On Thu, Mar 21, 2013 at 09:32:06AM -0700, H. Peter Anvin wrote:
> On 03/21/2013 09:26 AM, Michael S. Tsirkin wrote:
> >>>
> >>> Thanks. Same place in latest 3.0:
> >>> A PCI Express Endpoint must not depend on operating system allocation of
> >>> I/O resources claimed through BAR(s).
> >>> A PCI Express Endpoint must not generate I/O Requests.
> >>> of course this only applies to express :)
> >>>
> >>
> >> And it does... but it has implications for the OS resource manager that
> >> if Linux violates, we need to fix it. We should not fail a device in
> >> generic code because an I/O BAR allocation fails. The device driver may
> >> opt to fail the allocation.
> >>
> >> (Note that having an I/O BAR is not *generating* an I/O request.)
> >
> > Right. So if I read this literally, I should be able to boot
> > from the device even if it does not have an I/O BAR,
> > and BIOS really should not assume it has an I/O BAR option,
> > and if as you suggest it can't use MMIO, what is left?
> > config cycles.
> >
> > So coming back to the issue that started it all,
> > BIOS will be able to boot without I/O BAR, no good
> > reasons to have any capabilities pointing at I/O BARs,
> > so no need for duplicate capabilities?
> >
>
> First of all, you appear to be deliberately overinterpreting -- the BIOS
> is the resource manager here, so it can obviously make sure the I/O
> resource is available to the boot device.
Assuming there's one, but it's wrong: we might need serial for
output, -net for downloading stuff, maybe more.
> The performance argument, though, which is the more important one, still
> remains, so your conclusion is invalid.
>
> -hpa
I just think it does not apply to BIOS so much. A bigger issue for BIOS
virtio performance is that it normally does not implement batching at
all, to keep it simple and reduce memory usage it uses a small number
(often 1) of outstanding buffers per queue.
For example, here's BIOS driver for virtio-blk.
if (write)
vring_add_buf(vq, sg, 2, 1, 0, 0);
else
vring_add_buf(vq, sg, 1, 2, 0, 0);
vring_kick(GET_GLOBAL(vdrive_g->ioaddr), vq, 1);
/* Wait for reply */
while (!vring_more_used(vq))
usleep(5);
/* Reclaim virtqueue element */
vring_get_buf(vq, NULL);
/* Clear interrupt status register. Avoid leaving interrupts stuck if
* VRING_AVAIL_F_NO_INTERRUPT was ignored and interrupts were
* raised.
*/
vp_get_isr(GET_GLOBAL(vdrive_g->ioaddr));
Does it look like we should spend time optimizing vring_kick?
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
