Re: [Qemu-devel] Configuring pflash devices for OVMF firmware

[Ning, Yu]

> -----Original Message-----
> From: Paolo Bonzini [mailto:address@hidden
> Sent: Friday, February 1, 2019 7:55
> To: Alexandro Sanchez Bach <address@hidden>; 'Markus Armbruster'
> <address@hidden>
> Cc: 'Peter Maydell' <address@hidden>; 'Peter Krempa'
> <address@hidden>; 'Qemu-block' <address@hidden>; 'Libvirt'
> <address@hidden>; 'QEMU Developers' <address@hidden>;
> 'László Érsek' <address@hidden>; 'Justin Terry (VM)'
> <address@hidden>; Ning, Yu <address@hidden>
> Subject: Re: [Qemu-devel] Configuring pflash devices for OVMF firmware
> 
> On 01/02/19 00:28, Alexandro Sanchez Bach wrote:
> > (CC'd Yu Ning @ Intel's HAXM team)
> >
> > Not sure, if I'm understanding the issue correctly, but isn't
> > `HAX_VM_IOCTL_SET_RAM2` with the `HAX_RAM_INFO_ROM` flag precisely
> > what you are looking for?
> >
> > More precisely, HAX_VM_IOCTL_SET_RAM2 maps an HVA range to a GPA
> > range, the HAX_RAM_INFO_ROM flag should allow only guest memory reads
> > to that range [1]. When the guest attempts to write, this should
> > trigger a VM exit that will be handled by QEMU.
> 
> The missing handling is in the hypervisor:
> 
>     if (ret == -EACCES) {
>         /*
>          * For some reason, during boot-up, Chrome OS guests make
> hundreds of
>          * attempts to write to GPAs close to 4GB, which are mapped into
> BIOS
>          * (read-only) and thus result in EPT violations.
>          * TODO: Handle this case properly.
>          */
>         hax_warning("%s: Unexpected EPT violation cause. Skipping
> instruction"
>                     " (len=%u)\n", __func__,
> vcpu->vmx.exit_instr_length);
>         advance_rip(vcpu);
>         return HAX_EXIT;
> }
> 
> > Also, this seems to be handled here:
> >
> https://github.com/qemu/qemu/blob/15bede554162dda822cd762c689edb6fa3
> 2b
> > 6e3b/target/i386/hax-mem.c#L205-L207
> 
> Right, though to be precise it should be changed to
> 
>      if (memory_region_is_rom(section->mr) ||
>        memory_region_is_romd(section->mr)) {         flags |=
> HAX_RAM_INFO_ROM;
>      }
> 
> for that to work.
> 

Thank you both for outlining the changes we have to make in order to support 
ROMD memory regions!  The only question is whether we should pass a new flag to 
HAX_VM_IOCTL_SET_RAM2 for ROMD, so the hypervisor could respond differently to 
writes to ROM and ROMD regions.  Would that be useful at all?  What would 
happen if HAXM asked QEMU to emulate a write to ROM?

HAXM didn't implement ROMD support at first, because the guests we tested could 
boot without it (including Chrome OS).  Now that this feature has become more 
popular (and we want to be able to boot OVMF), I think it's time to get it 
done.  I'd like to get to it after the Lunar New Year holidays, but if anyone 
can finish it sooner, I'll be happy to merge their patch into HAXM.

-Yu