Re: [PATCH 1/5] pci-assign: Clean up assigned_dev_pci_read/write_config

[Alex Williamson <alex.williamson@redhat.com>]

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@siemens.com>
> >> ---
> >>  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