[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 0/4] VMX: Properly handle pi descriptor and per-cpu blocking list



On Fri, 2016-06-24 at 14:49 +0100, George Dunlap wrote:
> On 24/06/16 14:42, Wu, Feng wrote:
> > Here is my understanding, if the guest has nothing to do, it will
> > call HLT, and Xen hypervisor will call vcpu_block(), if we don't
> > block the vCPU and return to guest, guest will continue to run
> > HLT if it still has nothing to do. 
> As it happens, most operating systems will handle this situation just
> fine; but I'm not sure this is something we want to rely on.
> 
Exactly! I indeed don't think it would be wise to rely on that. But
more than that, I don't think we want to waste pCPU cycles considering
runnable, and hence potentially scheduling, vCPUs that have HTL-ed!

That may be acceptable in emulators like Bochs or "plain" Qemu... Xen
is an hypervisor, it does virtualization, and this is one of the points
of virtualization, IMO: when a virtual CPU has nothing to do, use the
physical CPU to execute _another_ virtual CPU.

And even if that would be just for the sake of handling a corner case,
I still think that:
 - we really want to try as hard as possible to avoid it,
 - if we really can't, we want a big comment in the code for:
  * explaining what actually happens,
  * proving that it will be something limited in time (and preferably
    rather short),
  * providing an explanations of why we could not do better.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.