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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 12/12/2016 09:02 AM, Jan Beulich wrote:
>>>> On 12.12.16 at 14:08, <boris.ostrovsky@oracle.com> wrote:
>> On 12/02/2016 02:48 AM, Jan Beulich wrote:
>>>>>> On 01.12.16 at 17:43, <boris.ostrovsky@oracle.com> 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.

When would we ever need to access anything larger? I'd think that the
common case is a few (1-4) bytes. The one instance when this is not true
is the VCPU map and 256 bytes allow for 16K VCPUs, which I suspect we
won't reach in a while.

But I can increase the length to uint16_t if you feel it's would be better.

-boris


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