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

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

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?


Xen-devel mailing list



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