Messages in this thread | | | Subject | Re: [PATCH 1/3] block: add queue flag for paravirt frontend drivers | From | Fernando Luis Vázquez Cao <> | Date | Wed, 05 Nov 2008 19:49:17 +0900 |
| |
On Wed, 2008-11-05 at 10:20 +0100, Jens Axboe wrote: > On Tue, Nov 04 2008, Jeremy Fitzhardinge wrote: > > Jens Axboe wrote: > > >On Mon, Oct 27 2008, Fernando Luis Vázquez Cao wrote: > > > > > >>As is the case with SSD devices, we do not want to idle in AS/CFQ when > > >>the block device is a paravirt front-end driver. This patch adds a flag > > >>(QUEUE_FLAG_VIRT) which should be used by front-end drivers such as > > >>virtio_blk and xen-blkfront to indicate a paravirtualized device. > > >> > > > > > >All three patches look fine, although we could just reuse > > >QUEUE_FLAG_NONROT directly. But I agree it makes sense to make the > > >distinction, so I've just applied 1-3. > > > > > > > I guess in theory you could imagine that the virtual device is mapped > > directly onto a physical device, and the host OS does no scheduling, in > > which case it would be appropriate for the guest do the work. But I > > think otherwise this makes sense. > > For that specific case, it should just not set the flag.
When the virtual device is mapped directly onto a physical device the host OS or the hypervisor could notify this fact to the guest using the PCI configuration space (the bytes reserved for vendor-defined purposes look like a good candidate to me). In such a case, on the guest side the driver should just check the configuration space and set/unset the flag accordingly.
The good thing about this approach is that it can be used with both paravirt drivers and regular drivers (which is important for fully virtualized guests).
I have just started to implement this idea but I would be great it you let me know your take on this issue.
- Fernando
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |