From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [RFC 7/11] virtio_pci: new, capability-aware driver. Date: Mon, 12 Dec 2011 20:25:34 +0200 Message-ID: <20111212182533.GB25916@redhat.com> References: <87pqfzgy6p.fsf@rustcorp.com.au> <87zkf3fiu2.fsf@rustcorp.com.au> <20111211094256.GB11504@redhat.com> <87boreohhs.fsf@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <87boreohhs.fsf@rustcorp.com.au> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Rusty Russell Cc: Sasha Levin , virtualization List-Id: virtualization@lists.linuxfoundation.org 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" 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