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

[Wei Liu <wei.liu2@citrix.com>]

On Mon, May 23, 2016 at 09:02:58AM -0400, Boris Ostrovsky wrote:
> 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@oracle.com>
> >> ---
> >>  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).
> 

Fair enough.

Wei.

> -boris
> 
> 

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