[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses
On 11/22/2016 09:08 AM, Jan Beulich wrote: >>>> On 22.11.16 at 13:38, <boris.ostrovsky@xxxxxxxxxx> wrote: >> On 11/22/2016 06:34 AM, Jan Beulich wrote: >>>>>> On 21.11.16 at 22:00, <boris.ostrovsky@xxxxxxxxxx> wrote: >>>> PVH guests will have ACPI accesses emulated by the hypervisor >>>> as opposed to QEMU (as is the case for HVM guests) >>>> >>>> Support for IOREQ server emulation of CPU hotplug is indicated >>>> by XEN_X86_EMU_IOREQ_CPUHP flag. >>>> >>>> Logic for the handler will be provided by a later patch. >>>> >>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> >>>> --- >>>> CC: Paul Durrant <paul.durrant@xxxxxxxxxx> >>>> --- >>>> Changes in v3: >>>> * acpi_ioaccess() returns X86EMUL_UNHANDLEABLE >>>> * Renamed XEN_X86_EMU_IOREQ_CPUHP to XEN_X86_EMU_ACPI_FF (together >>>> with corresponding has_*()) >>> Except in the description above. >>> >>> Also, while I'm fine with the flag rename, has_acpi_ff() looks wrong >>> (or at least misleading) to me: Both HVM and PVHv2 have fixed >>> function hardware emulated, they only differ in who the emulator >>> is. Reduced hardware, if we would emulate such down the road, >>> otoh might then indeed come without. So how about one of >>> has_xen_acpi_ff() or has_dm_acpi_ff()? >> I think the latter is better. But then to keep flag names in sync with >> has_*() macros, how about XEN_X86_EMU_DM_ACPI_FF? > Not sure - the flag name, as said, seemed fine to me before, and I > don't overly care about the two names fully matching up. Maybe > others here have an opinion? Any preferences? Roger? -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |