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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH qemu-traditional] ioreq: 
Support 32-bit default_ioport_* accesses"):
> On 05/25/2016 12:09 PM, Ian Jackson wrote:
> > 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.

That would mean that in the absence of indication that the new
standard is supported, accesses should be 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

That commit message does not justify the decision other than as an
optimisation.  Backward-incompatible `optimisations' are a bad idea
both de jure and de facto.

> 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.

I confess I don't understand that patch, but it does seem to be an
attempt to provide backward-compatible behaviour.

Overall, all this new information tends to reinforce my initial
supposition that the bug is in ACPICA and that qemu-xen-traditional
ought not to be changed.

Thanks,
Ian.

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