Hi,
I was just going through the (svm.c) svm_vmexit_handler() in the SVM
part of Xen, and saw that:
case VMEXIT_TASK_SWITCH:
__hvm_bug(regs);
break;
task switches are not intercepted and handled. I was wondering if it
is not so, then how do you manage consistency of the VM if the Guest
does a task switch (which could alter the value of CR3)? Am I missing
something here?
Thanks,
Vivek
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 27/10/06 7:28 am, "Vivek Mohan" <vivek.mt@gmail.com> wrote:> I was just going through the (svm.c) svm_vmexit_handler() in the SVM > part of Xen, and saw that: > > case VMEXIT_TASK_SWITCH: > __hvm_bug(regs); > break; > > task switches are not intercepted and handled. I was wondering if it > is not so, then how do you manage consistency of the VM if the Guest > does a task switch (which could alter the value of CR3)? Am I missing > something here?Task switches aren''t currently supported. The guest is marked as ''crashed'' if it attempts to do one. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Vivek Mohan > Sent: 27 October 2006 07:29 > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] Task Switching and Xen-SVM > > Hi, > > I was just going through the (svm.c) svm_vmexit_handler() in the SVM > part of Xen, and saw that: > > case VMEXIT_TASK_SWITCH: > __hvm_bug(regs); > break; > > task switches are not intercepted and handled. I was wondering if it > is not so, then how do you manage consistency of the VM if the Guest > does a task switch (which could alter the value of CR3)? Am I missing > something here?AMD and Intel are doing the same thing here. Do you actually know of any (32-bit) OS that uses task switching? In my experience, it''s horribly slow (because it generally saves/restores more of the context than is necessary). Of course, in 64-bit mode it''s not even allowed, all task-management features have been removed... I''m saying 32-bit OS, since there''s probably some 16-bit OS''s out there that do use task-switching, but those OS''s are not able to run on current Xen anyways, since Xen in it''s current form is very poor at supporting segments with base != 0 in protected mode. So far I''ve only seen a few rare reports of anyone actually wishing to run a 16-bit OS... -- Mats> > Thanks, > Vivek > > _______________________________________________ > 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 27/10/06 9:59 am, "Petersson, Mats" <Mats.Petersson@amd.com> wrote:> AMD and Intel are doing the same thing here. > > Do you actually know of any (32-bit) OS that uses task switching? In my > experience, it''s horribly slow (because it generally saves/restores more > of the context than is necessary). Of course, in 64-bit mode it''s not > even allowed, all task-management features have been removed... I''m > saying 32-bit OS, since there''s probably some 16-bit OS''s out there that > do use task-switching, but those OS''s are not able to run on current Xen > anyways, since Xen in it''s current form is very poor at supporting > segments with base != 0 in protected mode. So far I''ve only seen a few > rare reports of anyone actually wishing to run a 16-bit OS...It''s primarily used to obtain a fresh context when things have gobe very bad (so, for example, double-fault and NMI exceptions often specify a task gate in the IDT). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Do you actually know of any (32-bit) OS that uses task switching?It''s often used in double fault, NMI and MCA handlers, all of which are typically fatal. It would still be good to have them implemented to get a decent oops message out though. Ian> In my > experience, it''s horribly slow (because it generally saves/restoresmore> of the context than is necessary). Of course, in 64-bit mode it''s not > even allowed, all task-management features have been removed... I''m > saying 32-bit OS, since there''s probably some 16-bit OS''s out therethat> do use task-switching, but those OS''s are not able to run on currentXen> anyways, since Xen in it''s current form is very poor at supporting > segments with base != 0 in protected mode. So far I''ve only seen a few > rare reports of anyone actually wishing to run a 16-bit OS... > > -- > Mats > > > > Thanks, > > Vivek > > > > _______________________________________________ > > 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
True, not really many OSes, atleast the ones that matter, use task switching, but I was just wondering how well Xen w/ HVM would scale as a full architectural simulator - apparently not. Any idea why SVM (or VMX) have no support for non-intrusive stepwise execution of guest VMs? -Vivek On 10/27/06, Petersson, Mats <Mats.Petersson@amd.com> wrote:> > -----Original Message----- > > From: xen-devel-bounces@lists.xensource.com > > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > > Vivek Mohan > > Sent: 27 October 2006 07:29 > > To: xen-devel@lists.xensource.com > > Subject: [Xen-devel] Task Switching and Xen-SVM > > > > Hi, > > > > I was just going through the (svm.c) svm_vmexit_handler() in the SVM > > part of Xen, and saw that: > > > > case VMEXIT_TASK_SWITCH: > > __hvm_bug(regs); > > break; > > > > task switches are not intercepted and handled. I was wondering if it > > is not so, then how do you manage consistency of the VM if the Guest > > does a task switch (which could alter the value of CR3)? Am I missing > > something here? > > AMD and Intel are doing the same thing here. > > Do you actually know of any (32-bit) OS that uses task switching? In my > experience, it''s horribly slow (because it generally saves/restores more > of the context than is necessary). Of course, in 64-bit mode it''s not > even allowed, all task-management features have been removed... I''m > saying 32-bit OS, since there''s probably some 16-bit OS''s out there that > do use task-switching, but those OS''s are not able to run on current Xen > anyways, since Xen in it''s current form is very poor at supporting > segments with base != 0 in protected mode. So far I''ve only seen a few > rare reports of anyone actually wishing to run a 16-bit OS... > > -- > Mats > > > > Thanks, > > Vivek > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > > > > >-- http://sig9.com/vivek/ Sig9.com - Sugar for your brain _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: Ian Pratt [mailto:m+Ian.Pratt@cl.cam.ac.uk] > Sent: 27 October 2006 10:07 > To: Petersson, Mats; Vivek Mohan; xen-devel@lists.xensource.com > Cc: ian.pratt@cl.cam.ac.uk > Subject: RE: [Xen-devel] Task Switching and Xen-SVM > > > Do you actually know of any (32-bit) OS that uses task switching? > > It''s often used in double fault, NMI and MCA handlers, all of > which are > typically fatal. > > It would still be good to have them implemented to get a decent oops > message out though.Good point. On the other hand, double-fault is caught by SVM (vmx.c doesn''t seem to do the same here) and debug info printed to the console before we ship the DF back into the guest, so it should be detectable what went wrong there. NMI and MCA shouldn''t happen in the guest - at least not in the current architecture where NMI and MCA are all handled in Xen. Is there a reasonable cause for this to change anytime soon? [How do we know what guest cause MCE - as memory related MCE''s happen on the processor owning the memory, and may also be caused by the "memory scrubber". And it doesn''t really make much sense to give MCE''s to the guest, as it''s generally a hardware related problem.] NMI''s to guest may make more sense if we take for example performance counters... Not sure if this is important or not... Performance counting in the guest is another "interesting" topic where it''s hard for the guest to make sense of the numbers without knowing about the hypervisor, I think... -- Mats> > Ian > > > In my > > experience, it''s horribly slow (because it generally saves/restores > more > > of the context than is necessary). Of course, in 64-bit > mode it''s not > > even allowed, all task-management features have been removed... I''m > > saying 32-bit OS, since there''s probably some 16-bit OS''s out there > that > > do use task-switching, but those OS''s are not able to run on current > Xen > > anyways, since Xen in it''s current form is very poor at supporting > > segments with base != 0 in protected mode. So far I''ve only > seen a few > > rare reports of anyone actually wishing to run a 16-bit OS... > > > > -- > > Mats > > > > > > Thanks, > > > Vivek > > > > > > _______________________________________________ > > > 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
> > > Do you actually know of any (32-bit) OS that uses task switching? > > > > It''s often used in double fault, NMI and MCA handlers, all of > > which are > > typically fatal. > > > > It would still be good to have them implemented to get a decent oops > > message out though. > > NMI and MCA shouldn''t happen in the guest - at least not in thecurrent> architecture where NMI and MCA are all handled in Xen. Is there a > reasonable cause for this to change anytime soon? [How do we know what > guest cause MCE - as memory related MCE''s happen on the processorowning> the memory, and may also be caused by the "memory scrubber". And it > doesn''t really make much sense to give MCE''s to the guest, as it''s > generally a hardware related problem.] > > NMI''s to guest may make more sense if we take for example performance > counters... Not sure if this is important or not... Performancecounting> in the guest is another "interesting" topic where it''s hard for the > guest to make sense of the numbers without knowing about thehypervisor,> I think...Well, having the s/w equivalent of the NMI ''dump'' button would be useful. Ian> -- > Mats > > > > Ian > > > > > In my > > > experience, it''s horribly slow (because it generallysaves/restores> > more > > > of the context than is necessary). Of course, in 64-bit > > mode it''s not > > > even allowed, all task-management features have been removed...I''m> > > saying 32-bit OS, since there''s probably some 16-bit OS''s outthere> > that > > > do use task-switching, but those OS''s are not able to run oncurrent> > Xen > > > anyways, since Xen in it''s current form is very poor at supporting > > > segments with base != 0 in protected mode. So far I''ve only > > seen a few > > > rare reports of anyone actually wishing to run a 16-bit OS... > > > > > > -- > > > Mats > > > > > > > > Thanks, > > > > Vivek > > > > > > > > _______________________________________________ > > > > 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