On 15/04/2020 16:55, Ard Biesheuvel wrote:
> On Wed, 15 Apr 2020 at 17:43, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>>
>> On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei <alexandru.elisei@xxxxxxx> wrote:
>>>
>>> Hi,
>>>
>>> I've tested this patch by running badblocks and fio on a flash device inside a
>>> guest, everything worked as expected.
>>>
>>> I've also looked at the flowcharts for device operation from Intel Application
>>> Note 646, pages 12-21, and they seem implemented correctly.
>>>
>>> A few minor issues below.
>>>
>>> On 2/21/20 4:55 PM, Andre Przywara wrote:
>>>> From: Raphael Gault <raphael.gault@xxxxxxx>
>>>>
>>>> The EDK II UEFI firmware implementation requires some storage for the EFI
>>>> variables, which is typically some flash storage.
>>>> Since this is already supported on the EDK II side, we add a CFI flash
>>>> emulation to kvmtool.
>>>> This is backed by a file, specified via the --flash or -F command line
>>>> option. Any flash writes done by the guest will immediately be reflected
>>>> into this file (kvmtool mmap's the file).
>>>> The flash will be limited to the nearest power-of-2 size, so only the
>>>> first 2 MB of a 3 MB file will be used.
>>>>
>>>> This implements a CFI flash using the "Intel/Sharp extended command
>>>> set", as specified in:
>>>> - JEDEC JESD68.01
>>>> - JEDEC JEP137B
>>>> - Intel Application Note 646
>>>> Some gaps in those specs have been filled by looking at real devices and
>>>> other implementations (QEMU, Linux kernel driver).
>>>>
>>>> At the moment this relies on DT to advertise the base address of the
>>>> flash memory (mapped into the MMIO address space) and is only enabled
>>>> for ARM/ARM64. The emulation itself is architecture agnostic, though.
>>>>
>>>> This is one missing piece toward a working UEFI boot with kvmtool on
>>>> ARM guests, the other is to provide writable PCI BARs, which is WIP.
>>>>
>>
>> I have given this a spin with UEFI built for kvmtool, and it appears
>> to be working correctly. However, I noticed that it is intolerably
>> slow, which seems to be caused by the fact that both array mode and
>> command mode (or whatever it is called in the CFI spec) are fully
>> emulated, whereas in the QEMU implementation (for instance), the
>> region is actually exposed to the guest using a read-only KVM memslot
>> in array mode, and so the read accesses are made natively.
>>
>> It is also causing problems in the UEFI implementation, as we can no
>> longer use unaligned accesses to read from the region, which is
>> something the code currently relies on (and which works fine on actual
>> hardware as long as you use normal non-cacheable mappings)
>>
>
> Actually, the issue is not alignment. The issue is with instructions
> with multiple outputs, which means you cannot do an ordinary memcpy()
> from the NOR region using ldp instructions, aligned or not.
Yes, we traced that down to an "ldrb with post-inc", in the memcpy code.
My suggestion was to provide a version of memcpy_{from,to}_io(), as
Linux does, which only uses MMIO accessors to avoid "fancy" instructions.
Back at this point I was challenging the idea of accessing a flash
device with a normal memory mapping, because of it failing when being in
some query mode. Do you know of any best practices for flash mappings?
Are two mappings common?
Cheers,
Andre
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
