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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56B359A5.40202@oracle.com>
Date:	Thu, 4 Feb 2016 09:01:09 -0500
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	Roger Pau Monné <roger.pau@...rix.com>,
	David Vrabel <david.vrabel@...rix.com>, konrad.wilk@...cle.com
Cc:	xen-devel@...ts.xenproject.org, mcgrof@...e.com,
	linux-kernel@...r.kernel.org
Subject: 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?

-boris