Re: [Xen-devel] [PATCH v2 08/11] xen/hvmlite: Extend APIC operations for HVMlite guests

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 02/04/2016 07:14 AM, Roger Pau Monné wrote:
> El 4/2/16 a les 11:04, David Vrabel ha escrit:
> > On 01/02/16 15:38, Boris Ostrovsky wrote:
> > > HVMlite guests need to be viewed as having APIC, otherwise smpboot code,
> > > for example, will complain.
> > I think we should consider always giving HVMlite guests an emulated
> > APIC.  I think this eliminates one of the biggest differences between
> > HVMlite and native/KVM guests and will reduce the risk of future
> > breakage in this area.
> Right, I'm not opposed to that, but I think we should keep the hypercall
> interface in order to bring up vCPUs. IMHO it's useful for unikernels
> for example (do those support SMP?), and in general allows for
> easier/faster CPU-bringup as compared to bare metal.
As I mentioned in another reply, we can manage without emulated apic by 
slightly extending PV APIC. However, it is rather fragile and I think 
not having to do this would be a great improvement from code reliability 
POV. And with Intel's vAPIC (and AMD's equivalent eventually, I suppose) 
we should get performance improvement as well.
What was the reason for not providing it? ACPI?

> Then if we indeed decide to provide and emulated lapic, should we also
> at least provide the ACPI MADT table in order to enumerate them?
This brings another question that I was going to ask. In the NVDIMM 
thread there is a discussion about where to implement ACPI tables and I 
think people are leaning toward doing in it qemu. With HVMlite we can 
only (??) implement MADT (and whatever we add later) in the toolstack 
and so we will have 3 places (qemu, hvmloader, toolstack) that build 
ACPI tables.
Can we have all this done in one place? Perhaps keep this code as a library?

-boris

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