On Thu, 2011-04-28 at 16:46 +0200, Jan Kiszka wrote:
> On 2011-04-28 16:29, Alex Williamson wrote:
> > On Thu, 2011-04-28 at 10:59 +0200, Jan Kiszka wrote:
> >> Use rages_overlap and proper constants to match the access range against
> > ^^^^^ typo - only if you resend
> >
> >> regions that need special handling. This also fixes yet uncaught
> >> high-byte write access to the command register. Moreover, use more
> >> constants instead of magic numbers.
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
> >> ---
> >> hw/device-assignment.c | 39 +++++++++++++++++++++++++++++----------
> >> 1 files changed, 29 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> >> index 606d725..3481c93 100644
> >> --- a/hw/device-assignment.c
> >> +++ b/hw/device-assignment.c
> >> @@ -404,13 +404,20 @@ static void assigned_dev_pci_write_config(PCIDevice *d, uint32_t address,
> >> return assigned_device_pci_cap_write_config(d, address, val, len);
> >> }
> >>
> >> - if (address == 0x4) {
> >> + if (ranges_overlap(address, len, PCI_COMMAND, 2)) {
> >> pci_default_write_config(d, address, val, len);
> >> /* Continue to program the card */
> >> }
> >>
> >> - if ((address >= 0x10 && address <= 0x24) || address == 0x30 ||
> >> - address == 0x34 || address == 0x3c || address == 0x3d) {
> >> + /*
> >> + * Catch access to
> >> + * - base address registers
> >> + * - ROM base address & capability pointer
> >> + * - interrupt line & pin
> >> + */
> >> + if (ranges_overlap(address, len, PCI_BASE_ADDRESS_0, 24) ||
> >> + ranges_overlap(address, len, PCI_ROM_ADDRESS, 8) ||
> >
> > Should this be 5 bytes instead of 8? I'm not sure why we'd add catching
> > these reserved fields, but not those immediately after this range.
>
> Yes, that's asking for clarification: Should we allow direct access to
> the complete reserved space or virtualize it? Depending on this, the
> proper value should be 5 or 14 (the latter would also save one
> ranges_overlap).
I vote for 5 here since a cleanup patch shouldn't have behavior changes
hidden in it. I don't see any great value in virtualizing reserved
bits. It seems like it could only make things not work if a vendor was
stupid enough to hide something in there. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
