On Thu, Jun 06, 2013 at 10:02:14AM -0500, Anthony Liguori wrote: > Gleb Natapov <gleb@xxxxxxxxxx> writes: > > > On Wed, Jun 05, 2013 at 07:41:17PM -0500, Anthony Liguori wrote: > >> "H. Peter Anvin" <hpa@xxxxxxxxx> writes: > >> > >> > On 06/05/2013 03:08 PM, Anthony Liguori wrote: > >> >>> > >> >>> Definitely an option. However, we want to be able to boot from native > >> >>> devices, too, so having an I/O BAR (which would not be used by the OS > >> >>> driver) should still at the very least be an option. > >> >> > >> >> What makes it so difficult to work with an MMIO bar for PCI-e? > >> >> > >> >> With legacy PCI, tracking allocation of MMIO vs. PIO is pretty straight > >> >> forward. Is there something special about PCI-e here? > >> >> > >> > > >> > It's not tracking allocation. It is that accessing memory above 1 MiB > >> > is incredibly painful in the BIOS environment, which basically means > >> > MMIO is inaccessible. > >> > >> Oh, you mean in real mode. > >> > >> SeaBIOS runs the virtio code in 32-bit mode with a flat memory layout. > >> There are loads of ASSERT32FLAT()s in the code to make sure of this. > >> > > Well, not exactly. Initialization is done in 32bit, but disk > > reads/writes are done in 16bit mode since it should work from int13 > > interrupt handler. The only way I know to access MMIO bars from 16 bit > > is to use SMM which we do not have in KVM. > > Ah, if it's just the dataplane operations then there's another solution. > > We can introduce a virtqueue flag that asks the backend to poll for new > requests. Then SeaBIOS can add the request to the queue and not worry > about kicking or reading the ISR. > And when backend stops polling? When guest's driver reconfigure it? But what if this will never happen? > SeaBIOS is polling for completion anyway. > > Regards, > > Anthony Liguori > > > > > -- > > Gleb. > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
