Re: [Xen-devel] gross qemu behavior

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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