Questions about PVH in Xen 4.3 unstable

Questions about PVH in Xen 4.3 unstable

[tech mailinglists]

[-- Attachment #1.1: Type: text/plain, Size: 686 bytes --]

Hello all,

I have a few question about PVH guests on Xen 4.3 unstable.

Actually I am running 4.2.1 with Linux 3.7.4 with Debian Squeeze as Dom0.
For the HVM guests I am using ioemu stubdoms. When I understood PVH
correctly it implements that what actually is done with PV drivers on HVM
guests as a aggregated and seperate guest type.

So is it already possible to use PVH in 4.3 unstable for Dom0 and DomU? And
does PVHs can get use of stubdoms?

I am a little bit confused about a text I read that stubdoms are not needed
for HVM guests which have PV drivers installed, is this correct or can a
HVM guest always make use of stubdoms?

Hope that someone could help me.

Best Regards

[-- Attachment #1.2: Type: text/html, Size: 785 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Questions about PVH in Xen 4.3 unstable

[Samuel Thibault]

tech mailinglists, le Wed 30 Jan 2013 11:33:23 +0100, a écrit :
> Actually I am running 4.2.1 with Linux 3.7.4 with Debian Squeeze as Dom0. For
> the HVM guests I am using ioemu stubdoms. When I understood PVH correctly it
> implements that what actually is done with PV drivers on HVM guests as a
> aggregated and seperate guest type.

It's more than that. The guest does not need ioemu at all.

> And does PVHs can get use of stubdoms?

And thus PVH have no use for stubdoms, since there is no ioemu to
execute in there.

> I am a little bit confused about a text I read that stubdoms are not needed for
> HVM guests which have PV drivers installed,

Ioemu is still needed for those domains, but running it in a stubdom
won't bring more performance, since what matters for performance will
not go through ioemu, when PV drivers are installed.

> is this correct or can a HVM guest always make use of stubdoms?

HVM can always make use of stubdoms to execute ioemu, but that won't
improve performance. It could improve early boot time, at best.

Samuel

Re: Questions about PVH in Xen 4.3 unstable

[tech mailinglists]

[-- Attachment #1.1: Type: text/plain, Size: 1379 bytes --]

I thought that stubdoms for HVMs are great for security. Can it still be
used for PV-on-HVM for security? Can only Linux run as PVH and Windows and
so on still run as HVM?




2013/1/30 Samuel Thibault <samuel.thibault@ens-lyon.org>

> tech mailinglists, le Wed 30 Jan 2013 11:33:23 +0100, a écrit :
> > Actually I am running 4.2.1 with Linux 3.7.4 with Debian Squeeze as
> Dom0. For
> > the HVM guests I am using ioemu stubdoms. When I understood PVH
> correctly it
> > implements that what actually is done with PV drivers on HVM guests as a
> > aggregated and seperate guest type.
>
> It's more than that. The guest does not need ioemu at all.
>
> > And does PVHs can get use of stubdoms?
>
> And thus PVH have no use for stubdoms, since there is no ioemu to
> execute in there.
>
> > I am a little bit confused about a text I read that stubdoms are not
> needed for
> > HVM guests which have PV drivers installed,
>
> Ioemu is still needed for those domains, but running it in a stubdom
> won't bring more performance, since what matters for performance will
> not go through ioemu, when PV drivers are installed.
>
> > is this correct or can a HVM guest always make use of stubdoms?
>
> HVM can always make use of stubdoms to execute ioemu, but that won't
> improve performance. It could improve early boot time, at best.
>
> Samuel
>

[-- Attachment #1.2: Type: text/html, Size: 1919 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Questions about PVH in Xen 4.3 unstable

[Samuel Thibault]

tech mailinglists, le Wed 30 Jan 2013 11:52:48 +0100, a écrit :
> I thought that stubdoms for HVMs are great for security.

Ah, yes, for security it can still be interesting to use a stubdom for
ioemu.

> Can it still be used for PV-on-HVM for security?

Sure.

> Can only Linux run as PVH and Windows and so on still run as HVM?

Yes.

The other PV-capable OSes will probably be ported to PVH too, though.

Samuel

Re: Questions about PVH in Xen 4.3 unstable

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 880 bytes --]

On Wed, Jan 30, 2013 at 10:52 AM, tech mailinglists <
mailinglists.tech@gmail.com> wrote:

> I thought that stubdoms for HVMs are great for security. Can it still be
> used for PV-on-HVM for security? Can only Linux run as PVH and Windows and
> so on still run as HVM?
>

Stubdoms increase security by isolating the qemu process, so that it's not
running in domain 0.  PV domains (and by extension PVH domains) don't have
a qemu process, and are therefore are secure without needing a stubdom.

Yes, PVH is an extension of PV; so only operating systems which can be
ported to PV will support PVH.

Microsoft could of course port Windows to PV or PVH; in fact, the original
2003 Xen paper included tests run on a PV-ported version of Windows XP done
by the guys at Microsoft Research, Cambridge.  But it seems pretty unlikely
that they'll ever do such a thing again. :-)

 -George

[-- Attachment #1.2: Type: text/html, Size: 1283 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Questions about PVH in Xen 4.3 unstable

[Roger Pau Monné]

On 30/01/13 11:04, George Dunlap wrote:
> On Wed, Jan 30, 2013 at 10:52 AM, tech mailinglists
> <mailinglists.tech@gmail.com <mailto:mailinglists.tech@gmail.com>> wrote:
> 
>     I thought that stubdoms for HVMs are great for security. Can it
>     still be used for PV-on-HVM for security? Can only Linux run as PVH
>     and Windows and so on still run as HVM?
> 
> 
> Stubdoms increase security by isolating the qemu process, so that it's
> not running in domain 0.  PV domains (and by extension PVH domains)
> don't have a qemu process, and are therefore are secure without needing
> a stubdom.
> 
> Yes, PVH is an extension of PV; so only operating systems which can be
> ported to PV will support PVH.

Isn't it probably easier to port a system with PVHVM support to PVH?

Re: Questions about PVH in Xen 4.3 unstable

[Samuel Thibault]

Roger Pau Monné, le Wed 30 Jan 2013 11:11:00 +0000, a écrit :
> On 30/01/13 11:04, George Dunlap wrote:
> > Yes, PVH is an extension of PV; so only operating systems which can be
> > ported to PV will support PVH.
> 
> Isn't it probably easier to port a system with PVHVM support to PVH?

In general, no. Porting a system to PV involves a lot of tricky things
deep in the OS, while writing a PV driver is much less involving.

Samuel

Re: Questions about PVH in Xen 4.3 unstable

[Ian Campbell]

On Wed, 2013-01-30 at 12:20 +0000, Samuel Thibault wrote:
> Roger Pau Monné, le Wed 30 Jan 2013 11:11:00 +0000, a écrit :
> > On 30/01/13 11:04, George Dunlap wrote:
> > > Yes, PVH is an extension of PV; so only operating systems which can be
> > > ported to PV will support PVH.
> > 
> > Isn't it probably easier to port a system with PVHVM support to PVH?
> 
> In general, no. Porting a system to PV involves a lot of tricky things
> deep in the OS, while writing a PV driver is much less involving.

But in some sense the work for PVH is a superset of that for PVHVM, so
in that sense it would be easier to port an OS with existing PVHVM
support to PVH (which I think may have been what Roger was asking).

It is certainly the case that porting to PVH should be much easier than
a port to regular PV.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Questions about PVH in Xen 4.3 unstable

[Samuel Thibault]

Ian Campbell, le Wed 30 Jan 2013 12:26:07 +0000, a écrit :
> On Wed, 2013-01-30 at 12:20 +0000, Samuel Thibault wrote:
> > Roger Pau Monné, le Wed 30 Jan 2013 11:11:00 +0000, a écrit :
> > > On 30/01/13 11:04, George Dunlap wrote:
> > > > Yes, PVH is an extension of PV; so only operating systems which can be
> > > > ported to PV will support PVH.
> > > 
> > > Isn't it probably easier to port a system with PVHVM support to PVH?
> > 
> > In general, no. Porting a system to PV involves a lot of tricky things
> > deep in the OS, while writing a PV driver is much less involving.
> 
> But in some sense the work for PVH is a superset of that for PVHVM, so
> in that sense it would be easier to port an OS with existing PVHVM
> support to PVH (which I think may have been what Roger was asking).
> 
> It is certainly the case that porting to PVH should be much easier than
> a port to regular PV.

Ah, yes.  I hadn't understood the question that way, sorry.

Samuel

Re: Questions about PVH in Xen 4.3 unstable

[Samuel Thibault]

Samuel Thibault, le Wed 30 Jan 2013 13:20:16 +0100, a écrit :
> Roger Pau Monné, le Wed 30 Jan 2013 11:11:00 +0000, a écrit :
> > On 30/01/13 11:04, George Dunlap wrote:
> > > Yes, PVH is an extension of PV; so only operating systems which can be
> > > ported to PV will support PVH.
> > 
> > Isn't it probably easier to port a system with PVHVM support to PVH?
> 
> In general, no. Porting a system to PV involves a lot of tricky things
> deep in the OS, while writing a PV driver is much less involving.

Let me fix it: porting a system to PVH involves a lot less tricky things
deep in the OS than porting it to PV. There are still quite a few tricky
things to do, so I don't think PVH is half-way between PV and PVHVM.

Samuel

Re: Questions about PVH in Xen 4.3 unstable

[Samuel Thibault]

Samuel Thibault, le Wed 30 Jan 2013 13:26:08 +0100, a écrit :
> Samuel Thibault, le Wed 30 Jan 2013 13:20:16 +0100, a écrit :
> > Roger Pau Monné, le Wed 30 Jan 2013 11:11:00 +0000, a écrit :
> > > On 30/01/13 11:04, George Dunlap wrote:
> > > > Yes, PVH is an extension of PV; so only operating systems which can be
> > > > ported to PV will support PVH.
> > > 
> > > Isn't it probably easier to port a system with PVHVM support to PVH?
> > 
> > In general, no. Porting a system to PV involves a lot of tricky things
> > deep in the OS, while writing a PV driver is much less involving.
> 
> Let me fix it: porting a system to PVH involves a lot less tricky things
> deep in the OS than porting it to PV. There are still quite a few tricky
> things to do, so I don't think PVH is half-way between PV and PVHVM.

Let me fix it again :)

Starting from PV, most of what you need to support PVH is to just drop
the PV implementation and use the native code, without writing any code.

So even if it PVH was actually halfway between PVHVM and PV, it surely
is not halfway between PV and PVHVM :)

Samuel

Re: Questions about PVH in Xen 4.3 unstable

[Roger Pau Monné]

On 30/01/13 12:32, Samuel Thibault wrote:
> Samuel Thibault, le Wed 30 Jan 2013 13:26:08 +0100, a écrit :
>> Samuel Thibault, le Wed 30 Jan 2013 13:20:16 +0100, a écrit :
>>> Roger Pau Monné, le Wed 30 Jan 2013 11:11:00 +0000, a écrit :
>>>> On 30/01/13 11:04, George Dunlap wrote:
>>>>> Yes, PVH is an extension of PV; so only operating systems which can be
>>>>> ported to PV will support PVH.
>>>>
>>>> Isn't it probably easier to port a system with PVHVM support to PVH?
>>>
>>> In general, no. Porting a system to PV involves a lot of tricky things
>>> deep in the OS, while writing a PV driver is much less involving.
>>
>> Let me fix it: porting a system to PVH involves a lot less tricky things
>> deep in the OS than porting it to PV. There are still quite a few tricky
>> things to do, so I don't think PVH is half-way between PV and PVHVM.
> 
> Let me fix it again :)
> 
> Starting from PV, most of what you need to support PVH is to just drop
> the PV implementation and use the native code, without writing any code.

>From what I saw, PVH uses most of the PVHVM code paths, like the PVHVM
vector callback for events (not the PV callback), and grant frames are
also using the PVHVM paths, so I was thinking that the transition from
PVHVM to PVH was going to be easier than the transition from PV to PVH.
But yes, you also need some of the PV tricks, so I'm not sure what will
be more difficult to implement, the PV tricks or the PVHVM infrastructure.

Anyway, it is surely going to be much more easier to port a OS to PVH
from scratch compared to PV.

> So even if it PVH was actually halfway between PVHVM and PV, it surely
> is not halfway between PV and PVHVM :)
> 
> Samuel
> 

