On Thu, Mar 21, 2013 at 09:15:15AM -0700, H. Peter Anvin wrote: > On 03/21/2013 09:11 AM, Michael S. Tsirkin wrote: > >> > >> It is really, really, nasty, not to mention slow. > > > > Almost everything we do is through DMA, except a single write > > to start transmit and a single read to clear interrupts. So all it means > > is we do 2 io writes or reads per packet instead of 1. Seems harmless > > enough. A bit slower than native but should be good enough for > > BIOS. Needs no resources at all. Why nasty? What's not to like? > > > > Corner cases galore... including the statefulness and non-atomicity of > config space writes (MMCONFIG is obviously not an option here.) It > requires a minimum of four operations to do it safely. Even 4 operations per kick is harmless for BIOS, if you recall that it exits to host, that's pretty harmless. Might be an issue for cards that need you to put the whole packet in NIC memory, virtio rings make this a non issue - we might not be able to hit 10Gb/s but should be able to do 1Gb/s easily. Now I am really thinking we need such a config cycle backdoor for the BIOS. > > > > 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.) > > -hpa 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? -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
