From: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
To: Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: KVM in-kernel APIC update
Date: Wed, 4 Apr 2007 22:32:35 +0200 [thread overview]
Message-ID: <20070404203235.GA11369@elte.hu> (raw)
In-Reply-To: <46128F80.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
* Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> wrote:
> Hi all,
>
> Attached is a snapshot of my current efforts on the kernel side for
> the in-kernel APIC work. Feedback welcome.
good work and nice patch! :)
> My current thoughts are that we at least move the IOAPIC into the
> kernel as well. [...]
yes. And then do the final 10% move of handling the i8529A in KVM too.
That would mean that PV drivers could inject IRQ events without having
to schedule back to qemu. Especially if the IRQ is masked this avoids a
context-switch. (with any PIC component in qemu we have no choice but to
always wake up qemu and let it handle the event - even if it results in
a 'no vector generated' decision). This is a plus because most PV
drivers will do IO completion from irq context and possibly on other
CPUs.
> The current Bochs/QEMU system model paints a fairly simple ISA
> architecture utilizing a single IOAPIC + dual 8259 setup. Do we
> expect in-kernel injected IRQs to follow the ISA model (e.g. either
> legacy or PCI interrupts only limited to IRQ0-15) or do we want to
> expand on this? [...]
yes, we should probably expand them - it's not hard. PV/accel drivers
would most likely hook up to free pins to unshare the interrupts.
> If the latter, we also need to decide what the resource conveyance
> model and vector allocation policy should be. For instance, do we
> publish said resources formally in the MP/ACPI tables in Bochs? Doing
> so would allow MP/ACPI compliant OSs like linux to naturally route the
> IRQ. Conversely, do we do something more direct just like we do for
> KVM discovery via wrmsr?
for PV/accel drivers we dont need any extra ACPI enumeration - the
hypercall API is good enough to connect to the hypervisor, and i suspect
all guest OSs we care about allow drivers to allocate an IRQ vector for
a new device, without having that device enumerated in ACPI.
Ingo
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
next prev parent reply other threads:[~2007-04-04 20:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-03 22:31 KVM in-kernel APIC update Gregory Haskins
[not found] ` <46128F80.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-04 7:40 ` Avi Kivity
[not found] ` <46135686.4090905-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-04-04 16:23 ` Gregory Haskins
[not found] ` <46138A98.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-04 16:49 ` Avi Kivity
[not found] ` <4613D736.1080207-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-04-04 17:10 ` Gregory Haskins
[not found] ` <4613959F.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-04 17:43 ` Avi Kivity
[not found] ` <4613E3CB.6000904-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-04-04 17:56 ` Gregory Haskins
[not found] ` <4613A090.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-04 20:20 ` Ingo Molnar
[not found] ` <20070404202046.GD6070-X9Un+BFzKDI@public.gmane.org>
2007-04-05 6:48 ` Avi Kivity
2007-04-04 22:00 ` Dor Laor
2007-04-04 20:12 ` Ingo Molnar
[not found] ` <20070404201205.GC6070-X9Un+BFzKDI@public.gmane.org>
2007-04-04 21:55 ` Dor Laor
2007-04-05 6:47 ` Avi Kivity
[not found] ` <46149B7C.5020004-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-04-05 7:37 ` Dor Laor
2007-04-05 10:39 ` Ingo Molnar
[not found] ` <20070405103933.GA8936-X9Un+BFzKDI@public.gmane.org>
2007-04-05 10:50 ` Ingo Molnar
[not found] ` <20070405105042.GA11779-X9Un+BFzKDI@public.gmane.org>
2007-04-05 11:29 ` Avi Kivity
2007-04-05 14:37 ` Dong, Eddie
2007-04-04 20:32 ` Ingo Molnar [this message]
[not found] ` <20070404203235.GA11369-X9Un+BFzKDI@public.gmane.org>
2007-04-04 21:22 ` Gregory Haskins
[not found] ` <4613D0CE.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-04 21:40 ` Anthony Liguori
2007-04-05 7:11 ` Avi Kivity
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=20070404203235.GA11369@elte.hu \
--to=mingo-x9un+bfzkdi@public.gmane.org \
--cc=ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
/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