Re: [edk2] [PATCH v4 00/11] OvmfPkg: Introduce and use the new VIRTIO_DEVICE_PROTOCOL protocol

Subject: Re: [edk2] [PATCH v4 00/11] OvmfPkg: Introduce and use the new VIRTIO_DEVICE_PROTOCOL protocol

From: Jordan Justen <jljusten@gmail.com>

To: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>

Date: 2013-10-29 18:16:18

On Mon, Oct 28, 2013 at 10:36 PM, Olivier Martin  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? 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.)

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
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.

-Jordan

> ________________________________________
> From: Jordan Justen [jljusten@gmail.com]
> Sent: 23 October 2013 22:57
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [PATCH v4 00/11] OvmfPkg: Introduce and use the new VIRTIO_DEVICE_PROTOCOL protocol
>
> On Wed, Oct 16, 2013 at 10:29 AM, Olivier Martin  wrote:
>> Not changed:
>> ------------
>> - Endianness: All the architectures supported by the UEFI spec
>>   are in 'little endian' mode.
>> - Keep the PCI 64bit read/write break down into two 32bit accesses:
>>   The VirtiIo BlockIo driver makes (at least) one non 8-byte aligned
>>   access when trying to access the 'VIRTIO_BLK_CONFIG.Capacity' attribute.
>>   VIRTIO_BLK_CONFIG.Capacity is a 64bit field at the offset 0x0 of the
>>   device specific region. This region starts at the offset 20 (0x14) of
>>   the I/O region when there is no MSI-X capability.
>
> The caller making this I/O access has idea they are making an unaligned access?
>
> If the caller knows that it is unaligned and they know that it is okay
> (based on device specific knowledge) to split accesses apart, then the
> caller should split the access.
>
> -Jordan
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782
>
>
> ------------------------------------------------------------------------------
> 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

------------------------------------------------------------------------------
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