Xen devel - Jun 2006 - credit scheduler issues in 64bit hypervisor

When we use credit scheduler in 64bit hypervisor, we see these issues:
+ Booting 32bit VMX domain hangs at "ACPI: Unable to locate RSDP".
+ Booting 32pae VMX domain will get a kernel panic.
+ Booting indows SP1/SP2 Guest will crash guest OS.

We don''t see these issues with BVT scheduler.

Bests
Jeff

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

> When we use credit scheduler in 64bit hypervisor, we see these issues:
> + Booting 32bit VMX domain hangs at "ACPI: Unable to locate
RSDP".
> + Booting 32pae VMX domain will get a kernel panic.
> + Booting indows SP1/SP2 Guest will crash guest OS.
> 
> We don''t see these issues with BVT scheduler.
Is this specific to 64b hypervisor? We do most HVM testing on 32b PAE
and haven''t seen these issues.

Ian
> 
> Bests
> Jeff
> 
> _______________________________________________
> 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

On Wed, Jun 28, 2006 at 11:40:07AM +0800, Zheng, Jeff
wrote:
> When we use credit scheduler in 64bit hypervisor, we see these issues:
> + Booting 32bit VMX domain hangs at "ACPI: Unable to locate
RSDP".
> + Booting 32pae VMX domain will get a kernel panic.
> + Booting indows SP1/SP2 Guest will crash guest OS.
> 
> We don''t see these issues with BVT scheduler.
Which tree and which changeset are you working from?
Are you at least up to changeset d7543cff88ae (Cleanups
and fixes to VMCS lifecycle)? You need to be.

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

We are using changeset 10508, the changeset you mentioned is 10318, so we must
have the fixes.
-Xin 
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com 
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
>Emmanuel Ackaouy
>Sent: 2006年6月28日 21:08
>To: Zheng, Jeff
>Cc: xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] credit scheduler issues in 64bit hypervisor
>
>On Wed, Jun 28, 2006 at 11:40:07AM +0800, Zheng, Jeff wrote:
>> When we use credit scheduler in 64bit hypervisor, we see 
>these issues:
>> + Booting 32bit VMX domain hangs at "ACPI: Unable to locate
RSDP".
>> + Booting 32pae VMX domain will get a kernel panic.
>> + Booting indows SP1/SP2 Guest will crash guest OS.
>> 
>> We don''t see these issues with BVT scheduler.
>
>Which tree and which changeset are you working from?
>Are you at least up to changeset d7543cff88ae (Cleanups
>and fixes to VMCS lifecycle)? You need to be.
>
>_______________________________________________
>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

Yes. This is specific to 64bit hypervisor. We see these issue at CS10508 and
CS10482.

We didn''t see these issues on 32bit/32bit pae hypervisor.

Bests
Jeff 
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com 
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ian Pratt
>Sent: 2006年6月28日 20:43
>To: Zheng, Jeff; xen-devel@lists.xensource.com
>Subject: RE: [Xen-devel] credit scheduler issues in 64bit hypervisor 
>
>> When we use credit scheduler in 64bit hypervisor, we see 
>these issues:
>> + Booting 32bit VMX domain hangs at "ACPI: Unable to locate
RSDP".
>> + Booting 32pae VMX domain will get a kernel panic.
>> + Booting indows SP1/SP2 Guest will crash guest OS.
>> 
>> We don''t see these issues with BVT scheduler.
>
>Is this specific to 64b hypervisor? We do most HVM testing on 32b PAE
>and haven''t seen these issues.
>
>Ian
>
>> 
>> Bests
>> Jeff
>> 
>> _______________________________________________
>> 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

We saw these issue on ChangeSet 10508 and 10482.

Bests
Jeff 
>-----Original Message-----
>From: Emmanuel Ackaouy [mailto:ack@xensource.com] 
>Sent: 2006年6月28日 21:08
>To: Zheng, Jeff
>Cc: xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] credit scheduler issues in 64bit hypervisor
>
>On Wed, Jun 28, 2006 at 11:40:07AM +0800, Zheng, Jeff wrote:
>> When we use credit scheduler in 64bit hypervisor, we see 
>these issues:
>> + Booting 32bit VMX domain hangs at "ACPI: Unable to locate
RSDP".
>> + Booting 32pae VMX domain will get a kernel panic.
>> + Booting indows SP1/SP2 Guest will crash guest OS.
>> 
>> We don''t see these issues with BVT scheduler.
>
>Which tree and which changeset are you working from?
>Are you at least up to changeset d7543cff88ae (Cleanups
>and fixes to VMCS lifecycle)? You need to be.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I''m using sedf scheduler with changeset 10520 on my VT machine which
has 4 cpus.
I created a 4 vcpus SMP VMX guest and then a windows guest installer, I got:

