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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.12.16 at 17:19, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 12/12/2016 09:02 AM, Jan Beulich wrote:
>>>>> 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.
> 
> 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.

It's domctl, so we can change it later anyway. As said - I'm not
really sure here.

Jan


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