From: Rusty Russell <rusty@rustcorp.com.au>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Sasha Levin <levinsasha928@gmail.com>,
virtualization <virtualization@lists.linux-foundation.org>
Subject: Re: [RFC 7/11] virtio_pci: new, capability-aware driver.
Date: Thu, 30 May 2013 11:47:27 +0930 [thread overview]
Message-ID: <871u8pmcso.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20130529102100.GQ4472@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Wed, May 29, 2013 at 10:47:52AM +0930, Rusty Russell wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>>
>> > On Mon, Dec 12, 2011 at 01:49:13PM +0200, Michael S. Tsirkin wrote:
>> >> 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.
>> >>
>> >> I think PCI can optionally support atomic 64 bit accesses, but not all
>> >> architectures can generate them.
>> >
>> > Ping. Going to change this in the layout struct?
>>
>> Not sure what you mean.... We use a queue_enable field, so it doesn't
>> matter if the accesses aren't atomic for that.
>>
>> Cheers,
>> Rusty.
>
> I mean the struct should have separate _lo and _hi fields.
>
> Otherwise I have to do:
>
> + case offsetof(struct virtio_pci_common_cfg, queue_desc):
> + assert(size == 4);
> + return virtio_queue_get_desc_addr(vdev, vdev->queue_sel) & low;
> + case offsetof(struct virtio_pci_common_cfg, queue_desc) + 4:
> + assert(size == 4);
> + return virtio_queue_get_desc_addr(vdev, vdev->queue_sel) >> 32;
>
> Would be nicer as:
>
> + case offsetof(struct virtio_pci_common_cfg, queue_desc_lo):
> + assert(size == sizeof cfg.queue_desc_lo);
> + return virtio_queue_get_desc_addr(vdev, vdev->queue_sel) & low;
> + case offsetof(struct virtio_pci_common_cfg, queue_desc_hi):
> + assert(size == sizeof cfg.queue_desc_hi);
> + return virtio_queue_get_desc_addr(vdev, vdev->queue_sel) >> 32;
>
> Agree?
Indeed. Sorry for being obtuse!
Split into _lo and _hi fields:
Subject: virtio_pci: split u64 fields into u32.
MST points out that since we write them as two u32s, and the backend has
to handle that, let's not fool ourselves and just make it two u32s.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/drivers/virtio/virtio_pci_modern.c b/drivers/virtio/virtio_pci_modern.c
index 8b35c2e..b5bb348 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -37,17 +37,16 @@ static DEFINE_PCI_DEVICE_TABLE(virtio_pci_id_table) = {
MODULE_DEVICE_TABLE(pci, virtio_pci_id_table);
-/* There is no general iowrite64. We use two 32-bit ops. */
-static void iowrite64_twopart(u64 val, const __le64 *addr)
+static void iowrite64_twopart(u64 val, __le32 *lo, __le32 *hi)
{
- iowrite32((u32)val, (__le32 *)addr);
- iowrite32(val >> 32, (__le32 *)addr + 1);
+ iowrite32((u32)val, lo);
+ iowrite32(val >> 32, hi);
}
/* There is no ioread64. We use two 32-bit ops. */
-static u64 ioread64_twopart(__le64 *addr)
+static u64 ioread64_twopart(__le32 *lo, __le32 *hi)
{
- return ioread32(addr) | ((u64)ioread32((__le32 *)addr + 1) << 32);
+ return ioread32(lo) | ((u64)ioread32(hi) << 32);
}
/* config->{get,set}_status() implementations */
@@ -145,14 +144,16 @@ static u64 vp_get64(struct virtio_device *vdev, unsigned offset)
{
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
- return ioread64_twopart(vp_dev->device + offset);
+ return ioread64_twopart(vp_dev->device + offset,
+ vp_dev->device + offset + 4);
}
static void vp_set64(struct virtio_device *vdev, unsigned offset, u64 val)
{
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
- iowrite64_twopart(val, vp_dev->device + offset);
+ iowrite64_twopart(val, vp_dev->device + offset,
+ vp_dev->device + offset + 4);
}
static void vp_reset(struct virtio_device *vdev)
@@ -198,17 +199,18 @@ static struct virtqueue *setup_vq(struct virtio_pci_device *vp_dev,
{
struct virtio_pci_vq_info *info;
struct virtqueue *vq;
+ struct virtio_pci_common_cfg __iomem *cfg = vp_dev->common;
u16 num, off;
int err;
- if (index >= ioread16(&vp_dev->common->num_queues))
+ if (index >= ioread16(&cfg->num_queues))
return ERR_PTR(-ENOENT);
/* Select the queue we're interested in */
- iowrite16(index, &vp_dev->common->queue_select);
+ iowrite16(index, &cfg->queue_select);
/* Sanity check */
- switch (ioread64_twopart(&vp_dev->common->queue_desc)) {
+ switch (ioread64_twopart(&cfg->queue_desc_lo, &cfg->queue_desc_hi)) {
/* Uninitialized. Excellent. */
break;
default:
@@ -217,7 +219,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device *vp_dev,
}
/* Maximum size must be a power of 2. */
- num = ioread16(&vp_dev->common->queue_size);
+ num = ioread16(&cfg->queue_size);
if (num & (num - 1)) {
dev_warn(&vp_dev->pci_dev->dev, "bad queue size %u", num);
return ERR_PTR(-EINVAL);
@@ -233,7 +235,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device *vp_dev,
info->desired_num = num;
/* get offset of notification word for this vq (shouldn't wrap) */
- off = ioread16(&vp_dev->common->queue_notify_off);
+ off = ioread16(&cfg->queue_notify_off);
if ((u64)off * vp_dev->notify_offset_multiplier + 2
> vp_dev->notify_len) {
dev_warn(&vp_dev->pci_dev->dev,
@@ -264,8 +266,8 @@ static struct virtqueue *setup_vq(struct virtio_pci_device *vp_dev,
info->vq = vq;
if (msix_vec != VIRTIO_MSI_NO_VECTOR) {
- iowrite16(msix_vec, &vp_dev->common->queue_msix_vector);
- msix_vec = ioread16(&vp_dev->common->queue_msix_vector);
+ iowrite16(msix_vec, &cfg->queue_msix_vector);
+ msix_vec = ioread16(&cfg->queue_msix_vector);
if (msix_vec == VIRTIO_MSI_NO_VECTOR) {
err = -EBUSY;
goto out_new_virtqueue;
@@ -282,14 +284,14 @@ static struct virtqueue *setup_vq(struct virtio_pci_device *vp_dev,
}
/* Activate the queue. */
- iowrite16(num, &vp_dev->common->queue_size);
+ iowrite16(num, &cfg->queue_size);
iowrite64_twopart(virt_to_phys(vq->vring.desc),
- &vp_dev->common->queue_desc);
+ &cfg->queue_desc_lo, &cfg->queue_desc_hi);
iowrite64_twopart(virt_to_phys(vq->vring.avail),
- &vp_dev->common->queue_avail);
+ &cfg->queue_avail_lo, &cfg->queue_avail_hi);
iowrite64_twopart(virt_to_phys(vq->vring.used),
- &vp_dev->common->queue_used);
- iowrite8(1, &vp_dev->common->queue_enable);
+ &cfg->queue_used_lo, &cfg->queue_used_hi);
+ iowrite8(1, &cfg->queue_enable);
return vq;
@@ -352,9 +354,9 @@ static void del_vq(struct virtqueue *vq)
/* This is for our own benefit, not the device's! */
iowrite16(info->desired_num, &vp_dev->common->queue_size);
- iowrite64_twopart(0, &vp_dev->common->queue_desc);
- iowrite64_twopart(0, &vp_dev->common->queue_avail);
- iowrite64_twopart(0, &vp_dev->common->queue_used);
+ iowrite64_twopart(0, &vp_dev->common->queue_desc_lo, &vp_dev->common->queue_desc_hi);
+ iowrite64_twopart(0, &vp_dev->common->queue_avail_lo, &vp_dev->common->queue_avail_hi);
+ iowrite64_twopart(0, &vp_dev->common->queue_used_lo, &vp_dev->common->queue_used_hi);
free_pages_exact(info->queue, size);
kfree(info);
diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h
index 591eb0e5..a23226b 100644
--- a/include/uapi/linux/virtio_pci.h
+++ b/include/uapi/linux/virtio_pci.h
@@ -159,8 +159,11 @@ struct virtio_pci_common_cfg {
__le16 queue_msix_vector; /* read-write */
__le16 queue_enable; /* read-write */
__le16 queue_notify_off; /* read-only */
- __le64 queue_desc; /* read-write */
- __le64 queue_avail; /* read-write */
- __le64 queue_used; /* read-write */
+ __le32 queue_desc_lo; /* read-write */
+ __le32 queue_desc_hi; /* read-write */
+ __le32 queue_avail_lo; /* read-write */
+ __le32 queue_avail_hi; /* read-write */
+ __le32 queue_used_lo; /* read-write */
+ __le32 queue_used_hi; /* read-write */
};
#endif /* _UAPI_LINUX_VIRTIO_PCI_H */
next prev parent reply other threads:[~2013-05-30 2:17 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-08 10:22 [PATCH 0/11] RFC: PCI using capabilitities Rusty Russell
2011-12-08 10:30 ` [RFC 1/11] virtio: use u32, not bitmap for struct virtio_device's features Rusty Russell
2011-12-08 10:31 ` [RFC 2/11] virtio: add support for 64 bit features Rusty Russell
2011-12-08 10:32 ` [PATCH 0/11] RFC: PCI using capabilitities Sasha Levin
2011-12-08 10:32 ` [RFC 3/11] pci: add pci_iomap_range Rusty Russell
2011-12-15 8:30 ` Michael S. Tsirkin
2011-12-16 1:56 ` Rusty Russell
2011-12-26 14:05 ` [PATCHv2 RFC] " Michael S Tsirkin
2011-12-26 14:05 ` Michael S Tsirkin
2011-12-08 10:34 ` [RFC 4/11] virtio-pci: define layout for virtio vendor-specific capabilities Rusty Russell
2011-12-10 21:14 ` Sasha Levin
2011-12-08 10:35 ` [RFC 6/11] virtio_pci: move old defines to legacy, introduce new structure Rusty Russell
2011-12-08 10:38 ` [RFC 6/11] virtio_pci: don't use the legacy driver if we find the new PCI capabilities Rusty Russell
2011-12-10 21:18 ` Sasha Levin
2011-12-11 5:15 ` Rusty Russell
2011-12-11 9:37 ` Michael S. Tsirkin
2011-12-08 10:39 ` [RFC 7/11] virtio_pci: new, capability-aware driver Rusty Russell
2011-12-11 9:42 ` Michael S. Tsirkin
2011-12-11 22:45 ` Rusty Russell
2011-12-12 11:49 ` Michael S. Tsirkin
2011-12-12 18:10 ` Don Dutile
2011-12-16 1:58 ` Rusty Russell
2013-05-28 7:56 ` Michael S. Tsirkin
2013-05-29 1:17 ` Rusty Russell
2013-05-29 10:21 ` Michael S. Tsirkin
2013-05-30 2:17 ` Rusty Russell [this message]
2011-12-12 18:25 ` Michael S. Tsirkin
2011-12-13 2:21 ` Rusty Russell
2011-12-15 8:27 ` Michael S. Tsirkin
2011-12-16 1:50 ` Rusty Russell
2011-12-18 10:18 ` Michael S. Tsirkin
2011-12-19 6:06 ` Rusty Russell
2011-12-19 9:13 ` Michael S. Tsirkin
2011-12-19 11:08 ` Rusty Russell
2011-12-20 11:37 ` Michael S. Tsirkin
2011-12-21 0:33 ` Rusty Russell
2011-12-21 9:19 ` Michael S. Tsirkin
2012-01-10 17:03 ` Michael S. Tsirkin
2012-01-11 0:25 ` Rusty Russell
2012-01-11 1:48 ` Benjamin Herrenschmidt
2012-01-11 8:47 ` Stefan Hajnoczi
2012-01-11 9:10 ` Benjamin Herrenschmidt
2012-01-11 14:28 ` Stefan Hajnoczi
2012-01-11 15:39 ` Michael S. Tsirkin
2012-01-11 17:21 ` Stefan Hajnoczi
2012-01-11 18:34 ` Michael S. Tsirkin
2012-01-11 20:56 ` Benjamin Herrenschmidt
2012-01-11 20:46 ` Benjamin Herrenschmidt
2012-01-12 10:37 ` Stefan Hajnoczi
2012-01-11 10:21 ` Michael S. Tsirkin
2012-01-11 21:13 ` Benjamin Herrenschmidt
2012-01-11 22:13 ` Michael S. Tsirkin
2012-01-11 22:19 ` Benjamin Herrenschmidt
2012-01-11 22:56 ` Benjamin Herrenschmidt
2012-01-12 5:29 ` Michael S. Tsirkin
2012-01-12 6:13 ` Benjamin Herrenschmidt
2012-01-12 6:37 ` Michael S. Tsirkin
2012-01-12 2:01 ` Rusty Russell
2012-01-12 4:31 ` Benjamin Herrenschmidt
2012-01-12 6:09 ` Michael S. Tsirkin
2012-01-12 6:28 ` Benjamin Herrenschmidt
2012-01-12 6:51 ` Michael S. Tsirkin
2012-01-12 7:03 ` Benjamin Herrenschmidt
2012-01-12 6:00 ` Michael S. Tsirkin
2012-01-13 3:22 ` Rusty Russell
2012-01-11 13:30 ` Anthony Liguori
2012-01-11 15:12 ` Michael S. Tsirkin
2012-01-11 15:15 ` Anthony Liguori
2012-01-11 15:21 ` Michael S. Tsirkin
2012-01-11 15:28 ` Anthony Liguori
2012-01-11 15:45 ` Michael S. Tsirkin
2012-01-11 16:02 ` Anthony Liguori
2012-01-11 17:08 ` Michael S. Tsirkin
2012-01-11 19:42 ` Anthony Liguori
2012-01-11 20:14 ` Michael S. Tsirkin
2012-01-11 20:26 ` Anthony Liguori
2012-01-11 21:02 ` Benjamin Herrenschmidt
2012-01-11 22:02 ` Michael S. Tsirkin
2012-01-11 22:16 ` Benjamin Herrenschmidt
2012-01-12 1:42 ` Rusty Russell
2012-01-13 2:19 ` Michael S. Tsirkin
2012-01-13 2:32 ` Benjamin Herrenschmidt
2012-01-18 15:29 ` Michael S. Tsirkin
2012-01-22 22:53 ` Rusty Russell
2012-01-18 4:52 ` Rusty Russell
2012-01-11 21:58 ` Michael S. Tsirkin
2012-01-11 20:59 ` Benjamin Herrenschmidt
2012-01-11 20:51 ` Benjamin Herrenschmidt
2012-01-11 20:50 ` Benjamin Herrenschmidt
2012-01-12 1:35 ` Rusty Russell
2011-12-08 10:40 ` [RFC 8/11] virtio_pci: share structure between legacy and modern Rusty Russell
2011-12-08 10:41 ` [RFC 9/11] virtio_pci: share interrupt/notify handlers " Rusty Russell
2011-12-08 10:42 ` [RFC 10/11] virtio_pci: share virtqueue setup/teardown between modern and legacy driver Rusty Russell
2011-12-08 10:44 ` [RFC 11/11] virtio_pci: simplify common helpers Rusty Russell
2011-12-08 15:37 ` [PATCH 0/11] RFC: PCI using capabilitities Sasha Levin
2011-12-09 6:17 ` Rusty Russell
2011-12-10 21:32 ` Sasha Levin
2011-12-11 9:05 ` Avi Kivity
2011-12-11 10:03 ` Sasha Levin
2011-12-11 12:30 ` Michael S. Tsirkin
2011-12-11 12:48 ` Sasha Levin
2011-12-11 12:48 ` Sasha Levin
2011-12-11 12:47 ` Michael S. Tsirkin
2011-12-11 12:53 ` Sasha Levin
2011-12-11 12:53 ` Sasha Levin
2011-12-08 15:37 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871u8pmcso.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=levinsasha928@gmail.com \
--cc=mst@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.