On Fri, Dec 16, 2011 at 12:20:08PM +1030, Rusty Russell wrote:
> On Thu, 15 Dec 2011 10:27:50 +0200, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote:
> > On Tue, Dec 13, 2011 at 12:51:20PM +1030, Rusty Russell wrote:
> > I mean like this in block:
> >
> >
> >
> > /* Host must always specify the capacity. */
> > vdev->config->get(vdev, offsetof(struct virtio_blk_config,
> > capacity),
> > &capacity, sizeof(capacity));
> >
> > /* If capacity is too big, truncate with warning. */
> > if ((sector_t)capacity != capacity) {
> > dev_warn(&vdev->dev, "Capacity %llu too large:
> > truncating\n",
> > (unsigned long long)capacity);
> > capacity = (sector_t)-1;
> > }
> >
> >
> > Now let's assume capacity field is changed from 0x8000 to 0x10000
> > on host. Is it possible that we read two upper bytes
> > before the change so we see 0x0000....
> > and 2 lower bytes after the change
> > so we see 0x....0000 and resulting capacity appears
> > to be 0?
> >
> > If no why not?
>
> Same issue in reverse with the guest setting the MAC address in
> virtio_net, if the host were reading it. And virtio_balloon? We have
> ignored it, so far.
>
> Perhaps a new feature VIRTIO_F_UNSTABLE? Which (unlike other features)
> appears and vanishes around config writes by either side? Kind of a
> hack though...
>
> Cheers,
> Rusty.
Not sure how this can work in such a setup: when would guest
check this bit to avoid races?
A separate registers also seems nicer than a flag.
Some other possible design choices:
- a flag to signal config accesses in progress by guest
host would need to buffer changes and apply them in one go
when flag is cleared
- a register to make host get/set config in guest memory
- use a control vq for all devices
The last two involve defining a structure specifying
offset and length of device configuration affected.
The last option is preferable if other transports
besides pci might have the same issue: we solve
it once and for all this way.
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
