| Message ID | alpine.DEB.2.02.1403281751000.20764@kaball.uk.xensource.com |
|---|---|
| State | New |
| Headers | show |
Il 28/03/2014 18:52, Stefano Stabellini ha scritto: >> This is a thorny issue, fixing this behavior is not going to be trivial: >> >> - The hypervisor/libxc does not currently expose a >> xc_domain_remove_from_physmap function. >> >> - QEMU works by allocating memory regions at the end of the guest >> physmap and then moving them at the right place. >> >> - QEMU can destroy a memory region and in that case we could free the >> memory and remove it from the physmap, however that is NOT what QEMU >> does with the vga ROM. In that case it calls >> memory_region_del_subregion, so we can't be sure that the ROM won't be >> mapped again, therefore we cannot free it. We need to move it >> somewhere else, hence the problem. Right; QEMU cannot know either if the ROM will be mapped again (examples include "cd /sys/bus/pci/devices/0000:0:03.0 && echo 1 > rom && cat rom" or a warm reset). >> But fortunately we don't actually need to add the VGA ROM to the guest >> physmap for it to work, QEMU can trap and emulate. In fact even today we >> are not mapping it at the right place anyway, see xen_set_memory: But how can you execute from the VGA ROM then? Also, how do you migrate its contents? And how is VGA different from say an iPXE ROM? It would be nice if QEMU could just special case pc.ram (which has block->offset == 0), and use the normal method to allocate other RAM regions. But I'm afraid that would require some changes in the Xen toolstack as well (for migration, for example) and I'm not sure how you could execute from PCI ROM BARs. Paolo
On Fri, 28 Mar 2014, Paolo Bonzini wrote: > Il 28/03/2014 18:52, Stefano Stabellini ha scritto: > > > This is a thorny issue, fixing this behavior is not going to be trivial: > > > > > > - The hypervisor/libxc does not currently expose a > > > xc_domain_remove_from_physmap function. > > > > > > - QEMU works by allocating memory regions at the end of the guest > > > physmap and then moving them at the right place. > > > > > > - QEMU can destroy a memory region and in that case we could free the > > > memory and remove it from the physmap, however that is NOT what QEMU > > > does with the vga ROM. In that case it calls > > > memory_region_del_subregion, so we can't be sure that the ROM won't be > > > mapped again, therefore we cannot free it. We need to move it > > > somewhere else, hence the problem. > > Right; QEMU cannot know either if the ROM will be mapped again (examples > include "cd /sys/bus/pci/devices/0000:0:03.0 && echo 1 > rom && cat rom" or a > warm reset). > > > > But fortunately we don't actually need to add the VGA ROM to the guest > > > physmap for it to work, QEMU can trap and emulate. In fact even today we > > > are not mapping it at the right place anyway, see xen_set_memory: > > But how can you execute from the VGA ROM then? I don't know, I guess we don't? In that case why does it work today? > Also, how do you migrate its contents? That would also not work. We would have to re-initialize it in QEMU on the receiving end. > And how is VGA different from say an iPXE ROM? iPXE is read into memory by hvmloader. > It would be nice if QEMU could just special case pc.ram (which has > block->offset == 0), and use the normal method to allocate other RAM regions. > But I'm afraid that would require some changes in the Xen toolstack as well > (for migration, for example) and I'm not sure how you could execute from PCI > ROM BARs. > > Paolo >
Il 28/03/2014 19:30, Stefano Stabellini ha scritto: > On Fri, 28 Mar 2014, Paolo Bonzini wrote: >> Il 28/03/2014 18:52, Stefano Stabellini ha scritto: >>>> This is a thorny issue, fixing this behavior is not going to be trivial: >>>> >>>> - The hypervisor/libxc does not currently expose a >>>> xc_domain_remove_from_physmap function. >>>> >>>> - QEMU works by allocating memory regions at the end of the guest >>>> physmap and then moving them at the right place. >>>> >>>> - QEMU can destroy a memory region and in that case we could free the >>>> memory and remove it from the physmap, however that is NOT what QEMU >>>> does with the vga ROM. In that case it calls >>>> memory_region_del_subregion, so we can't be sure that the ROM won't be >>>> mapped again, therefore we cannot free it. We need to move it >>>> somewhere else, hence the problem. >> >> Right; QEMU cannot know either if the ROM will be mapped again (examples >> include "cd /sys/bus/pci/devices/0000:0:03.0 && echo 1 > rom && cat rom" or a >> warm reset). >> >>>> But fortunately we don't actually need to add the VGA ROM to the guest >>>> physmap for it to work, QEMU can trap and emulate. In fact even today we >>>> are not mapping it at the right place anyway, see xen_set_memory: >> >> But how can you execute from the VGA ROM then? > > I don't know, I guess we don't? In that case why does it work today? Right, the ROM is copied down to low memory by firmware (hvmloader?). >> Also, how do you migrate its contents? > > That would also not work. We would have to re-initialize it in QEMU on > the receiving end. That is problematic. It would mean that a system reset after migration may auto-upgrade some parts of the firmware. Paolo
2014-03-29 8:31 GMT+01:00 Paolo Bonzini <pbonzini@redhat.com>: > Il 28/03/2014 19:30, Stefano Stabellini ha scritto: > > On Fri, 28 Mar 2014, Paolo Bonzini wrote: >> >>> Il 28/03/2014 18:52, Stefano Stabellini ha scritto: >>> >>>> This is a thorny issue, fixing this behavior is not going to be trivial: >>>>> >>>>> - The hypervisor/libxc does not currently expose a >>>>> xc_domain_remove_from_physmap function. >>>>> >>>>> - QEMU works by allocating memory regions at the end of the guest >>>>> physmap and then moving them at the right place. >>>>> >>>>> - QEMU can destroy a memory region and in that case we could free the >>>>> memory and remove it from the physmap, however that is NOT what QEMU >>>>> does with the vga ROM. In that case it calls >>>>> memory_region_del_subregion, so we can't be sure that the ROM won't >>>>> be >>>>> mapped again, therefore we cannot free it. We need to move it >>>>> somewhere else, hence the problem. >>>>> >>>> >>> Right; QEMU cannot know either if the ROM will be mapped again (examples >>> include "cd /sys/bus/pci/devices/0000:0:03.0 && echo 1 > rom && cat >>> rom" or a >>> warm reset). >>> >>> But fortunately we don't actually need to add the VGA ROM to the guest >>>>> physmap for it to work, QEMU can trap and emulate. In fact even today >>>>> we >>>>> are not mapping it at the right place anyway, see xen_set_memory: >>>>> >>>> >>> But how can you execute from the VGA ROM then? >>> >> >> I don't know, I guess we don't? In that case why does it work today? >> > > Right, the ROM is copied down to low memory by firmware (hvmloader?). Only vgabios and other rom of qemu traditional are include and loaded by hvmloader. Time ago when I was trying to solve some problems with the emulated vgas I came to doubt that the vgabios of qemu upstream were not loaded or used correctly. Someone had told me that they were loaded automatically from qemu when you use the qemu upstream. Unfortunately I do not have enough knowledge and are not able to find exactly the problems or things missing in xen to solve problems with the emulated vgas. I did a lot of tests, comparing with kvm using same qemu parameters used with xen showed almost always higher video performance on kvm and qxl was not working on xen but showing too few errors/details in logs that I posted long ago, unfortunately no answers. It seemed to me from what little I knew that was not allocated or usedcorrectly all the ram or one or more regions (having memory errors in logs) and / or not being loaded or used properly the vgabios. Seems that in this thread you are probably trying to solve problems including the ones I found. Last mail of my qxl tests for example is this: http://lists.xen.org/archives/html/xen-devel/2013-12/msg00758.html And the memory error on domU logs of this test was: ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0 There was also another test maybe 2 years ago for which data have made me doubt the proper loading or use of vgabios stdvga with xen and qemu upstream but unfortunately can not find it now. I will try to help with test and post results/details if I can. For example some posts ago I see Stabellini patch that seems about load of vgabios and other roms, should be tested? Thanks for any reply and sorry for my bad english. > > > Also, how do you migrate its contents? >>> >> >> That would also not work. We would have to re-initialize it in QEMU on >> the receiving end. >> > > That is problematic. It would mean that a system reset after migration > may auto-upgrade some parts of the firmware. > > > Paolo > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >
diff --git a/exec.c b/exec.c index 91513c6..bdecc70 100644 --- a/exec.c +++ b/exec.c @@ -1453,6 +1453,7 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length) It should not be used for general purpose DMA. Use cpu_physical_memory_map/cpu_physical_memory_rw instead. */ +extern uint8_t* vga_rom; void *qemu_get_ram_ptr(ram_addr_t addr) { RAMBlock *block = qemu_get_ram_block(addr); @@ -1462,7 +1463,9 @@ void *qemu_get_ram_ptr(ram_addr_t addr) * because we don't want to map the entire memory in QEMU. * In that case just map until the end of the page. */ - if (block->offset == 0) { + if (!strcmp(block->mr->name,"cirrus_vga.rom")) { + return vga_rom; + } else if (block->offset == 0) { return xen_map_cache(addr, 0, 0); } else if (block->host == NULL) { block->host = diff --git a/xen-all.c b/xen-all.c index ba34739..6211946 100644 --- a/xen-all.c +++ b/xen-all.c @@ -101,6 +101,8 @@ typedef struct XenIOState { Notifier wakeup; } XenIOState; +uint8_t* vga_rom; + /* Xen specific function for piix pci */ int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num) @@ -217,6 +219,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr) return; } + if (!strcmp(mr->name,"cirrus_vga.rom")) { + vga_rom = g_malloc(size); + return; + } + trace_xen_ram_alloc(ram_addr, size); nr_pfn = size >> TARGET_PAGE_BITS;