Re: [RFC 7/11] virtio_pci: new, capability-aware driver.

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Dec 12, 2011 at 09:15:03AM +1030, Rusty Russell wrote:
> On Sun, 11 Dec 2011 11:42:56 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Thu, Dec 08, 2011 at 09:09:33PM +1030, Rusty Russell wrote:
> > > +/* There is no iowrite64.  We use two 32-bit ops. */
> > > +static void iowrite64(u64 val, const __le64 *addr)
> > > +{
> > > +	iowrite32((u32)val, (__le32 *)addr);
> > > +	iowrite32(val >> 32, (__le32 *)addr + 1);
> > > +}
> > > +
> > 
> > Let's put addr_lo/addr_hi in the structure then,
> > to make the fact this field is not atomic explicit?
> 
> Good point, assuming I haven't missed something.
> 
> Are 64-bit accesses actually unknown in PCI-land?  Or is this a limited
> availability thing?
> 
> Thanks,
> Rusty.

By the way, a generic question on virtio-pci: we now have:

/* virtio config->get() implementation */
static void vp_get(struct virtio_device *vdev, unsigned offset,
                   void *buf, unsigned len)
{
        struct virtio_pci_device *vp_dev = to_vp_device(vdev);
        void __iomem *ioaddr = vp_dev->ioaddr +
                                VIRTIO_PCI_CONFIG(vp_dev) + offset;
        u8 *ptr = buf;
        int i;

        for (i = 0; i < len; i++)
                ptr[i] = ioread8(ioaddr + i);
}

This means that if configuration is read while
it is changed, we might get an inconsistent state,
with parts of a 64 bit field coming from old
and parts from new value.

Isn't this a problem?

-- 
MST