Re: [Xen-devel] [PATCH qemu-traditional] ioreq: Support 32-bit default_ioport_* accesses

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 05/25/2016 11:22 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit 
> default_ioport_* accesses"):
>> IIUIC, the Linux/ACPICA patch makes ACPICA use correct field in ACPI's
>> Generic Address Structure (section 5.2.3.2 in the 6.0 spec). Before the
>> patch it used register's bit_width and now it will use access_size.
>> According to the spec access_size 0 means undefined/legacy access.
> I see.  (Well, sort of.)
>
>> I just looked at what hvmloader provides and at least for FADT
>> address_size is 0. And I wonder whether ACPICA uses 4-byte-access for
>> these cases.
> If 0 is "undefined/legacy access", shouldn't it be using the
> register's bit width ?  Ie, isn't this then a bug in ACPICA ?
>
>> So maybe instead of trying to patch qemu-trad I should see if I can make
>> hvmloader provide proper access size. Let me poke at that.
> If this "access size" attribute is new, things should work without it,
> surely ?

This is what the spec says:

AccessSize evaluates to an 8-bit integer that specifies the size of data
values used when accessing the
address space as follows:
0 - Undefined (legacy)
1 - Byte access
2 - Word access
3 - DWord access
4 - QWord access
The 8-bit field DescriptorName . _ASZ is automatically created in order
to refer to this portion of the
resource descriptor. See _ASZ (page 368) for more information. For
backwards compatibility, the
AccesSize parameter is optional when invoking the Register macro. If the
AccessSize parameter is
not supplied then the AccessSize field will be set to zero. In this
case, OSPM will assume the access
size.

I don't think I understand what the last sentence means. Does it imply
that SW can do whatever it thinks is appropriate?


-boris

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