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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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