Re: [Xen-devel] [PATCH v11 02/12] xen/pvh: Define what an PVH guestis.

From: Ian Campbell
Date: Wed Dec 18 2013 - 12:03:33 EST


On Wed, 2013-12-18 at 11:58 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 18, 2013 at 04:01:03PM +0000, Ian Campbell wrote:
> > On Wed, 2013-12-18 at 14:55 +0000, Stefano Stabellini wrote:
> > > On Wed, 18 Dec 2013, Stefano Stabellini wrote:
> > > > On Tue, 17 Dec 2013, Konrad Rzeszutek Wilk wrote:
> > > > > From: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> > > > >
> > > > > Which is a PV guest with auto page translation enabled
> > > > > and with vector callback. It is a cross between PVHVM and PV.
> > > > >
> > > > > The Xen side defines PVH as (from docs/misc/pvh-readme.txt,
> > > > > with modifications):
> > > > >
> > > > > "* the guest uses auto translate:
> > > > > - p2m is managed by Xen
> > > > > - pagetables are owned by the guest
> > > > > - mmu_update hypercall not available
> > > > > * it uses event callback and not vlapic emulation,
> > > > > * IDT is native, so set_trap_table hcall is also N/A for a PVH guest.
> > > > >
> > > > > For a full list of hcalls supported for PVH, see pvh_hypercall64_table
> > > > > in arch/x86/hvm/hvm.c in xen. From the ABI prespective, it's mostly a
> > > > > PV guest with auto translate, although it does use hvm_op for setting
> > > > > callback vector."
> > > > >
> > > > > We don't have yet a Kconfig entry setup as we do not
> > > > > have all the parts ready for it - so we piggyback
> > > > > on the PVHVM config option. This scaffolding will
> > > > > be removed later.
> > > > >
> > > > > Signed-off-by: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> > > > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > > >
> > > > Could you please add an "&& CONFIG_X86"?
> > >
> > > On second thought, given that it is just temporary and that PVHVM is not
> > > defined on ARM, it could be OK. But maybe it is worth adding a small
> > > comment on the fact that this is an x86-only option.
> >
> > I wonder if it should be CONFIG_XEN_X86_{PVH,PVHVM} instead?
>
> Originally it was CONFIG_XEN_X86_PVH but I figured it would be pointless
> as most of the changes were in arch/x86 and that is by default x86.
>
> And then once that work is stabilized, ARM can kind of do the same thing - have
> an CONFIG_XEN_PVH that would (hopefully) have the same ABI as x86 PVH?
>
> Thought, you kind of already do PVH in spirit. Is that what you were
> alluding too? As ARM already boots in PV and the page table manipulations
> are done by the hardware.
>
> ?

The Zen answer is that an ARM guest is neither PV nor HVM nor PVHVM.
It's a bit like PVH but is different also (it's further towards the H
end of the spectrum than even PVH).

I'm keen to avoid using these x86 specific terms to widely to refer to
ARM guests, because it leads to confusion.

Ian.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/