Re: Questions about PVH in Xen 4.3 unstable

[tech mailinglists]

[-- Attachment #1.1: Type: text/plain, Size: 3330 bytes --]

Thats good that I understood now everything. So can xenstored/oxenstored
stubdoms run on the actual stable trunk? I already talked with Daniel de
Graaf from the NSA about this theme in this thread:
http://lists.xen.org/archives/html/xen-devel/2013-01/msg00956.html

So the main problem is that the FLASK ruleset he posted is incompatible
with 4.2.1. I also talked with Steven Maresca on IRC about this and he said
that in 4.2.1 only sysctl hypercalls are support more or less by XSM/FLASK
and not domctl hypercalls so I think that these lines are a problem:


*# Xenstore requires the global VIRQ for domain destroy
operations**allow dom0_t xenstore_t:domain set_virq_handler;**#
Current xenstore stubdom uses the hypervisor console, not "xl
console"**allow xenstore_t xen_t:xen writeconsole;**# Xenstore queries
domaininfo on all domains**allow xenstore_t domain_type:domain
getdomaininfo;**# As a shortcut, the following 3 rules are used
instead of adding a**domain_comms**# rule between xenstore_t and every
domain type that talks to xenstore**create_channel(xenstore_t,
domain_type, xenstore_t_channel)**allow event_type xenstore_t: event
bind;**allow xenstore_t domain_type:grant { map_read map_write unmap
};

*

*
*


Aspecially the first two roles I think won't work, in the case of the
other lines I am not sure.

Can I workaround this and find a FLASK ruleset to use
xenstored/oxenstored stubdom on 4.2.1?

Best Regards



2013/1/30 Roger Pau Monné <roger.pau@citrix.com>

> On 30/01/13 12:32, Samuel Thibault wrote:
> > Samuel Thibault, le Wed 30 Jan 2013 13:26:08 +0100, a écrit :
> >> Samuel Thibault, le Wed 30 Jan 2013 13:20:16 +0100, a écrit :
> >>> Roger Pau Monné, le Wed 30 Jan 2013 11:11:00 +0000, a écrit :
> >>>> On 30/01/13 11:04, George Dunlap wrote:
> >>>>> Yes, PVH is an extension of PV; so only operating systems which can
> be
> >>>>> ported to PV will support PVH.
> >>>>
> >>>> Isn't it probably easier to port a system with PVHVM support to PVH?
> >>>
> >>> In general, no. Porting a system to PV involves a lot of tricky things
> >>> deep in the OS, while writing a PV driver is much less involving.
> >>
> >> Let me fix it: porting a system to PVH involves a lot less tricky things
> >> deep in the OS than porting it to PV. There are still quite a few tricky
> >> things to do, so I don't think PVH is half-way between PV and PVHVM.
> >
> > Let me fix it again :)
> >
> > Starting from PV, most of what you need to support PVH is to just drop
> > the PV implementation and use the native code, without writing any code.
>
> From what I saw, PVH uses most of the PVHVM code paths, like the PVHVM
> vector callback for events (not the PV callback), and grant frames are
> also using the PVHVM paths, so I was thinking that the transition from
> PVHVM to PVH was going to be easier than the transition from PV to PVH.
> But yes, you also need some of the PV tricks, so I'm not sure what will
> be more difficult to implement, the PV tricks or the PVHVM infrastructure.
>
> Anyway, it is surely going to be much more easier to port a OS to PVH
> from scratch compared to PV.
>
> > So even if it PVH was actually halfway between PVHVM and PV, it surely
> > is not halfway between PV and PVHVM :)
> >
> > Samuel
> >
>
>

