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 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Samuel Thibault
2013-Jan-30 10:47 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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
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
George Dunlap
2013-Jan-30 10:50 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
tech mailinglists
2013-Jan-30 10:52 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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 >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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
Samuel Thibault
2013-Jan-30 10:56 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
George Dunlap
2013-Jan-30 11:04 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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?
Roger Pau Monné
2013-Jan-30 11:11 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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?
>>> 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
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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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
Samuel Thibault
2013-Jan-30 12:20 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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
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
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
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
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
Ian Campbell
2013-Jan-30 12:26 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Samuel Thibault
2013-Jan-30 12:26 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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
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
Samuel Thibault
2013-Jan-30 12:32 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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
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
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
Samuel Thibault
2013-Jan-30 12:33 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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
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 >
Roger Pau Monné
2013-Jan-30 12:43 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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 >
tech mailinglists
2013-Jan-30 13:35 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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
> >
>
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
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
> >
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
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
Samuel Thibault
2013-Jan-30 15:02 UTC
Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable
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