Re: [Xen-devel] [PATCH v3 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Nov 28, 2016 at 10:16:33AM -0500, Boris Ostrovsky wrote:
> 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?

I don't really have a strong opinion, so far we have named all the macros after 
s/XEN_X86_EMU//, so if the macro is named has_dm_acpi_ff the mask should be 
XEN_X86_EMU_DM_ACPI_FF (but again this is more for coherence that anything 
else).

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel