On Fri, Feb 08, 2013 at 10:18:19PM +1100, Vadim Rozenfeld wrote: > On Thu, 2013-02-07 at 14:33 +0100, Laszlo Ersek wrote: > > Apologies in advance for asking a possibly exorbitantly lame question... > > > > On 02/06/13 10:47, Vadim Rozenfeld wrote: > > > On Tue, 2013-02-05 at 13:58 +0200, Michael S. Tsirkin wrote: > > >> On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote: > > >>> 05.02.2013 15:31, Vadim Rozenfeld wrote: > > >>>> On Mon, 2013-02-04 at 08:41 -0600, Anthony Liguori wrote: > > > > >>>>> But adding feature bits an altering the config size doesn't > > >>>>> constitute a > > >>>>> change in the software interface IMHO. > > >>>> > > >>>> I agree, feature bits are good. The only one problem with them, is that > > >>>> driver usually doesn't have access to PCI space during the driver > > >>>> loading phase. > > >>> > > >>> Vadim, can you please describe in a bit more details what the actual > > >>> issue > > >>> here is, from the windows or windows driver point of view? > > > > > If a driver receives descriptor with memory type resources it needs to > > > map physical address to logical. This process requires the number of > > > bytes to be mapped, and it is the best place for sanity check to verify > > > that the resources are valid and not corrupted. We usually do it by > > > comparing the resource size with some predefined value, that we expect > > > to see. > > > > >>> Is it really > > >>> that bad that the config space size changed? Why it has this effect? > > > > > Because in this case it's hard to distinguish between resource's > > > corruption and HW update. > > > > In theory, would the following approach work? > > > > (1) insist on revision-id being 0, > > > > (2) only require a minimum size of VIRTIO_PCI_CONFIG_NOMSI == 20 bytes > > from the iomem BAR (= common virtio header, guaranteed by the virtio > > spec for revision-id==0) when loading the driver, > > > > (3) at first, only map this initial (guaranteed) part of the resource, > > > > (4) this should provide access to the feature bits, allowing > > verification of the full BAR size, including MSI-X fields and device > > type specific fields, > > > > (5a) remap the BAR with full size if there's a match, > I would try avoiding any remapping in virtio block and scsi drivers, > especially when they are operating in system installation, crash dump > and hibernation modes. > Best regards, > Vadim.
Looks like there's some misunderstanding. It's an IO BAR, not a memory BAR. As such I don't think there is any remapping done on x86 before access. > > (5b) if there's a mismatch, set "permanent hardware failure" or some > > such in the loaded drier. > > > > It would be probably overkill; I'm just wondering if it made sense in > > theory. > > > > Thanks > > Laszlo >
