From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCTBW-0004oG-DT for qemu-devel@nongnu.org; Thu, 22 Aug 2013 07:36:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCTBQ-00052j-By for qemu-devel@nongnu.org; Thu, 22 Aug 2013 07:36:14 -0400 Message-ID: <5215F777.1040404@redhat.com> Date: Thu, 22 Aug 2013 13:35:19 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1377086477-19553-1-git-send-email-pbonzini@redhat.com> <5214DB87.6010305@redhat.com> <5214DD8B.2020803@redhat.com> <5215CDFB.7000201@redhat.com> <5215D7B0.5090500@redhat.com> <5215E946.5030008@redhat.com> In-Reply-To: <5215E946.5030008@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] vl: allow "cont" from panicked state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: pkrempa@redhat.com, marcel.a@redhat.com, libvir-list@redhat.com, hutao@cn.fujitsu.com, qemu-stable@nongnu.org, mst@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, rhod@redhat.com, kraxel@redhat.com, anthony@codemonkey.ws, afaerber@suse.de Il 22/08/2013 12:34, Laszlo Ersek ha scritto: > Actually it's fine to clarify these things! Hence the longish digression below. > I think before priority comes into the picture, the access size would > matter first, no? > > (I think I'm recalling this from the 0xCF9 reset control register, which > falls into the [0xCF8..0xCFA] range.) The base address is what matters. A 2- or 4-byte access to x will always go to the region that includes address x, even if there are other regions between x and respectively x+1 or x+3. So an access to 0xCF8 will go to the PCI address register, while an access to 0xCF9 will always go to the reset control register. This happens in address_space_translate_internal: diff = int128_sub(section->mr->size, int128_make64(addr)); For a write to 0xCF8, addr would be 0 (it is relative to the base of the MemoryRegion). section->size would be 1 because the next section starts at 0xCF9. However, section->mr->size would be 4 as specified e.g. in i440fx_pcihost_initfn: memory_region_init_io(&s->conf_mem, obj, &pci_host_conf_le_ops, s, "pci-conf-idx", 4); Using section->size would be wrong---it would attempt a 1-byte write to 0xCF8, another 1-byte write to 0xCF9, and a 2-byte write to 0xCFA. section->mr->size instead does a single write to 0xCF8, the same as on real hardware. BTW, the behavior changed slightly in QEMU 1.6 for 8-byte accesses. All such accesses were split to two 4-byte accesses before; now the maximum size of a "direct" MMIO operation (the data bus size, effectively) is 64 bits, so a 64-bit write will always address a single MemoryRegion. For example, say you had the PCI address and data registers occupying two separate 4-byte MemoryRegions in 8 consecutive bytes of memory. In 1.5 you could write both of them with a single 64-bit write. In 1.6, this would only write four bytes to the first MemoryRegion. This matches hardware more closely, and is really unlikely to be a problem: a target with 32-bit data bus probably would not have 64-bit CPU registers to begin with. If it did, it would resemble the architecture of the 80386SX or 8088 processors. > Unless ioport 0 is accessed with width 1 for dma-chan purposes, I think > such an access would be unique to pvpanic, and always dispatched to pvpanic. It is: static const MemoryRegionOps channel_io_ops = { .read = read_chan, .write = write_chan, .endianness = DEVICE_NATIVE_ENDIAN, .impl = { .min_access_size = 1, .max_access_size = 1, }, }; >> Channel 0 is (was) used for DRAM refresh, so >> it should not have any visible effect. However, it may not be entirely >> disabling pvpanic, just making it mostly invisible. > > That's good enough for the guest to reach kexec :) Yes, I cannot deny that. :) Paolo