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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

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.

Ian.

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