[-- Attachment #1.2: Type: text/html, Size: 4213 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Questions about PVH in Xen 4.3 unstable

[Samuel Thibault]

Samuel Thibault, le Wed 30 Jan 2013 13:26:08 +0100, a écrit :
> There are still quite a few tricky things to do, so I don't think PVH
> is half-way between PV and PVHVM.

Please scratch that. With the answers to my questions, it seems there is
very little needed work once one has PVHVM. Mostly some plumbing in the
early boot and device detection.

Samuel

Re: Questions about PVH in Xen 4.3 unstable

[Jan Beulich]

>>> On 30.01.13 at 12:04, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Wed, Jan 30, 2013 at 10:52 AM, tech mailinglists <
> mailinglists.tech@gmail.com> wrote:
> 
>> I thought that stubdoms for HVMs are great for security. Can it still be
>> used for PV-on-HVM for security? Can only Linux run as PVH and Windows and
>> so on still run as HVM?
>>
> 
> Stubdoms increase security by isolating the qemu process, so that it's not
> running in domain 0.  PV domains (and by extension PVH domains) don't have
> a qemu process, and are therefore are secure without needing a stubdom.

That's not generally true - PV domains (including Dom0 itself) can
have a qemu e.g. for providing a block backend drivers for certain
disk types.

Jan

Re: Questions about PVH in Xen 4.3 unstable

[tech mailinglists]

[-- Attachment #1.1: Type: text/plain, Size: 2496 bytes --]

I read the blog posts and watched the video of Mukesh's prasentation. And
now I want to try to summer up the existing guest/domain-types and
stubdom-types to verify I understood them:

Guest/Domain-Types

PV: A PV guest is a guest where the kernel is so modified that it knows
that it is a virtualized system (no priviliged instructions, special
drivers and so on).

HVM: This guests are guest which can not be modified or need to run because
of other reasons with the original code base. This guests run with the
VT-x/AMD-V implementations in the modern CPUs. They need QEmu and can use
ioemu stubdoms

PVHVM: This guests are HVM guests for which special drivers exists for the
qemu devices, which makes it possible to shrink the need of emulation
because the guest knows that the devices are virtual.

PVH: This guests are PV guests which can use the hardware virtualization
technologies of the CPUs to do special things. About this I have still two
questions: I found out that a few tasks are faster in HVM Mode so is it a
try to make PV guests faster? And does PVH makes it easier to implement PV
in an operating system kernels?

Stubdoms:

PV-GRUB: This is a stubdom where GRUB is compiled against Mini-OS to get
all features of GRUB and doesn't need to use PyGRUB within Dom0.

ioemu: This stubdom is a QEmu version which is compiled against Mini-OS and
it isolates the qemu process of a HVM DomU.

xenstore: This stubdom contains the xenstore service which holds a database
about resources and domains. So it stores informations about which resource
is attached to which domain and so on.

Would this description be right or does I think wrong?

Best Regards


2013/1/30 Jan Beulich <JBeulich@suse.com>

> >>> On 30.01.13 at 12:04, George Dunlap <George.Dunlap@eu.citrix.com>
> wrote:
> > On Wed, Jan 30, 2013 at 10:52 AM, tech mailinglists <
> > mailinglists.tech@gmail.com> wrote:
> >
> >> I thought that stubdoms for HVMs are great for security. Can it still be
> >> used for PV-on-HVM for security? Can only Linux run as PVH and Windows
> and
> >> so on still run as HVM?
> >>
> >
> > Stubdoms increase security by isolating the qemu process, so that it's
> not
> > running in domain 0.  PV domains (and by extension PVH domains) don't
> have
> > a qemu process, and are therefore are secure without needing a stubdom.
>
> That's not generally true - PV domains (including Dom0 itself) can
> have a qemu e.g. for providing a block backend drivers for certain
> disk types.
>
> Jan
>
>

[-- Attachment #1.2: Type: text/html, Size: 3298 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Questions about PVH in Xen 4.3 unstable

[Samuel Thibault]

tech mailinglists, le Wed 30 Jan 2013 13:04:57 +0100, a écrit :
> Would this description be right or does I think wrong?

All this seems right to me.

> I found out that a few tasks are faster in HVM Mode so is it a try to
> make PV guests faster?

Yes.

> And does PVH makes it easier to implement PV in an operating system
> kernels?

Yes. It avoids a lot of the tricky parts of implementing PV.

Samuel

Re: Questions about PVH in Xen 4.3 unstable

[George Dunlap]

On 30/01/13 12:04, tech mailinglists wrote:
> I read the blog posts and watched the video of Mukesh's prasentation. 
> And now I want to try to summer up the existing guest/domain-types and 
> stubdom-types to verify I understood them:
>
> Guest/Domain-Types
>
> PV: A PV guest is a guest where the kernel is so modified that it 
> knows that it is a virtualized system (no priviliged instructions, 
> special drivers and so on).
>
> HVM: This guests are guest which can not be modified or need to run 
> because of other reasons with the original code base. This guests run 
> with the VT-x/AMD-V implementations in the modern CPUs. They need QEmu 
> and can use ioemu stubdoms
>
> PVHVM: This guests are HVM guests for which special drivers exists for 
> the qemu devices, which makes it possible to shrink the need of 
> emulation because the guest knows that the devices are virtual.

Not quite.  "PVHVM" is where the guest knows about more of the PV 
interfaces provided by Xen and uses those instead of the emulated ones.  
It doesn't necessarily have to do with things provided by qemu.

For example, one of the big things in PVHVM is the use the event channel 
interface for interrupts, rather than emulated APICs.  APICs are 
emulated in Xen, not in qemu, so they're pretty fast.  Still, each 
interrupt requires the guest to go into the hypervisor 3 times when 
using a virtual APIC (because you have to do 3 MMIO writes), but only 
once when using event channels.

But PVHVM guests still use qemu for emulated mouse, motherboard, 
cd-roms, and so on, because there's not really a performance problem there.

> PVH: This guests are PV guests which can use the hardware 
> virtualization technologies of the CPUs to do special things. About 
> this I have still two questions: I found out that a few tasks are 
> faster in HVM Mode so is it a try to make PV guests faster?

This is covered in the blogs, I think.  There are sometimes performance 
advantages to using the HVM extensions, and that's a big reason to have 
this mode.  The other big thing is to get rid of the MMU hooks in the 
pvops kernel, which is the source of a lot of unhappiness and stress.

> And does PVH makes it easier to implement PV in an operating system 
> kernels?

Probably, yes.

> Stubdoms:
>
> PV-GRUB: This is a stubdom where GRUB is compiled against Mini-OS to 
> get all features of GRUB and doesn't need to use PyGRUB within Dom0.

Yes -- although I'm not sure I would call this a stubdom technically, 
since it runs inside the guest domain itself and goes a way once it 
starts.  It's basically the equivalent of BIOS+grub for HVM domains.

> ioemu: This stubdom is a QEmu version which is compiled against 
> Mini-OS and it isolates the qemu process of a HVM DomU.
>
> xenstore: This stubdom contains the xenstore service which holds a 
> database about resources and domains. So it stores informations about 
> which resource is attached to which domain and so on.
>
> Would this description be right or does I think wrong?

Everything else sounds about right.

  -George

Re: Questions about PVH in Xen 4.3 unstable

[Samuel Thibault]

Jan Beulich, le Wed 30 Jan 2013 11:29:00 +0000, a écrit :
> >>> On 30.01.13 at 12:04, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> > On Wed, Jan 30, 2013 at 10:52 AM, tech mailinglists <
> > mailinglists.tech@gmail.com> wrote:
> > 
> >> I thought that stubdoms for HVMs are great for security. Can it still be
> >> used for PV-on-HVM for security? Can only Linux run as PVH and Windows and
> >> so on still run as HVM?
> >>
> > 
> > Stubdoms increase security by isolating the qemu process, so that it's not
> > running in domain 0.  PV domains (and by extension PVH domains) don't have
> > a qemu process, and are therefore are secure without needing a stubdom.
> 
> That's not generally true - PV domains (including Dom0 itself) can
> have a qemu e.g. for providing a block backend drivers for certain
> disk types.

Right. And unfortunately one can't use a stubdom for that, since that'd
only move the disk access problem to the stubdom.

Samuel

Re: Questions about PVH in Xen 4.3 unstable

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 1385 bytes --]

On Wed, Jan 30, 2013 at 10:33 AM, tech mailinglists <
mailinglists.tech@gmail.com> wrote:

> Hello all,
>
> I have a few question about PVH guests on Xen 4.3 unstable.
>
> Actually I am running 4.2.1 with Linux 3.7.4 with Debian Squeeze as Dom0.
> For the HVM guests I am using ioemu stubdoms. When I understood PVH
> correctly it implements that what actually is done with PV drivers on HVM
> guests as a aggregated and seperate guest type.
>
> So is it already possible to use PVH in 4.3 unstable for Dom0 and DomU?
> And does PVHs can get use of stubdoms?
>

it sounds like you may be confusing "PVHVM" and "PVH".  No surprise, as it
is unfortunately very confusing. :-)  Have you read the blog posts on the
subject?

http://blog.xen.org/index.php/2012/10/23/the-paravirtualization-spectrum-part-1-the-ends-of-the-spectrum/
http://blog.xen.org/index.php/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/

PVHVM guests, from Xen's perspective, are just HVM guests that know how to
use many of the PV features.  So PVHVM guests need qemu, and thus can use
stubdoms.  This mode has been available for several years now.

PVH guests are PV guests that know how to use some HVM features.  So PVH
guests will not need qemu, and thus not need stubdoms.  The patches for
these have not been checked in yet, and so are not available even in
4.3-unstable.

 -George

[-- Attachment #1.2: Type: text/html, Size: 2120 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel