[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
Boris Ostrovsky writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit default_ioport_* accesses"): > IIUIC, the Linux/ACPICA patch makes ACPICA use correct field in ACPI's > Generic Address Structure (section 5.2.3.2 in the 6.0 spec). Before the > patch it used register's bit_width and now it will use access_size. > According to the spec access_size 0 means undefined/legacy access. I see. (Well, sort of.) > I just looked at what hvmloader provides and at least for FADT > address_size is 0. And I wonder whether ACPICA uses 4-byte-access for > these cases. If 0 is "undefined/legacy access", shouldn't it be using the register's bit width ? Ie, isn't this then a bug in ACPICA ? > So maybe instead of trying to patch qemu-trad I should see if I can make > hvmloader provide proper access size. Let me poke at that. If this "access size" attribute is new, things should work without it, surely ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |