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