Re: [Xen-devel] [PATCH v4 06/15] domctl: Add XEN_DOMCTL_acpi_access

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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.

-boris


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