From: "Michael S. Tsirkin" <mst@redhat.com>
To: liu ping fan <qemulist@gmail.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Anthony Liguori" <anthony@codemonkey.ws>,
"Jan Kiszka" <jan.kiszka@siemens.com>,
qemu-devel@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH v5 2/5] hpet: entitle more irq pins for hpet
Date: Sun, 29 Sep 2013 07:15:47 +0300 [thread overview]
Message-ID: <20130929041547.GA28242@redhat.com> (raw)
In-Reply-To: <CAJnKYQmMDmkOM=c7rGxaqNBNSLtF46P+9DWV7bAoiUKXz84CqA@mail.gmail.com>
On Sun, Sep 29, 2013 at 11:49:41AM +0800, liu ping fan wrote:
> On Sun, Sep 29, 2013 at 3:56 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Thu, Sep 12, 2013 at 11:25:15AM +0800, Liu Ping Fan wrote:
> >> On PC, IRQ2/8 can be reserved for hpet timer 0/1. And pin 16~23
> >> of ioapic can be dynamically assigned to hpet as guest chooses.
> >> (Will enable them after introducing pc 1.6 compat)
> >>
> >> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> >> ---
> >> hw/timer/hpet.c | 13 +++++++++++--
> >> 1 file changed, 11 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
> >> index 8429eb3..46903b9 100644
> >> --- a/hw/timer/hpet.c
> >> +++ b/hw/timer/hpet.c
> >> @@ -25,6 +25,7 @@
> >> */
> >>
> >> #include "hw/hw.h"
> >> +#include "hw/boards.h"
> >> #include "hw/i386/pc.h"
> >> #include "ui/console.h"
> >> #include "qemu/timer.h"
> >> @@ -42,6 +43,12 @@
> >>
> >> #define HPET_MSI_SUPPORT 0
> >>
> >> +/* For bug compat, using only IRQ2. Soon it will be fixed as
> >> + * 0xff0104ULL, i.e using IRQ16~23, IRQ8 and IRQ2
> >
> > So users are expected to stick a bitmask of legal
> > pins here?
> > I think that's a bit too much rope to give to users.
> > Don't you think?
> >
> Sorry, not understand your meaning exactly. But the scene will be:
> guest kernel polls the ability bitmask, and pick up one pin which is
> not occupied or can be shared with the level-trigger and low-active.
> So is it rope?
I merely say that it's better to make this a bool or bit property.
UINT32 is too much flexibility imho.
> Thanks and regards,
> Pingfan
> >> after
> >> + * introducing pc-1.6 compat.
> >> + */
> >> +#define HPET_TN_INT_CAP_DEFAULT 0x4ULL
> >> +
> >> #define TYPE_HPET "hpet"
> >> #define HPET(obj) OBJECT_CHECK(HPETState, (obj), TYPE_HPET)
> >>
> >> @@ -73,6 +80,7 @@ typedef struct HPETState {
> >> uint8_t rtc_irq_level;
> >> qemu_irq pit_enabled;
> >> uint8_t num_timers;
> >> + uint32_t intcap;
> >> HPETTimer timer[HPET_MAX_TIMERS];
> >>
> >> /* Memory-mapped, software visible registers */
> >> @@ -663,8 +671,8 @@ static void hpet_reset(DeviceState *d)
> >> if (s->flags & (1 << HPET_MSI_SUPPORT)) {
> >> timer->config |= HPET_TN_FSB_CAP;
> >> }
> >> - /* advertise availability of ioapic inti2 */
> >> - timer->config |= 0x00000004ULL << 32;
> >> + /* advertise availability of ioapic int */
> >> + timer->config |= (uint64_t)s->intcap << 32;
> >> timer->period = 0ULL;
> >> timer->wrap_flag = 0;
> >> }
> >> @@ -753,6 +761,7 @@ static void hpet_realize(DeviceState *dev, Error **errp)
> >> static Property hpet_device_properties[] = {
> >> DEFINE_PROP_UINT8("timers", HPETState, num_timers, HPET_MIN_TIMERS),
> >> DEFINE_PROP_BIT("msi", HPETState, flags, HPET_MSI_SUPPORT, false),
> >> + DEFINE_PROP_UINT32("intcap", HPETState, intcap, HPET_TN_INT_CAP_DEFAULT),
> >> DEFINE_PROP_END_OF_LIST(),
> >> };
> >>
> >> --
> >> 1.8.1.4
> >>
next prev parent reply other threads:[~2013-09-29 4:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-12 3:25 [Qemu-devel] [PATCH v5 0/5] bugs fix for hpet Liu Ping Fan
2013-09-12 3:25 ` [Qemu-devel] [PATCH v5 1/5] hpet: inverse polarity when pin above ISA_NUM_IRQS Liu Ping Fan
2013-09-28 19:52 ` Michael S. Tsirkin
2013-09-29 3:25 ` liu ping fan
2013-09-29 4:20 ` Michael S. Tsirkin
2013-09-30 8:04 ` liu ping fan
2013-09-12 3:25 ` [Qemu-devel] [PATCH v5 2/5] hpet: entitle more irq pins for hpet Liu Ping Fan
2013-09-28 19:56 ` Michael S. Tsirkin
2013-09-29 3:49 ` liu ping fan
2013-09-29 4:15 ` Michael S. Tsirkin [this message]
2013-09-30 8:02 ` liu ping fan
2013-09-30 9:06 ` Michael S. Tsirkin
2013-09-30 9:06 ` Paolo Bonzini
2013-09-30 9:30 ` Michael S. Tsirkin
2013-09-30 15:48 ` Paolo Bonzini
2013-09-30 15:58 ` Michael S. Tsirkin
2013-10-09 3:27 ` liu ping fan
2013-10-09 7:24 ` Michael S. Tsirkin
2013-10-09 7:41 ` Paolo Bonzini
2013-10-09 8:01 ` Michael S. Tsirkin
2013-10-09 8:41 ` Paolo Bonzini
2013-09-12 3:25 ` [Qemu-devel] [PATCH v5 3/5] PC: use qdev_xx to create hpet instead of sysbus_create_xx Liu Ping Fan
2013-09-12 3:25 ` [Qemu-devel] [PATCH v5 4/5] PC: differentiate hpet's interrupt capability on piix and q35 Liu Ping Fan
2013-09-12 3:25 ` [Qemu-devel] [PATCH v5 5/5] PC-1.6: add compatibility for hpet intcap on pc-q35-1.6 Liu Ping Fan
2013-09-12 6:29 ` [Qemu-devel] [PATCH v5 0/5] bugs fix for hpet Paolo Bonzini
2013-09-12 7:49 ` liu ping fan
2013-09-25 6:27 ` liu ping fan
2013-09-25 15:59 ` Paolo Bonzini
2013-09-26 15:45 ` Mike Day
2013-09-26 15:48 ` Mike Day
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130929041547.GA28242@redhat.com \
--to=mst@redhat.com \
--cc=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--cc=jan.kiszka@siemens.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).