qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/27] ACPI hardware-reduced support


From: Samuel Ortiz
Subject: Re: [Qemu-devel] [PATCH 00/27] ACPI hardware-reduced support
Date: Tue, 23 Oct 2018 11:00:18 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Oct 22, 2018 at 05:28:54PM -0400, Michael S. Tsirkin wrote:
> On Mon, Oct 22, 2018 at 08:36:30PM +0200, Samuel Ortiz wrote:
> > This patch set implements support for the ACPI hardware-reduced
> > specification.
> > 
> > The changes are coming from the NEMU [1] project where we're defining
> > a new x86 machine type: i386/virt. This is an EFI only, ACPI
> > hardware-reduced platform and as such we had to implement support
> > for the latter.
> > 
> > As a preliminary for adding hardware-reduced support to QEMU, we did
> > some ACPI code reorganization with the following goals:
> > 
> > * Share as much as possible of the current ACPI build APIs between
> >   legacy and hardware-reduced ACPI.
> > * Share the ACPI build code across machine types and architectures and
> >   remove the typical PC machine type dependency.
> >   Eventually we hope to see arm/virt also re-use much of that code.
> > 
> > The rest of the patchset adds the hardware-reduced support on top of
> > this code reorganization. Here again, the implementation is machine
> > type, platform and architecture independent.
> > 
> > [1] https://github.com/intel/nemu
> 
> 
> Thanks for the patch!
> I'm traveling so won't be able to review until next week.
No problem. I'm assuming you'll be attending the KVM Forum, Rob Bradford
and myself will be there as well.


> I wonder whether the code can be refactored slightly differently:
> instead of common code calling out to platform specific one,
> have platform code call out to generic one.
> That would avoid indicectiin but I'm not sure at what cost
> in complexity.
I may be misunderstanding your point, so forgive me if that's the case.
But the code refactoring actually lead to both of the code paths you're
describing. The generic code calls into platform specific hooks for
potentially calling custom ACPI tables, but the platform code also uses
the now shared generic code.

> Still that's a generic question as I have not looked at the
> patches in depth.
Looking forward to getting your review.

Cheers,
Samuel.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]