[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

 


Rackspace

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