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

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

On 05/25/2016 12:09 PM, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH qemu-traditional] ioreq: Support 32-bit default_ioport_* accesses"):
>> On 25.05.16 at 17:36, <boris.ostrovsky@oracle.com> wrote:
>>> 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?
>> I think so, yes.
> I think this question can only be resolved de jure by looking at what
> previous ACPI specifications (before this AccessSize field) said.

It's been around since 3.0 (which is 2004). Prior to that --- my cursory
read of 2.0 suggests that accesses were 8-bit.

>
> But, I think: de facto, what is going on here is that ACPICA and hence
> Linux have changed their behaviour in a way that is not compatible
> with at least some existing "hardware".  Is this not arguably a
> compatibility defect Linux ?
>
> It would surely be better to make Linux do whatever it did before,
> when AccessSize is not supplied.  That will avoid breaking any other
> things (whether or not those other things are de jure broken according
> to previous specs).  It will also avoid us having to make changes our
> ACPI tables which themselves come with a risk of compatibility
> problems.

ACPICA will use 32-bit accesses for access_size=0:
    https://github.com/acpica/acpica/commit/c49a751b

However, Linux appears to have some sort of workaround for FreeBSD,
which *appears* as it should be applicable to hvmloader's tables as
well. But it clearly does not as we are failing on Linux.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/acpi/acpica/hwregs.c?id=b314a172ee968d45f72dffea68ab8af38aa80ded

Let me see whether which path we take.

-boris



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