Re: [Xen-devel] gross qemu behavior

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.04.14 at 15:53, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Fri, 4 Apr 2014, Jan Beulich wrote:
>> 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?

Hypercall? Everything you need is there afaict.

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

And I never proposed this as an alternative.

Jan


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