From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFh4g-0007Pi-SN for qemu-devel@nongnu.org; Thu, 16 Jul 2015 07:11:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFh4a-0007y6-7c for qemu-devel@nongnu.org; Thu, 16 Jul 2015 07:11:34 -0400 Received: from mail-wg0-x22d.google.com ([2a00:1450:400c:c00::22d]:36220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFh4a-0007xs-1b for qemu-devel@nongnu.org; Thu, 16 Jul 2015 07:11:28 -0400 Received: by wgxm20 with SMTP id m20so55553375wgx.3 for ; Thu, 16 Jul 2015 04:11:27 -0700 (PDT) Sender: Paolo Bonzini References: <1437035704-11299-1-git-send-email-real@ispras.ru> <1437035704-11299-4-git-send-email-real@ispras.ru> <55A773C1.6060400@redhat.com> <55A78C99.5040504@ispras.ru> From: Paolo Bonzini Message-ID: <55A79117.2020300@redhat.com> Date: Thu, 16 Jul 2015 13:10:15 +0200 MIME-Version: 1.0 In-Reply-To: <55A78C99.5040504@ispras.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 3/3] PAM: make PAM emulation closer to documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?0JXRhNC40LzQvtCyINCS0LDRgdC40LvQuNC5?= , qemu-devel@nongnu.org Cc: Kirill Batuzov , "Michael S. Tsirkin" On 16/07/2015 12:51, Ефимов Василий wrote: > The rest of code looks up destination or source region or child region > offset in memory sub-tree which root is PCI or RAM region provided on > PAM creation. We cannon use common address_space_translate because it > searches from address space root and will return current PAM region. > To summarize, I suggest to move the code to exec.c. It is generic > enough. All these mechanism are extremely low level. They are encapsulated within exec.c, and copying code to pam.c is not a good idea because you already have all the AddressSpaces and RAM MemoryRegions you need. >> Could you use an IOMMU memory region instead? Then a single region can >> be used to implement all four modes, and you don't hit the "trying to >> execute code outside RAM or RAM". > Did you mean MemoryRegion.iommu_ops ? The feature does not allow to > change destination memory region. It does. You're right about this: > exec.c: address_space_translate_for_iotlb: > assert(!section->mr->iommu_ops); ... but an IOMMU region is not needed, and I think you can do everything without touching exec.c at all. + /* Read from RAM and write to PCI */ + memory_region_init_io(&pam->region[1], OBJECT(dev), &pam_ops, pam, + "pam-r-ram-w-pci", size); This can be done with memory_region_set_readonly on the RAM region. You need to set mr->ops in order to point to pam_ops; for a first proof of concept you can just set the field directly. Writes to the PCI memory space can use the PCI address space, with address_space_st*. + /* Read from PCI and write to RAM */ + memory_region_init_io(&pam->region[2], OBJECT(dev), &pam_ops, pam, + "pam-r-pci-w-ram", size); Here you cannot run code from ROM, so it can be a pure MMIO region. Reads can use address_space_ld*, while writes can use memory_region_get_ram_ptr. Paolo