On 10/29/13 18:16, Jordan Justen wrote: > On Mon, Oct 28, 2013 at 10:36 PM, Olivier Martin <olivier.mar...@arm.com> > wrote: >> Unfortunately, the caller (the VirtIo Block driver) does not >> know if the access is unaligned. > > Did you or Laszlo say that the virtio spec specifically says that all > I/O accesses can be broken up into smaller accesses?
In the device-specific offset range, yes. Accesses to the common range need strict alignment and size. > If so, then I > think it is fine for the virtio protocol instance to automatically > break the access apart. (But, the protocol interface should document > this.) Jordan, could you please explain the problem again? > If that is not mentioned, then I don't think VirtioPciDeviceDxe should do > this. > > Since this is now becoming a protocol, it seems like we look at the > existing I/O protocols. (PciIo, CpuIo) I see 2 main differences in the > interfaces. > 1. Those interfaces use an enum for widths PciIo and CpuIo are generic. For example, beside width of access, their enums allow the caller to control (non-)advancing through the source and target ranges. In my mind VirtIo is more oriented towards the individual configuration field. > 2. Those interfaces are well defined in terms of alignment requirements > >> The VirtIo Block driver does not necessary know if the transport >> layer is PCI and has not got PCI-X capability (case when the >> access is unaligned). > > That is unfortunate. I guess at the expense of considerable > complication for the caller, the virtio protocol instance could > indicate an alignment offset. > > Maybe this issue makes 64-bit accesses too complicated for the > interface. This is something that could be re-enforced by defining > width enums, and simply not adding 64-bit versions. > >> One other solution would be to handle the 64bit unaligned >> access in the VirtIo PCI driver. >> Such as we are doing now by splitting the 64bit access >> into two 32bit accesses; >> except when the access is aligned we would do a single >> 64bit access. > > Performance could be an issue, but it also seems that it would be > possible for the auto-split I/O to cause the I/O to the device to > fail. OK I'll admit I don't understand what we're talking about, but if the offset is divisible by 8 (and thus theoretically appropriate for a 64-bit access), then it is also divisible by 4 (and appropriate for a 32-bit access). This covers the offset. Regarding size: the common config area (which requires strict alignment and size from the access) has no 64-bit fields. Auto-splitting in that range would be incorrect there, but it never happens, because no common field exceeds 32 bits in size. The device-specific range may contain 64-bit fields (for some devices), but splitting is fine there. What am I not seeing? Anyway I don't insist. I added the splitting out of precaution, not because I found out the hard way that it was necessary. I think OVMF would work just fine without it on qemu. (No idea about VirtualBox etc.) Thanks! Laszlo ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
