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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.12.16 at 14:08, <boris.ostrovsky@xxxxxxxxxx> wrote:

> 
> On 12/02/2016 02:48 AM, Jan Beulich wrote:
>>>>> 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.
> 
> Are there any registers that are not byte-aligned or not whole number of 
> bytes?
> 
> I am thinking about dropping bit_offset (along with access_width) and 
> making bit_width (byte_)width. And keeping the latter as uint8_t will 
> also implicitly limit register size to 256 bytes which I think is a 
> reasonable size limit.

Since we're doing the emulation (and hence defining the registers)
we could require no such unusual registers. This would be something
we can't simplify only if we foresee ever needing to hand through a
hardware register without interposing any emulation.

Whether limiting to 256 bytes is reasonable I'm not so sure, otoh.

Jan


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