[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] gross qemu behavior
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |