From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36054 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONqUH-0006zg-RG for qemu-devel@nongnu.org; Sun, 13 Jun 2010 12:56:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONqUG-0007od-7T for qemu-devel@nongnu.org; Sun, 13 Jun 2010 12:56:45 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:55135) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONqUF-0007oM-Qn for qemu-devel@nongnu.org; Sun, 13 Jun 2010 12:56:44 -0400 Message-ID: <4C150DC5.6020802@web.de> Date: Sun, 13 Jun 2010 18:56:37 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20100613144315.GB6292@redhat.com> In-Reply-To: <20100613144315.GB6292@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB69D36D0A75D7A01B8C8E127" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH] pass info about hpets to seabios. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB69D36D0A75D7A01B8C8E127 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gleb Natapov wrote: > Currently HPET ACPI table is created regardless of whether qemu actuall= y > created hpet device. This may confuse some guests that don't check that= > hpet is functional before using it. Solve this by passing info about > hpets in qemu to seabios via fw config interface. Additional benefit is= > that seabios no longer uses hard coded hpet configuration. Proposed > interface supports up to 256 hpets. This is the number defined by hpet = > spec. Nice, this lays the ground for adding hpets via -device. (But I think I read there can only be 8 hpets with a total sum of 256 timers.) >=20 > Signed-off-by: Gleb Natapov > diff --git a/hw/hpet.c b/hw/hpet.c > index 93fc399..f2a4514 100644 > --- a/hw/hpet.c > +++ b/hw/hpet.c > @@ -73,6 +73,8 @@ typedef struct HPETState { > uint64_t hpet_counter; /* main counter */ > } HPETState; > =20 > +struct hpet_fw_config hpet_cfg =3D {.valid =3D 1}; > + > static uint32_t hpet_in_legacy_mode(HPETState *s) > { > return s->config & HPET_CFG_LEGACY; > @@ -661,6 +663,9 @@ static void hpet_reset(DeviceState *d) > */ > hpet_pit_enable(); > } > + hpet_cfg.count =3D 1; > + hpet_cfg.hpet.event_timer_block_id =3D (uint32_t)s->capability; The number of timers, thus the content of capability can change on vmload. So you need to update hpet_cfg there as well. And I think we can move the capability setup into init. But this is not directly related to this patch, would just avoid adding this hunk to hpet_reset. > + hpet_cfg.hpet.address =3D sysbus_from_qdev(d)->mmio[0].addr; > count =3D 1; > } > =20 > diff --git a/hw/hpet_emul.h b/hw/hpet_emul.h > index d7bc102..5cf5463 100644 > --- a/hw/hpet_emul.h > +++ b/hw/hpet_emul.h > @@ -53,4 +53,20 @@ > #define HPET_TN_INT_ROUTE_CAP_SHIFT 32 > #define HPET_TN_CFG_BITS_READONLY_OR_RESERVED 0xffff80b1U > =20 > +struct hpet_fw_entry > +{ > + uint32_t event_timer_block_id; > + uint64_t address; > + uint16_t min_tick; > + uint8_t page_prot; > +} __attribute__ ((packed)); > + > +struct hpet_fw_config > +{ > + uint8_t valid; > + uint8_t count; > + struct hpet_fw_entry hpet; Why not already struct hpet_fw_entry hpet[8]? Once the bios bits are merge, we can quickly remove the single hpet limitation on qemu side. > +} __attribute__ ((packed)); > + > +extern struct hpet_fw_config hpet_cfg; > #endif > diff --git a/hw/pc.c b/hw/pc.c > index 1491129..d14d657 100644 > --- a/hw/pc.c > +++ b/hw/pc.c > @@ -61,6 +61,7 @@ > #define FW_CFG_SMBIOS_ENTRIES (FW_CFG_ARCH_LOCAL + 1) > #define FW_CFG_IRQ0_OVERRIDE (FW_CFG_ARCH_LOCAL + 2) > #define FW_CFG_E820_TABLE (FW_CFG_ARCH_LOCAL + 3) > +#define FW_CFG_HPET (FW_CFG_ARCH_LOCAL + 4) > =20 > #define E820_NR_ENTRIES 16 > =20 > @@ -484,6 +485,8 @@ static void *bochs_bios_init(void) > fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE, (uint8_t *)&e820_table= , > sizeof(struct e820_table)); > =20 > + fw_cfg_add_bytes(fw_cfg, FW_CFG_HPET, (uint8_t *)&hpet_cfg, > + sizeof(struct hpet_fw_config)); > /* allocate memory for the NUMA channel: one (64bit) word for the = number > * of nodes, one word for each VCPU->node and one word for each no= de to > * hold the amount of memory. > -- > Gleb. >=20 >=20 Jan --------------enigB69D36D0A75D7A01B8C8E127 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkwVDckACgkQitSsb3rl5xQdHQCePjFpxxeFUwZ7C+kCMR4nzCGg Y0cAoNJoz+jXuieOE9lfCH5zOJoUVTER =evCN -----END PGP SIGNATURE----- --------------enigB69D36D0A75D7A01B8C8E127--