public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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:20:46 +0200	[thread overview]
Message-ID: <20070404202046.GD6070@elte.hu> (raw)
In-Reply-To: <4613A090.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>


* Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> wrote:

> > pci is level triggered, so maybe the guests just handle the 
> > inaccuracy.
> > 
> 
> Good point.  I'm not sure how this works today.  Perhaps we just get 
> lucky that nothing checks the IRR in the IOAPIC coupled with a bug in 
> the IOAPIC model that an APIC message is sent out even if the 
> interrupt is not acknowledged.  It would explain why it works today, 
> anyway.  Either way, I would like to get this modeled "right" this 
> go-round, so the point is moot.

on real hardware, some devices produce edges, some devices produce level 
signals that need to be deasserted. The basic model of a PIC is that it 
has 'pins', which convert the signal arriving on those pins into 
interrupts. Qemu itself should only know about the pin enumeration, and 
should only be able to raise/lower the (virtual) 'signal' on such a pin.

PCI can be level and edge triggered too, and IO-APICs can be programmed 
on a per-pin basis to detect edge-high, edge-low, level-high, level-low 
signals.

there is a remote possibility that some OSs depend on certain devices 
being level-triggered: for example if you get an IRQ from a 
level-triggered device and _dont_ deassert that signal from the IRQ 
handler (intentionally so), then the semantics of current hardware will 
cause a second interrupt to be sent by the PIC, after the APIC message 
has been EOI-ed in the local APIC. While such "repeat interrupts" would 
be pure madness to rely on i think, i'm not sure it's not being done. 
Note that if the same IO-APIC pin is set up to detect edges then not 
deasserting the signal would not cause a 'repeat interrupt'. Whether 
such accurate emulation of signalling is needed depends on the hardware 
semantics of the devices we emulate.

	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

  parent reply	other threads:[~2007-04-04 20:20 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 [this message]
     [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
     [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=20070404202046.GD6070@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