[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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@xxxxxxxxxx> 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:

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.


Let me see whether which path we take.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.