Keir, Currently guest is seeing broken thread/core siblings topology because some of cupid bits are getting blocked by default. With the attached 2 patches hvm guest will see same topology as the host-os sees. It is still possible to override these bits in the guest config file, so that migration across different topology system can work. Please apply. Thanks & Regards, Nitin Linux Open Source Technology Center, Intel Corporation -------------------------------------------------------------------------------- The Mind is like a parachute; it works much better when it''s open. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hiding those details by default is a good strategy we¹d like to maintain. Furthermore we cannot change CPU-to-LAPIC identifier mapping without breaking saved guest images, which is not acceptable. If our hiding of host information is broken, we¹d like a patch to fix it; likewise any other CPUID inconsistency. What specific issues are you seeing? -- Keir On 29/9/08 18:21, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote:> Keir, > > Currently guest is seeing broken thread/core siblings topology because some of > cupid bits are getting blocked by default. > > With the attached 2 patches hvm guest will see same topology as the host-os > sees. > > It is still possible to override these bits in the guest config file, so that > migration across different topology system can work. > > Please apply. > > > Thanks & Regards, > Nitin > Linux Open Source Technology Center, Intel Corporation > ------------------------------------------------------------------------------ > -- > The Mind is like a parachute; it works much better when it''s open. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Hiding those details by default is a good strategy we''d like to maintain. [Nitin>] Why do you say it is a good strategy? What are the benefits associated with it? Furthermore we cannot change CPU-to-LAPIC identifier mapping without breaking saved guest images, which is not acceptable. [Nitin>] I am not clear on this part, how saved guest images get broken? I think this change is like upgrading BIOS. It should not break guest images. If our hiding of host information is broken, we''d like a patch to fix it; likewise any other CPUID inconsistency. What specific issues are you seeing? [Nitin>] This is an issue with OS which have licensing restriction on CPUs. A customer reported to us that they were not seeing all cpus on windows server because Xen is exposing each vcpu as a socket on a multi-core host system. -- Keir On 29/9/08 18:21, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote: Keir, Currently guest is seeing broken thread/core siblings topology because some of cupid bits are getting blocked by default. With the attached 2 patches hvm guest will see same topology as the host-os sees. It is still possible to override these bits in the guest config file, so that migration across different topology system can work. Please apply. Thanks & Regards, Nitin Linux Open Source Technology Center, Intel Corporation -------------------------------------------------------------------------------- The Mind is like a parachute; it works much better when it''s open. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I¹d be happy, by default, for xend to detect threads-per-socket on the host system and replicate that on guest CPUID. I don¹t see how direct pass-through of host CPUID values can work, because for example host LAPIC identifiers may be guest different from guest vLAPIC identifiers. So I won¹t apply anything like your original patches, period. -- Keir On 29/9/08 18:48, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote:> Hiding those details by default is a good strategy we¹d like to maintain. > [Nitin>] Why do you say it is a good strategy? What are the benefits > associated with it? > Furthermore we cannot change CPU-to-LAPIC identifier mapping without breaking > saved guest images, which is not acceptable. > [Nitin>] I am not clear on this part, how saved guest images get broken? I > think this change is like upgrading BIOS. It should not break guest images. > If our hiding of host information is broken, we¹d like a patch to fix it; > likewise any other CPUID inconsistency. What specific issues are you seeing? > [Nitin>] This is an issue with OS which have licensing restriction on CPUs. A > customer reported to us that they were not seeing all cpus on windows server > because Xen is exposing each vcpu as a socket on a multi-core host system._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
How about the following changes to our default HVM CPUID? Guest_CPUID.1:EBX[23:17] = Host_CPUID.1:EBX[22:16] Guest_CPUID.1:EBX[16] = 0 Guest_CPUID.4:EAX[31:27] = Host_CPUID.4:EAX[30:26] Guest_CPUID.4:EAX[26] = 1 Guest_CPUID.1:EDX[28] = Host_CPUID.1:EDX[28] Basically pass-through HT/multicore support, but specify max-cores-per-package and max-threads-per-package as twice the host values. This deals with the fact our virtual APIC IDs are 2*VCPUID. -- Keir On 29/9/08 21:15, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> I¹d be happy, by default, for xend to detect threads-per-socket on the host > system and replicate that on guest CPUID. I don¹t see how direct pass-through > of host CPUID values can work, because for example host LAPIC identifiers may > be guest different from guest vLAPIC identifiers. So I won¹t apply anything > like your original patches, period. > > -- Keir > > On 29/9/08 18:48, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote: > >> Hiding those details by default is a good strategy we¹d like to maintain. >> [Nitin>] Why do you say it is a good strategy? What are the benefits >> associated with it? >> Furthermore we cannot change CPU-to-LAPIC identifier mapping without breaking >> saved guest images, which is not acceptable. >> [Nitin>] I am not clear on this part, how saved guest images get broken? I >> think this change is like upgrading BIOS. It should not break guest images. >> If our hiding of host information is broken, we¹d like a patch to fix it; >> likewise any other CPUID inconsistency. What specific issues are you seeing? >> [Nitin>] This is an issue with OS which have licensing restriction on CPUs. A >> customer reported to us that they were not seeing all cpus on windows server >> because Xen is exposing each vcpu as a socket on a multi-core host system. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir,
I think what you are suggesting would work, and I was also thinking about
it.
Only thing is we will be adding 2nd effect to nullify 1st effect. IMHO
correcting 1st effect will be a better.
Why are you so sensitive to changing vlapic_id? If it has to stay the same, then
I can provide you a patch with your approach.
Thanks & Regards,
Nitin
Linux Open Source Technology Center, Intel Corporation
--------------------------------------------------------------------------------
The Mind is like a parachute; it works much better when it''s open.
________________________________
From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
Sent: Monday, September 29, 2008 2:31 PM
To: Kamble, Nitin A
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Re: cpuid information to hvm guest
How about the following changes to our default HVM CPUID?
Guest_CPUID.1:EBX[23:17] = Host_CPUID.1:EBX[22:16]
Guest_CPUID.1:EBX[16] = 0
Guest_CPUID.4:EAX[31:27] = Host_CPUID.4:EAX[30:26]
Guest_CPUID.4:EAX[26] = 1
Guest_CPUID.1:EDX[28] = Host_CPUID.1:EDX[28]
Basically pass-through HT/multicore support, but specify max-cores-per-package
and max-threads-per-package as twice the host values. This deals with the fact
our virtual APIC IDs are 2*VCPUID.
-- Keir
On 29/9/08 21:15, "Keir Fraser" <keir.fraser@eu.citrix.com>
wrote:
I''d be happy, by default, for xend to detect threads-per-socket on the
host system and replicate that on guest CPUID. I don''t see how direct
pass-through of host CPUID values can work, because for example host LAPIC
identifiers may be guest different from guest vLAPIC identifiers. So I
won''t apply anything like your original patches, period.
-- Keir
On 29/9/08 18:48, "Kamble, Nitin A" <nitin.a.kamble@intel.com>
wrote:
Hiding those details by default is a good strategy we''d like to
maintain.
[Nitin>] Why do you say it is a good strategy? What are the benefits
associated with it?
Furthermore we cannot change CPU-to-LAPIC identifier mapping without breaking
saved guest images, which is not acceptable.
[Nitin>] I am not clear on this part, how saved guest images get broken? I
think this change is like upgrading BIOS. It should not break guest images.
If our hiding of host information is broken, we''d like a patch to fix
it; likewise any other CPUID inconsistency. What specific issues are you seeing?
[Nitin>] This is an issue with OS which have licensing restriction on CPUs. A
customer reported to us that they were not seeing all cpus on windows server
because Xen is exposing each vcpu as a socket on a multi-core host system.
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Changing VLAPIC identifiers breaks xm restore¹ of old saved images. The reason for picking the current mapping is to strictly obey the constraints of the IOAPIC hardware that we emulate, which only supports a 4-bit identifier. Hence it is not strictly correct to number IO-APICs downwards from 0xfe: we would need to number it 0xf or lower. This coupled with needing to give VCPU0 APIC ID 0 (some OSes get upset otherwise) and not wanting to make a hole in the VCPU vLAPIC ID space for vIOAPICs, led to the vLAPIC_ID == vCPU_ID * 2 relationship. So, there is a reason why it is as it is, and a reason why it is a pain to change. And there¹s no particular reason to change it either, since we can appropriately translate host CPUID parameters quite easily. -- Keir On 29/9/08 23:32, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote:> Keir, > I think what you are suggesting would work, and I was also thinking about > it. > Only thing is we will be adding 2nd effect to nullify 1st effect. IMHO > correcting 1st effect will be a better. > > Why are you so sensitive to changing vlapic_id? If it has to stay the same, > then I can provide you a patch with your approach. > > > Thanks & Regards, > Nitin > Linux Open Source Technology Center, Intel Corporation > ------------------------------------------------------------------------------ > -- > The Mind is like a parachute; it works much better when it''s open. > > > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Monday, September 29, 2008 2:31 PM > To: Kamble, Nitin A > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Re: cpuid information to hvm guest > > How about the following changes to our default HVM CPUID? > > Guest_CPUID.1:EBX[23:17] = Host_CPUID.1:EBX[22:16] > Guest_CPUID.1:EBX[16] = 0 > Guest_CPUID.4:EAX[31:27] = Host_CPUID.4:EAX[30:26] > Guest_CPUID.4:EAX[26] = 1 > Guest_CPUID.1:EDX[28] = Host_CPUID.1:EDX[28] > > Basically pass-through HT/multicore support, but specify max-cores-per-package > and max-threads-per-package as twice the host values. This deals with the fact > our virtual APIC IDs are 2*VCPUID. > > -- Keir > > On 29/9/08 21:15, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > I¹d be happy, by default, for xend to detect threads-per-socket on the host > system and replicate that on guest CPUID. I don¹t see how direct pass-through > of host CPUID values can work, because for example host LAPIC identifiers may > be guest different from guest vLAPIC identifiers. So I won¹t apply anything > like your original patches, period. > > -- Keir > > On 29/9/08 18:48, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote: > Hiding those details by default is a good strategy we¹d like to maintain. > [Nitin>] Why do you say it is a good strategy? What are the benefits > associated with it? > Furthermore we cannot change CPU-to-LAPIC identifier mapping without breaking > saved guest images, which is not acceptable. > [Nitin>] I am not clear on this part, how saved guest images get broken? I > think this change is like upgrading BIOS. It should not break guest images. > If our hiding of host information is broken, we¹d like a patch to fix it; > likewise any other CPUID inconsistency. What specific issues are you seeing? > [Nitin>] This is an issue with OS which have licensing restriction on CPUs. A > customer reported to us that they were not seeing all cpus on windows server > because Xen is exposing each vcpu as a socket on a multi-core host system. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I applied a patch that does this as changeset 18560. -- Keir On 29/9/08 22:30, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> How about the following changes to our default HVM CPUID? > > Guest_CPUID.1:EBX[23:17] = Host_CPUID.1:EBX[22:16] > Guest_CPUID.1:EBX[16] = 0 > Guest_CPUID.4:EAX[31:27] = Host_CPUID.4:EAX[30:26] > Guest_CPUID.4:EAX[26] = 1 > Guest_CPUID.1:EDX[28] = Host_CPUID.1:EDX[28] > > Basically pass-through HT/multicore support, but specify max-cores-per-package > and max-threads-per-package as twice the host values. This deals with the fact > our virtual APIC IDs are 2*VCPUID. > > -- Keir > > On 29/9/08 21:15, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > >> I¹d be happy, by default, for xend to detect threads-per-socket on the host >> system and replicate that on guest CPUID. I don¹t see how direct pass-through >> of host CPUID values can work, because for example host LAPIC identifiers may >> be guest different from guest vLAPIC identifiers. So I won¹t apply anything >> like your original patches, period. >> >> -- Keir >> >> On 29/9/08 18:48, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote: >> >>> Hiding those details by default is a good strategy we¹d like to maintain. >>> [Nitin>] Why do you say it is a good strategy? What are the benefits >>> associated with it? >>> Furthermore we cannot change CPU-to-LAPIC identifier mapping without >>> breaking saved guest images, which is not acceptable. >>> [Nitin>] I am not clear on this part, how saved guest images get broken? I >>> think this change is like upgrading BIOS. It should not break guest images. >>> If our hiding of host information is broken, we¹d like a patch to fix it; >>> likewise any other CPUID inconsistency. What specific issues are you seeing? >>> [Nitin>] This is an issue with OS which have licensing restriction on CPUs. >>> A customer reported to us that they were not seeing all cpus on windows >>> server because Xen is exposing each vcpu as a socket on a multi-core host >>> system. >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir, Alright, I will give it a try. Thanks & Regards, Nitin Linux Open Source Technology Center, Intel Corporation -------------------------------------------------------------------------------- The Mind is like a parachute; it works much better when it''s open. ________________________________ From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: Tuesday, September 30, 2008 2:15 AM To: Kamble, Nitin A Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: cpuid information to hvm guest I applied a patch that does this as changeset 18560. -- Keir On 29/9/08 22:30, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: How about the following changes to our default HVM CPUID? Guest_CPUID.1:EBX[23:17] = Host_CPUID.1:EBX[22:16] Guest_CPUID.1:EBX[16] = 0 Guest_CPUID.4:EAX[31:27] = Host_CPUID.4:EAX[30:26] Guest_CPUID.4:EAX[26] = 1 Guest_CPUID.1:EDX[28] = Host_CPUID.1:EDX[28] Basically pass-through HT/multicore support, but specify max-cores-per-package and max-threads-per-package as twice the host values. This deals with the fact our virtual APIC IDs are 2*VCPUID. -- Keir On 29/9/08 21:15, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: I''d be happy, by default, for xend to detect threads-per-socket on the host system and replicate that on guest CPUID. I don''t see how direct pass-through of host CPUID values can work, because for example host LAPIC identifiers may be guest different from guest vLAPIC identifiers. So I won''t apply anything like your original patches, period. -- Keir On 29/9/08 18:48, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote: Hiding those details by default is a good strategy we''d like to maintain. [Nitin>] Why do you say it is a good strategy? What are the benefits associated with it? Furthermore we cannot change CPU-to-LAPIC identifier mapping without breaking saved guest images, which is not acceptable. [Nitin>] I am not clear on this part, how saved guest images get broken? I think this change is like upgrading BIOS. It should not break guest images. If our hiding of host information is broken, we''d like a patch to fix it; likewise any other CPUID inconsistency. What specific issues are you seeing? [Nitin>] This is an issue with OS which have licensing restriction on CPUs. A customer reported to us that they were not seeing all cpus on windows server because Xen is exposing each vcpu as a socket on a multi-core host system. ________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir, The patch is working right. I tested it with windows server 2003 enterprise guest. With the patch guest was running with 16 cpus; without the patch it could only work with 8 cpus and remaining 8 cpus were parked without using. Thanks & Regards, Nitin Linux Open Source Technology Center, Intel Corporation -------------------------------------------------------------------------------- The Mind is like a parachute; it works much better when it''s open. ________________________________ From: Kamble, Nitin A Sent: Tuesday, September 30, 2008 10:45 AM To: ''Keir Fraser'' Cc: xen-devel@lists.xensource.com Subject: RE: [Xen-devel] Re: cpuid information to hvm guest Keir, Alright, I will give it a try. Thanks & Regards, Nitin Linux Open Source Technology Center, Intel Corporation -------------------------------------------------------------------------------- The Mind is like a parachute; it works much better when it''s open. ________________________________ From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: Tuesday, September 30, 2008 2:15 AM To: Kamble, Nitin A Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Re: cpuid information to hvm guest I applied a patch that does this as changeset 18560. -- Keir On 29/9/08 22:30, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: How about the following changes to our default HVM CPUID? Guest_CPUID.1:EBX[23:17] = Host_CPUID.1:EBX[22:16] Guest_CPUID.1:EBX[16] = 0 Guest_CPUID.4:EAX[31:27] = Host_CPUID.4:EAX[30:26] Guest_CPUID.4:EAX[26] = 1 Guest_CPUID.1:EDX[28] = Host_CPUID.1:EDX[28] Basically pass-through HT/multicore support, but specify max-cores-per-package and max-threads-per-package as twice the host values. This deals with the fact our virtual APIC IDs are 2*VCPUID. -- Keir On 29/9/08 21:15, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: I''d be happy, by default, for xend to detect threads-per-socket on the host system and replicate that on guest CPUID. I don''t see how direct pass-through of host CPUID values can work, because for example host LAPIC identifiers may be guest different from guest vLAPIC identifiers. So I won''t apply anything like your original patches, period. -- Keir On 29/9/08 18:48, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote: Hiding those details by default is a good strategy we''d like to maintain. [Nitin>] Why do you say it is a good strategy? What are the benefits associated with it? Furthermore we cannot change CPU-to-LAPIC identifier mapping without breaking saved guest images, which is not acceptable. [Nitin>] I am not clear on this part, how saved guest images get broken? I think this change is like upgrading BIOS. It should not break guest images. If our hiding of host information is broken, we''d like a patch to fix it; likewise any other CPUID inconsistency. What specific issues are you seeing? [Nitin>] This is an issue with OS which have licensing restriction on CPUs. A customer reported to us that they were not seeing all cpus on windows server because Xen is exposing each vcpu as a socket on a multi-core host system. ________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Glad to hear it! -- Keir On 1/10/08 18:20, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote:> Keir, > The patch is working right. I tested it with windows server 2003 enterprise > guest. With the patch guest was running with 16 cpus; without the patch it > could only work with 8 cpus and remaining 8 cpus were parked without using. > > > Thanks & Regards, > Nitin > Linux Open Source Technology Center, Intel Corporation > ------------------------------------------------------------------------------ > -- > The Mind is like a parachute; it works much better when it''s open. > > > From: Kamble, Nitin A > Sent: Tuesday, September 30, 2008 10:45 AM > To: ''Keir Fraser'' > Cc: xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] Re: cpuid information to hvm guest > > Keir, > Alright, I will give it a try. > > > Thanks & Regards, > Nitin > Linux Open Source Technology Center, Intel Corporation > ------------------------------------------------------------------------------ > -- > The Mind is like a parachute; it works much better when it''s open. > > > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Tuesday, September 30, 2008 2:15 AM > To: Kamble, Nitin A > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Re: cpuid information to hvm guest > > I applied a patch that does this as changeset 18560. > > -- Keir > > On 29/9/08 22:30, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > How about the following changes to our default HVM CPUID? > > Guest_CPUID.1:EBX[23:17] = Host_CPUID.1:EBX[22:16] > Guest_CPUID.1:EBX[16] = 0 > Guest_CPUID.4:EAX[31:27] = Host_CPUID.4:EAX[30:26] > Guest_CPUID.4:EAX[26] = 1 > Guest_CPUID.1:EDX[28] = Host_CPUID.1:EDX[28] > > Basically pass-through HT/multicore support, but specify max-cores-per-package > and max-threads-per-package as twice the host values. This deals with the fact > our virtual APIC IDs are 2*VCPUID. > > -- Keir > > On 29/9/08 21:15, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > I¹d be happy, by default, for xend to detect threads-per-socket on the host > system and replicate that on guest CPUID. I don¹t see how direct pass-through > of host CPUID values can work, because for example host LAPIC identifiers may > be guest different from guest vLAPIC identifiers. So I won¹t apply anything > like your original patches, period. > > -- Keir > > On 29/9/08 18:48, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote: > Hiding those details by default is a good strategy we¹d like to maintain. > [Nitin>] Why do you say it is a good strategy? What are the benefits > associated with it? > Furthermore we cannot change CPU-to-LAPIC identifier mapping without breaking > saved guest images, which is not acceptable. > [Nitin>] I am not clear on this part, how saved guest images get broken? I > think this change is like upgrading BIOS. It should not break guest images. > If our hiding of host information is broken, we¹d like a patch to fix it; > likewise any other CPUID inconsistency. What specific issues are you seeing? > [Nitin>] This is an issue with OS which have licensing restriction on CPUs. A > customer reported to us that they were not seeing all cpus on windows server > because Xen is exposing each vcpu as a socket on a multi-core host system. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel