[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest
On Tue, Oct 17, 2017 at 08:16:47PM +0800, Haozhong Zhang wrote: > On 10/17/17 13:45 +0200, Paolo Bonzini wrote: > > On 14/10/2017 00:46, Stefano Stabellini wrote: > > > On Fri, 13 Oct 2017, Jan Beulich wrote: > > >>>>> On 13.10.17 at 13:13, <haozhong.zhang@xxxxxxxxx> wrote: > > >>> To Jan, Andrew, Stefano and Anthony, > > >>> > > >>> what do you think about allowing QEMU to build the entire guest ACPI > > >>> and letting SeaBIOS to load it? ACPI builder code in hvmloader is > > >>> still there and just bypassed in this case. > > >> Well, if that can be made work in a non-quirky way and without > > >> loss of functionality, I'd probably be fine. I do think, however, > > >> that there's a reason this is being handled in hvmloader right now. > > > And not to discourage you, just as a clarification, you'll also need to > > > consider backward compatibility: unless the tables are identical, I > > > imagine we'll have to keep using the old tables for already installed > > > virtual machines. > > > > I agree. Some of them are already identical, some are not but the QEMU > > version should be okay, and for yet more it's probably better to keep > > the Xen-specific parts in hvmloader. > > > > The good thing is that it's possible to proceed incrementally once you > > have the hvmloader support for merging the QEMU and hvmloader RSDT or > > XSDT (whatever you are using), starting with just NVDIMM and proceeding > > later with whatever you see fit. > > > > I'll have a try to check how much the differences would affect. If it > would not take too much work, I'd like to adapt Xen NVDIMM enabling > patches to the all QEMU built ACPI. Otherwise, I'll fall back to Paolo > and MST's suggestions. I don't agree with the end goal of fully switching to the QEMU build ACPI tables. First of all, the only entity that has all the information about the guest it's the toolstack, and so it should be the one in control of the ACPI tables. Also, Xen guests can use several device models concurrently (via the ioreq server interface), and each should be able to contribute to the information presented in the ACPI tables. Intel is also working on adding IOMMU emulation to the Xen hypervisor, in which case the vIOMMU ACPI tables should be created by the toolstack and not QEMU. And finally keep in mind that there are Xen guests (PVH) that use ACPI tables but not QEMU. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |