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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 05/23/2016 08:02 AM, Wei Liu wrote:
> On Fri, May 20, 2016 at 09:52:40AM -0400, Boris Ostrovsky wrote:
>> Recent changes in ACPICA (specifically, Linux commit 66b1ed5aa8dd ("ACPICA:
>> ACPI 2.0, Hardware: Add access_width/bit_offset support for
>> acpi_hw_write()") result in guests issuing 32-bit accesses to IO space.
>>
>> QEMU needs to be able to handle them.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
>> ---
>>  vl.c | 15 ++++++++-------
>>  1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/vl.c b/vl.c
>> index c864e7d..79d3ab5 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -350,17 +350,18 @@ static void default_ioport_writew(void *opaque, 
>> uint32_t address, uint32_t data)
>>  
>>  static uint32_t default_ioport_readl(void *opaque, uint32_t address)
>>  {
>> -#ifdef DEBUG_UNUSED_IOPORT
>> -    fprintf(stderr, "unused inl: port=0x%04x\n", address);
>> -#endif
>> -    return 0xffffffff;
>> +    uint32_t data;
>> +    data = default_ioport_readw(opaque, address) & 0xffff;
>> +    address = (address + 2) & (MAX_IOPORTS - 1);
> I'm not very familiar with how hardware behaves, but shouldn't we return
> some sort of invalid result (~0) and log when the port wraps?

Intel SDM says that trying to access ports beyond 0xffff is
implementation-specific. So wrapping them I guess is valid (it's how
qemu implements it for default_ioport_readw/writew, which is what I am
following here).

-boris



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