(XEN) (GUEST: 14) ata0-0: PCHS=4063/16/63 translation=lba LCHS=1015/64/63
(XEN) (GUEST: 14) ata0 master: QEMU HARDDISK ATA-2 Hard-Disk (2000 MBytes)
(XEN) (GUEST: 14) ata0  slave: Unknown device
(XEN) (GUEST: 14) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom
(XEN) (GUEST: 14) ata1  slave: Unknown device
(XEN) (GUEST: 14) 
(XEN) (GUEST: 14) Booting from CD-Rom...
(XEN) (GUEST: 14) Invalid %cs=0x58 for protected mode
(XEN) (GUEST: 14) 
(XEN) (GUEST: 14) Halt called from %eip 0xD32DA 

But if I only create the windows guest, all is OK.
So seems we have bug if one physical cpu is used by 2 different VMX guest,
I''m looking at it.

-Xin
 
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com 
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Zheng, Jeff
>Sent: 2006年6月28日 11:40
>To: xen-devel@lists.xensource.com
>Subject: [Xen-devel] credit scheduler issues in 64bit hypervisor 
>
>When we use credit scheduler in 64bit hypervisor, we see these issues:
>+ Booting 32bit VMX domain hangs at "ACPI: Unable to locate RSDP".
>+ Booting 32pae VMX domain will get a kernel panic.
>+ Booting indows SP1/SP2 Guest will crash guest OS.
>
>We don''t see these issues with BVT scheduler.
>
>Bests
>Jeff
>
>_______________________________________________
>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

On Thu, Jun 29, 2006 at 07:46:57PM +0800, Li, Xin B
wrote:
> But if I only create the windows guest, all is OK.
> So seems we have bug if one physical cpu is used by 2 different VMX
> guest, I''m looking at it.
it seems to be more or less similar with:

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=679

-- 
Vincent Hanquez

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

On Wed, 28 Jun 2006, Ian Pratt wrote:
> > When we use credit scheduler in 64bit hypervisor, we see these issues:
> > + Booting 32bit VMX domain hangs at "ACPI: Unable to locate
RSDP".
> > + Booting 32pae VMX domain will get a kernel panic.
> > + Booting indows SP1/SP2 Guest will crash guest OS.
> > 
> > We don''t see these issues with BVT scheduler.
> 
> Is this specific to 64b hypervisor? We do most HVM testing on 32b PAE
> and haven''t seen these issues.
I am also seeing an instant reboot if I try the credit
scheduler on my x86-64 system.  The reboot happens every
time I try to start a VT guest domain - haven''t tried
paravirt, since I need one of the VT domains :)

Please don''t make the credit scheduler the default until
it actually works.

-- 
All Rights Reversed

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

>On Wed, 28 Jun 2006, Ian Pratt wrote:
>> > When we use credit scheduler in 64bit hypervisor, we see these
issues:
>> > + Booting 32bit VMX domain hangs at "ACPI: Unable to locate
RSDP".
>> > + Booting 32pae VMX domain will get a kernel panic.
>> > + Booting indows SP1/SP2 Guest will crash guest OS.
>> > 
>> > We don''t see these issues with BVT scheduler.
>> 
>> Is this specific to 64b hypervisor? We do most HVM testing on 32b PAE
>> and haven''t seen these issues.
>
>I am also seeing an instant reboot if I try the credit
>scheduler on my x86-64 system.  The reboot happens every
>time I try to start a VT guest domain - haven''t tried
>paravirt, since I need one of the VT domains :)
Have you got any debug output from Xen ? (and are you running a debug 
build?). 
>Please don''t make the credit scheduler the default until
>it actually works.
I''m not sure this is a credit scheduler bug - it seems rather more
likely
to be a vmx bug shaken out by the more aggressive load balancing of the 
new scheduler. Masking such bugs by using another scheduler doesn''t
seem
like a great idea to me.

Of course, difficult to be certain of the exact cause without some debug
output or similar. 


cheers,

S.



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

On Sat, 1 Jul 2006, Steven Hand wrote:
> Have you got any debug output from Xen ? (and are you running a debug 
> build?). 
I have no serial console on this system, and it rebooted
instantly - so unfortunately, no debugging output.

