[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 06/15] domctl: Add XEN_DOMCTL_acpi_access
>>> On 01.12.16 at 17:43, <boris.ostrovsky@xxxxxxxxxx> wrote: > On 12/01/2016 11:06 AM, Jan Beulich wrote: >> >>> +++ b/xen/include/public/domctl.h >>> @@ -1144,6 +1144,29 @@ struct xen_domctl_psr_cat_op { >>> typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t; >>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t); >>> >>> +/* ACPI Generic Address Structure */ >>> +typedef struct gas { >> xen_acpi_gas >> >>> +#define XEN_ACPI_SYSTEM_MEMORY 0 >>> +#define XEN_ACPI_SYSTEM_IO 1 >>> + uint8_t space_id; /* Address space */ >>> + uint8_t bit_width; /* Size in bits of given register */ >>> + uint8_t bit_offset; /* Bit offset within the register */ >>> + uint8_t access_width; /* Minimum Access size (ACPI 3.0) */ >>> + uint64_t address; /* 64-bit address of register */ >> uint64_aligned_t with explicit padding added ahead of it. >> >> And then there's the question of what uses of this will look like: >> I'm not convinced we need to stick to the exact ACPI layout >> here, unless you expect (or could imagine) for the tool stack to >> hold GAS structures coming from elsewhere in its hands. If we >> don't follow the layout as strictly, we could namely widen >> bit_width (and maybe bit_offset) to allow for larger transfers >> in one go. And in such a relaxed model I don't think we'd need >> access_width at all as a field. > > There is indeed no current need to use actual ACPI GAS layout but then > it's not GAS, really, and should be named something else. Which of course is fine by me; I had referred to that structure only for the underlying principle of specifying how to access the data. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |