From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtdRo-0004Ke-7L for qemu-devel@nongnu.org; Fri, 11 Jan 2013 07:10:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtdRl-0004nw-TI for qemu-devel@nongnu.org; Fri, 11 Jan 2013 07:10:56 -0500 Received: from cantor2.suse.de ([195.135.220.15]:58702 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtdRl-0004nr-Jf for qemu-devel@nongnu.org; Fri, 11 Jan 2013 07:10:53 -0500 Message-ID: <50F0014A.5050804@suse.de> Date: Fri, 11 Jan 2013 13:10:50 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1357681452-24963-1-git-send-email-lersek@redhat.com> <50EFDBA4.4050201@redhat.com> In-Reply-To: <50EFDBA4.4050201@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] PIIX: reset the VM when the Reset Control Register's RCPU bit gets set List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Blue Swirl , akong@redhat.com, qemu-devel@nongnu.org Hi, Am 11.01.2013 10:30, schrieb Laszlo Ersek: > On 01/09/13 22:01, Blue Swirl wrote: >> On Tue, Jan 8, 2013 at 9:44 PM, Laszlo Ersek wrote= : >=20 >>> +static void i440fx_host_config_write(void *opaque, hwaddr addr, >>> + uint64_t val, unsigned len) >>> +{ >>> + if (addr =3D=3D 1 && len =3D=3D 1) { >>> + if (val & 4) { >>> + qemu_system_reset_request(); >>> + } >>> + return; >>> + } >>> + pci_host_conf_le_ops.write(opaque, addr, val, len); >>> +} >>> + >>> +static MemoryRegionOps i440fx_host_conf_ops =3D { >>> + .read =3D NULL, >>> + .write =3D i440fx_host_config_write, >>> + .endianness =3D DEVICE_LITTLE_ENDIAN >>> +}; >>> + >>> static int i440fx_pcihost_initfn(SysBusDevice *dev) >>> { >>> PCIHostState *s =3D PCI_HOST_BRIDGE(dev); >>> >>> - memory_region_init_io(&s->conf_mem, &pci_host_conf_le_ops, s, >>> + i440fx_host_conf_ops.read =3D pci_host_conf_le_ops.read; >> >> It would be cleaner to introduce a new memory region (without this >> copying) which passes 0xcf8 and 0xcfc to standard PCI host but catches >> accesses to 0xcf9. This may mean that pci_host_config_{read,write} >> will need to be exposed. >=20 > Do you mean: >=20 > (1) introducing the new "i440fx_host_conf_ops" struct-of-funcptrs with > detached functions (that is, duplicating the guts of > pci_host_config_{read,write} and modifying them, and then registering > s->conf_mem with this "i440fx_host_conf_ops"; or >=20 > (2) leaving s->conf_mem as-is, and introducing a sub-region just for > port 0xcf9, with higher visibility priority? >=20 > (I don't feel confident about (2), and based on "docs/memory.txt" I > thought that overlapping regions had not been invented for this purpose= .) >=20 > IOW, are you OK with the explicit offset + access-width based check, > just organized differently, or are you proposing a one-byte-wide subreg= ion? Another option: (3) leaving s->conf_mem as-is but implementing your own read function as well that forwards to pci_host_conf_le_ops.read() to avoid this unusual non-const MemoryRegionOps construct But I guess Blue meant (2), which should be slightly more performant. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg