Re: [Xen-devel] gross qemu behavior

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 4 Apr 2014, Jan Beulich wrote:
> >>> On 03.04.14 at 18:12, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Mon, 31 Mar 2014, Jan Beulich wrote:
> >> >>> On 28.03.14 at 18:46, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> >> > But fortunately we don't actually need to add the VGA ROM to the guest
> >> > physmap for it to work,
> >> 
> >> Is that true even when the ROM gets enabled by the guest?
> > 
> > Yes, I think so.
> 
> Implying that any execution of code in the ROM would be fully
> emulated. Very odd, but fitting the picture of trying to be as slow
> as possible (in the context of the breakage introduced by
> ef437690 "x86/HVM: correct CPUID leaf 80000008 handling" I
> had to run qemu-traditional and qemu-upstream, and the
> performance of the guest visibly _much_ better with the former,
> which I consider rather worrying).
> 
> >> > QEMU can trap and emulate. In fact even today we
> >> > are not mapping it at the right place anyway, see xen_set_memory:
> >> > 
> >> >     if (add) {
> >> >         if (!memory_region_is_rom(section->mr)) {
> >> >             xen_add_to_physmap(state, start_addr, size,
> >> >                                section->mr, 
> >> > section->offset_within_region);
> >> >         } else {
> >> 
> >> Right - that's part of the problem. And it would seem to be better to
> >> map it where it belongs (even if not enabled) than to have it sit at
> >> some arbitrary place. But as that still wouldn't be correct, I'd clearly
> >> prefer a proper solution.
> > 
> > We could go down this route, but then on unmap the rom would just be
> > moved back to the original place.
> > Do you think that would be a reasonable solution? From QEMU POV it would
> > certainly be better then the approach below.
> 
> No, it should just never appear at the wrong address. As I said above,
> I'd consider it halfway acceptable if it remained mapped despite an
> unmap, but I do think that a proper solution (properly unmapping
> without de-allocating) can and should be found.

There is no way to do it today AFAICT.
Would you care of proposing an hypercall that would support this
scenario?


> The more that this
> intermediate approach can't really work as I now realize: When
> disabled while the guest is sizing the BARs, the address put there
> would be all ones in the writable upper bits of the address, i.e. not
> a place where the ROM could be legitimately mapped.
>
> And btw - the current model is inconsistent anyway (and perhaps a
> reason why certain things appear to not work right when a domain
> has memory extending beyond 4G): Once other things (it was the
> frame buffer in all cases I've seen) get mapped into the address
> space, the ROM gets (implicitly) unmapped anyway. So relying on
> it to stay somewhere in guest address space is broken in any event;
> qemu's view just doesn't match reality anymore at that point.

The alternative, never mapping any ROMs in the guest address space, has
other issues too:

- inconsistency with QEMU's way of doing things
- firmware update on migration (as Paolo pointed out)

I don't really see this as a huge step forward.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel