From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: gross qemu behavior Date: Sat, 29 Mar 2014 08:31:13 +0100 Message-ID: <533676C1.2080203@redhat.com> References: <5335376102000078000033DA@nat28.tlf.novell.com> <5335B902.5080507@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WTnjb-0002GG-CI for xen-devel@lists.xenproject.org; Sat, 29 Mar 2014 07:31:19 +0000 Received: by mail-ee0-f44.google.com with SMTP id e49so4846660eek.3 for ; Sat, 29 Mar 2014 00:31:17 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: anthony.perard@citrix.com, xen-devel , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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