I will try this on one of my test systems at work, which
do have serial console.
> >Please don''t make the credit scheduler the default until
> >it actually works.
> 
> I''m not sure this is a credit scheduler bug - it seems rather more
likely
> to be a vmx bug shaken out by the more aggressive load balancing of the 
> new scheduler. Masking such bugs by using another scheduler
doesn''t seem
> like a great idea to me.
Point taken.  Though at this point I can''t rule out the
scheduler yet, either :)
> Of course, difficult to be certain of the exact cause without some debug
> output or similar. 
*nod*

-- 
All Rights Reversed

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

>>I am also seeing an instant reboot if I try the credit
>>scheduler on my x86-64 system.  The reboot happens every
>>time I try to start a VT guest domain - haven''t tried
>>paravirt, since I need one of the VT domains :)
>
>Have you got any debug output from Xen ? (and are you running a debug 
>build?). 
>
>>Please don''t make the credit scheduler the default until
>>it actually works.
>
>I''m not sure this is a credit scheduler bug - it seems rather 
>more likely
>to be a vmx bug shaken out by the more aggressive load 
>balancing of the 
>new scheduler. Masking such bugs by using another scheduler 
>doesn''t seem
>like a great idea to me.
>
This is caused by a vmcs bug, the root cause is on x86_64, a VMX domain
is killed without any vmentry (caused by "Error: Device 768 (vbd) could
not be connected. Hotplug scripts not working."), but then a VMCLEAR is
still executed on its unlaunched VMCS.
the following patch fixes it.

Signed-off-by: Xin Li <xin.b.li@intel.com>

diff -r 130a5badf2b7 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c       Fri Jun 30 22:02:58 2006 +0100
+++ b/xen/arch/x86/hvm/vmx/vmcs.c       Sat Jul 01 23:10:31 2006 +0800
@@ -67,7 +67,12 @@ static void __vmx_clear_vmcs(void *info)
 static void __vmx_clear_vmcs(void *info)
 {
     struct vcpu *v = info;
+
+    if ( !v->arch.hvm_vmx.launched )
+        return;
+
     __vmpclear(virt_to_maddr(v->arch.hvm_vmx.vmcs));
+
     v->arch.hvm_vmx.active_cpu = -1;
     v->arch.hvm_vmx.launched   = 0;
 }

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

On Sat, 1 Jul 2006, Li, Xin B wrote:
> This is caused by a vmcs bug, the root cause is on x86_64, a VMX domain
> is killed without any vmentry (caused by "Error: Device 768 (vbd)
could
> not be connected. Hotplug scripts not working."), but then a VMCLEAR
is
> still executed on its unlaunched VMCS.
I guess that might explain the lack of console output :)

-- 
All Rights Reversed

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

On 1 Jul 2006, at 16:22, Li, Xin B wrote:
> This is caused by a vmcs bug, the root cause is on x86_64, a VMX domain
> is killed without any vmentry (caused by "Error: Device 768 (vbd)
could
> not be connected. Hotplug scripts not working."), but then a VMCLEAR
is
> still executed on its unlaunched VMCS.
> the following patch fixes it.
>
> Signed-off-by: Xin Li <xin.b.li@intel.com>
This patch is itself buggy: Just because a VMCS hasn''t been launched 
doesn''t mean it hasn''t been activated on some CPU. I think the
original
bug would be better fixed by only calling vmx_clear_vmcs() in 
vmx_destroy_vmcs() if arch_vmx->vmcs != NULL. Even better would be not 
to allocate the VMCS so darn late.

  -- Keir


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

>-----Original Message-----
>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
>Sent: 2006年7月2日 0:02
>To: Li, Xin B
>Cc: xen-devel@lists.xensource.com; Ian Pratt; Rik van Riel; 
>Steven Hand; Zheng, Jeff
>Subject: Re: [Xen-devel] credit scheduler issues in 64bit hypervisor
>
>
>On 1 Jul 2006, at 16:22, Li, Xin B wrote:
>
>> This is caused by a vmcs bug, the root cause is on x86_64, a 
>VMX domain
>> is killed without any vmentry (caused by "Error: Device 768 
>(vbd) could
>> not be connected. Hotplug scripts not working."), but then a 
>VMCLEAR is
>> still executed on its unlaunched VMCS.
>> the following patch fixes it.
>>
>> Signed-off-by: Xin Li <xin.b.li@intel.com>
>
>This patch is itself buggy: Just because a VMCS hasn''t been
launched
>doesn''t mean it hasn''t been activated on some CPU. I think
the
>original 
>bug would be better fixed by only calling vmx_clear_vmcs() in 
>vmx_destroy_vmcs() if arch_vmx->vmcs != NULL. Even better would be not 
>to allocate the VMCS so darn late.
>
Yes, it''s buggy, and prevent the first vmclear to a vmcs.
-Xin

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

>>-----Original Message-----
>>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
>>Sent: 2006年7月2日 0:02
>>To: Li, Xin B
>>Cc: xen-devel@lists.xensource.com; Ian Pratt; Rik van Riel; 
>>Steven Hand; Zheng, Jeff
>>Subject: Re: [Xen-devel] credit scheduler issues in 64bit hypervisor
>>
>>
>>On 1 Jul 2006, at 16:22, Li, Xin B wrote:
>>
>>> This is caused by a vmcs bug, the root cause is on x86_64, a 
>>VMX domain
>>> is killed without any vmentry (caused by "Error: Device 768 
>>(vbd) could
>>> not be connected. Hotplug scripts not working."), but then a 
>>VMCLEAR is
>>> still executed on its unlaunched VMCS.
>>> the following patch fixes it.
>>>
>>> Signed-off-by: Xin Li <xin.b.li@intel.com>
>>
>>This patch is itself buggy: Just because a VMCS hasn''t been
launched
>>doesn''t mean it hasn''t been activated on some CPU. 
Hmm, thinking about a VMCS is migrating from cpu A to cpu B, and on cpu A
vmclear has been executed, but just before the VMCS is launched on cpu B, the
domain is killed, what will happen?
I''m not sure if vmclear on a VMCS in cleared state is allowed. If not,
we still need this fix.

>>I think the original 
>>bug would be better fixed by only calling vmx_clear_vmcs() in 
>>vmx_destroy_vmcs() if arch_vmx->vmcs != NULL. Even better 
>would be not 
>>to allocate the VMCS so darn late.
>>
>
>Yes, it''s buggy, and prevent the first vmclear to a vmcs.
I found even without my fix the first vmclear to a newly allocated vmcs is
prevented, this is because arch_vmx->active_cpu = -1is executed  before
vmx_clear_vmcs(v) in construct_vmcs().
We may workaound it by setting active_cpu to smp_processor_id(), and launched to
1here, but surely this is not what we want.

-Xin

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

On 2 Jul 2006, at 05:01, Li, Xin B wrote:
>>> This patch is itself buggy: Just because a VMCS hasn''t
been launched
>>> doesn''t mean it hasn''t been activated on some
CPU.
>
> Hmm, thinking about a VMCS is migrating from cpu A to cpu B, and on 
> cpu A vmclear has been executed, but just before the VMCS is launched 
> on cpu B, the domain is killed, what will happen?
> I''m not sure if vmclear on a VMCS in cleared state is allowed. If
not,
> we still need this fix.
active_cpu will be B in this case, so we''ll execute VMCLEAR on CPU B. 
''Launched'' is just an extra sub-state of an active VMCS. This
is all
taken from Section 20.1 of Vol. 3 of the Intel Reference Manual.
>>> I think the original
>>> bug would be better fixed by only calling vmx_clear_vmcs() in
>>> vmx_destroy_vmcs() if arch_vmx->vmcs != NULL. Even better
>> would be not
>>> to allocate the VMCS so darn late.
>>>
>>
>> Yes, it''s buggy, and prevent the first vmclear to a vmcs.
>
> I found even without my fix the first vmclear to a newly allocated 
> vmcs is prevented, this is because arch_vmx->active_cpu = -1is 
> executed  before vmx_clear_vmcs(v) in construct_vmcs().
> We may workaound it by setting active_cpu to smp_processor_id(), and 
> launched to 1here, but surely this is not what we want.
Yes, that''s broken. I''ll fix to use __vmx_clear_vmcs().

  -- Keir


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

>> This is caused by a vmcs bug, the root cause is on x86_64, a 
>VMX domain
>> is killed without any vmentry (caused by "Error: Device 768 
>(vbd) could
>> not be connected. Hotplug scripts not working."), but then a 
>VMCLEAR is
>> still executed on its unlaunched VMCS.
>> the following patch fixes it.
>>
>> Signed-off-by: Xin Li <xin.b.li@intel.com>
>
>This patch is itself buggy: Just because a VMCS hasn''t been
launched
>doesn''t mean it hasn''t been activated on some CPU. I think
the
>original 
>bug would be better fixed by only calling vmx_clear_vmcs() in 
>vmx_destroy_vmcs() if arch_vmx->vmcs != NULL. Even better would be not 
>to allocate the VMCS so darn late.
>
Yes, such a fix should work.

diff -r 130a5badf2b7 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c       Fri Jun 30 22:02:58 2006 +0100
+++ b/xen/arch/x86/hvm/vmx/vmcs.c       Sun Jul 02 22:33:47 2006 +0800
@@ -495,6 +511,9 @@ void vmx_destroy_vmcs(struct vcpu *v)
 void vmx_destroy_vmcs(struct vcpu *v)
 {
     struct arch_vmx_struct *arch_vmx = &v->arch.hvm_vmx;
+
+    if ( arch_vmx->vmcs == NULL )
+        return;

     vmx_clear_vmcs(v);

Hmm, I still prefer allocating VMCS just before launching, can you
explain your concerns?
thanks
-Xin

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

On 2 Jul 2006, at 15:38, Li, Xin B wrote:
> Hmm, I still prefer allocating VMCS just before launching, can you
> explain your concerns?
If the VMCS allocation fails you have no path for indicating failure to 
the caller -- context switch is always expected to succeed. Critical 
dynamic allocations should really happen on domain/vcpu creation. Also 
the short VMCS lifetime (first launch to dom0_destroy) means that 
getvcpucontext at other times -- on a very new HVM guest or one very 
close to death -- probably crashes or hangs right now.

  -- Keir


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

>> Hmm, I still prefer allocating VMCS just before launching, can you
>> explain your concerns?
>
>If the VMCS allocation fails you have no path for indicating 
>failure to 
>the caller -- context switch is always expected to succeed. Critical 
>dynamic allocations should really happen on domain/vcpu creation. Also 
>the short VMCS lifetime (first launch to dom0_destroy) means that 
>getvcpucontext at other times -- on a very new HVM guest or one very 
>close to death -- probably crashes or hangs right now.
>
OK, that''s reasonable :-), I''ll send out the patch.
Thanks
-Xin

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

>>If the VMCS allocation fails you have no path for indicating 
>>failure to 
>>the caller -- context switch is always expected to succeed. Critical 
>>dynamic allocations should really happen on domain/vcpu 
>creation. Also 
>>the short VMCS lifetime (first launch to dom0_destroy) means that 
>>getvcpucontext at other times -- on a very new HVM guest or one very 
>>close to death -- probably crashes or hangs right now.
>>
>
>OK, that''s reasonable :-), I''ll send out the patch.
This patch is to move vmcs and IO bitmap allocation into
vmx_initialize_guest_resources.
And some necessary code rearrangement.

Signed-off-by: Xin Li <xin.b.li@intel.com>



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

On 4 Jul 2006, at 13:00, Li, Xin B wrote:
>> OK, that''s reasonable :-), I''ll send out the patch.
>
> This patch is to move vmcs and IO bitmap allocation into
> vmx_initialize_guest_resources.
> And some necessary code rearrangement.
This patch messes with more stuff than it needs to. In particular, 
every place we VMCLEAR/VMPTRLD we expect the operation to succeed -- 
crashing on error is the most sensible thing to do. I don''t see that 
returning error to the caller is helpful, and in fact you have callers 
who don''t even check the error return. It keeps the interface to those 
functions simpler to have them return void and for them to bug out 
internally if they fail (as they currently do).

  -- Keir


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

>>> OK, that''s reasonable :-), I''ll send out the
patch.
>>
>> This patch is to move vmcs and IO bitmap allocation into
>> vmx_initialize_guest_resources.
>> And some necessary code rearrangement.
>
>This patch messes with more stuff than it needs to.

OK, I splitted it. This patch only moves vmcs and IO bitmap allocation
into vmx_initialize_guest_resources.

> In particular, 
>every place we VMCLEAR/VMPTRLD we expect the operation to succeed -- 
>crashing on error is the most sensible thing to do. I don''t see
that
>returning error to the caller is helpful, and in fact you have callers 
>who don''t even check the error return. It keeps the interface to
those
>functions simpler to have them return void and for them to bug out 
>internally if they fail (as they currently do).
>
I really don''t like crashing on such errors, but yes, this small
changes
to VMCLEAR/VMPTRLD make no sense at this point.
For long term, we need follow IA32 SPEC to handle all the faliure VMX
instruction cases, basically we should crash the domain not the system,
and give some basic description.
I will send separate patches later, maybe after 3.0.3,
-Xin


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

On 5 Jul 2006, at 02:51, Li, Xin B wrote:
> I really don''t like crashing on such errors, but yes, this small 
> changes
> to VMCLEAR/VMPTRLD make no sense at this point.
> For long term, we need follow IA32 SPEC to handle all the faliure VMX
> instruction cases, basically we should crash the domain not the system,
> and give some basic description.
Are there any cases where the domain itself can cause those 
instructions to fail? I agree that we should have a function that reads 
and decodes the reason for failure, and maybe also dumps other 
interesting state, but BUG still seems the right failure mode to me.

  -- Keir


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