| Message ID | 1479762047-29431-8-git-send-email-boris.ostrovsky@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 21.11.16 at 22:00, <boris.ostrovsky@oracle.com> 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@oracle.com> > --- > CC: Paul Durrant <paul.durrant@citrix.com> > --- > 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()? Jan
On 11/22/2016 06:34 AM, Jan Beulich wrote: >>>> On 21.11.16 at 22:00, <boris.ostrovsky@oracle.com> 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@oracle.com> >> --- >> CC: Paul Durrant <paul.durrant@citrix.com> >> --- >> 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? -boris
>>> On 22.11.16 at 13:38, <boris.ostrovsky@oracle.com> wrote: > > On 11/22/2016 06:34 AM, Jan Beulich wrote: >>>>> On 21.11.16 at 22:00, <boris.ostrovsky@oracle.com> 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@oracle.com> >>> --- >>> CC: Paul Durrant <paul.durrant@citrix.com> >>> --- >>> 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? Jan
On 11/22/2016 09:08 AM, Jan Beulich wrote: >>>> On 22.11.16 at 13:38, <boris.ostrovsky@oracle.com> wrote: >> On 11/22/2016 06:34 AM, Jan Beulich wrote: >>>>>> On 21.11.16 at 22:00, <boris.ostrovsky@oracle.com> 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@oracle.com> >>>> --- >>>> CC: Paul Durrant <paul.durrant@citrix.com> >>>> --- >>>> 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
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@oracle.com> wrote: > >> On 11/22/2016 06:34 AM, Jan Beulich wrote: > >>>>>> On 21.11.16 at 22:00, <boris.ostrovsky@oracle.com> 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@oracle.com> > >>>> --- > >>>> CC: Paul Durrant <paul.durrant@citrix.com> > >>>> --- > >>>> 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.
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index d2245e2..51bb399 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -1380,6 +1380,12 @@ static int hvm_access_cf8( return X86EMUL_UNHANDLEABLE; } +static int acpi_ioaccess( + int dir, unsigned int port, unsigned int bytes, uint32_t *val) +{ + return X86EMUL_UNHANDLEABLE; +} + void hvm_ioreq_init(struct domain *d) { spin_lock_init(&d->arch.hvm_domain.ioreq_server.lock); @@ -1387,6 +1393,18 @@ void hvm_ioreq_init(struct domain *d) if ( !is_pvh_domain(d) ) register_portio_handler(d, 0xcf8, 4, hvm_access_cf8); + + if ( !has_acpi_ff(d) ) + { + /* Online CPU map, see DSDT's PRST region. */ + register_portio_handler(d, XEN_ACPI_CPU_MAP, + XEN_ACPI_CPU_MAP_LEN, acpi_ioaccess); + + register_portio_handler(d, ACPI_GPE0_BLK_ADDRESS_V1, + ACPI_GPE0_BLK_LEN_V1, acpi_ioaccess); + register_portio_handler(d, ACPI_PM1A_EVT_BLK_ADDRESS_V1, + ACPI_PM1A_EVT_BLK_LEN, acpi_ioaccess); + } } /* diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h index f6a40eb..33f862f 100644 --- a/xen/include/asm-x86/domain.h +++ b/xen/include/asm-x86/domain.h @@ -425,6 +425,7 @@ struct arch_domain #define has_vvga(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_VGA)) #define has_viommu(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_IOMMU)) #define has_vpit(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT)) +#define has_acpi_ff(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_ACPI_FF)) #define has_arch_pdevs(d) (!list_empty(&(d)->arch.pdev_list)) diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h index cdd93c1..04c78ec 100644 --- a/xen/include/public/arch-x86/xen.h +++ b/xen/include/public/arch-x86/xen.h @@ -283,12 +283,14 @@ struct xen_arch_domainconfig { #define XEN_X86_EMU_IOMMU (1U<<_XEN_X86_EMU_IOMMU) #define _XEN_X86_EMU_PIT 8 #define XEN_X86_EMU_PIT (1U<<_XEN_X86_EMU_PIT) +#define _XEN_X86_EMU_ACPI_FF 9 +#define XEN_X86_EMU_ACPI_FF (1U<<_XEN_X86_EMU_ACPI_FF) #define XEN_X86_EMU_ALL (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET | \ XEN_X86_EMU_PM | XEN_X86_EMU_RTC | \ XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC | \ XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU | \ - XEN_X86_EMU_PIT) + XEN_X86_EMU_PIT | XEN_X86_EMU_ACPI_FF) uint32_t emulation_flags; }; #endif
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@oracle.com> --- CC: Paul Durrant <paul.durrant@citrix.com> --- Changes in v3: * acpi_ioaccess() returns X86EMUL_UNHANDLEABLE * Renamed XEN_X86_EMU_IOREQ_CPUHP to XEN_X86_EMU_ACPI_FF (together with corresponding has_*()) xen/arch/x86/hvm/ioreq.c | 18 ++++++++++++++++++ xen/include/asm-x86/domain.h | 1 + xen/include/public/arch-x86/xen.h | 4 +++- 3 files changed, 22 insertions(+), 1 deletion(-)