On 09/05/2011 10:36 PM, Blue Swirl wrote:
I don't agree. That's not what qemu_irq represents.
It represents a wire, a mechanism to drive changes through logic paths
between state. It is intrinsically stateless.
It may be the case that it is missused in some places, or that it isn't
On 09/05/2011 11:38 AM, Edgar E. Iglesias wrote:
We shouldn't really use the term IRQ as it's confusing. I like the term
pin better because that describes what we're really talking about.
qemu_irq is designed oddly today because is represents something that is
intrinsically state
On 5 September 2011 09:51, Avi Kivity a...@redhat.com wrote:
On 09/05/2011 11:38 AM, Edgar E. Iglesias wrote:
I don't agree. That's not what qemu_irq represents.
It represents a wire, a mechanism to drive changes through logic paths
between state. It is intrinsically stateless.
It may be the
On 09/05/2011 12:02 PM, Peter Maydell wrote:
I agree that qemu_irq is inherently stateless. But I do think there should
be a way for the sink to query the line level. Whether it is implemented as
a cache of the last qemu_set() level, or with callbacks that query the
underlying state is
On Mon, Sep 05, 2011 at 11:51:01AM +0300, Avi Kivity wrote:
On 09/05/2011 11:38 AM, Edgar E. Iglesias wrote:
We shouldn't really use the term IRQ as it's confusing. I like the term
pin better because that describes what we're really talking about.
qemu_irq is designed oddly
On 09/05/2011 12:22 PM, Edgar E. Iglesias wrote:
(real hardware can query a line at any time, yes?)
IMO, the query is just an upside-down way of thinking of it.
What happens is, you change some state, and the state drives changes through
a logic path towards new state that picks up the
On Sun, Sep 04, 2011 at 08:57:31AM -0500, Anthony Liguori wrote:
On 09/04/2011 08:49 AM, Jan Kiszka wrote:
On 2011-09-04 15:41, Anthony Liguori wrote:
On 09/04/2011 08:36 AM, Jan Kiszka wrote:
On 2011-09-04 15:32, Anthony Liguori wrote:
I prefer to not think of IRQs as special things.
On Mon, Sep 05, 2011 at 12:28:50PM +0300, Avi Kivity wrote:
...
Query is needed when a line is masked internally, or when a device is
hot-plugged.
We can work around masking by caching the level in the device even
though the line is masked, and querying the cache when the line is
On Mon, Sep 5, 2011 at 8:38 AM, Edgar E. Iglesias
edgar.igles...@gmail.com wrote:
On Sat, Sep 03, 2011 at 02:53:31PM -0500, Anthony Liguori wrote:
On 08/31/2011 11:59 AM, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivitya...@redhat.com wrote:
On 08/30/2011 10:19 PM, Blue Swirl
On Sat, Sep 3, 2011 at 9:41 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 09/03/2011 04:10 PM, Blue Swirl wrote:
On Sat, Sep 3, 2011 at 8:07 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
On 09/01/2011 12:58 AM, Avi Kivity wrote:
On 08/31/2011 07:59 PM, Blue Swirl wrote:
That
On Wed, Aug 31, 2011 at 7:44 PM, Blue Swirl blauwir...@gmail.com wrote:
On Wed, Aug 31, 2011 at 6:17 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-08-31 19:41, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-08-31 10:25, Peter Maydell
On 2011-09-03 21:54, Anthony Liguori wrote:
On 08/31/2011 05:53 AM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszkajan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place (pushing downward, querying
On 08/31/2011 01:53 PM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszkajan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place (pushing downward, querying upward - required to skip IRQ routers
On Wed, Aug 31, 2011 at 6:17 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-08-31 19:41, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszka jan.kis...@web.de wrote:
On 2011-09-04 14:17, Avi Kivity wrote:
On 08/31/2011 01:53 PM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszkajan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional IRQ
links in
place (pushing downward,
On 09/04/2011 03:37 PM, Jan Kiszka wrote:
(here it's strictly an optimization; with the memory API it's a
requirement since kvm requires a flattened representation, and tcg is
greatly simplified by it).
With current kvm device assignment it's mandatory as it only support
kernel/kernel
On 09/04/2011 07:13 AM, Jan Kiszka wrote:
On 2011-09-03 21:54, Anthony Liguori wrote:
On 08/31/2011 05:53 AM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszkajan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional
On 09/04/2011 07:17 AM, Avi Kivity wrote:
On 08/31/2011 01:53 PM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszkajan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place (pushing downward, querying
On 2011-09-04 15:32, Anthony Liguori wrote:
On 09/04/2011 07:13 AM, Jan Kiszka wrote:
On 2011-09-03 21:54, Anthony Liguori wrote:
On 08/31/2011 05:53 AM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszkajan.kis...@web.de wrote:
Yes, that's the
On 09/04/2011 07:37 AM, Jan Kiszka wrote:
On 2011-09-04 14:17, Avi Kivity wrote:
On 08/31/2011 01:53 PM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszkajan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional IRQ
On 09/04/2011 08:36 AM, Jan Kiszka wrote:
On 2011-09-04 15:32, Anthony Liguori wrote:
I prefer to not think of IRQs as special things. They're just single
bits of information that flow through the device model. Having a higher
level representation that understands something like paths seems
On 2011-09-04 15:38, Anthony Liguori wrote:
On 09/04/2011 07:37 AM, Jan Kiszka wrote:
On 2011-09-04 14:17, Avi Kivity wrote:
On 08/31/2011 01:53 PM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszkajan.kis...@web.de wrote:
Yes, that's the
On 2011-09-04 15:41, Anthony Liguori wrote:
On 09/04/2011 08:36 AM, Jan Kiszka wrote:
On 2011-09-04 15:32, Anthony Liguori wrote:
I prefer to not think of IRQs as special things. They're just single
bits of information that flow through the device model. Having a higher
level representation
On 09/04/2011 08:42 AM, Jan Kiszka wrote:
On 2011-09-04 15:38, Anthony Liguori wrote:
With current kvm device assignment it's mandatory as it only support
kernel/kernel IRQ delivery. Only vfio's eventfds will make it optional
(but still highly desirable).
It's not mandatory. All you need to
On 09/04/2011 08:49 AM, Jan Kiszka wrote:
On 2011-09-04 15:41, Anthony Liguori wrote:
On 09/04/2011 08:36 AM, Jan Kiszka wrote:
On 2011-09-04 15:32, Anthony Liguori wrote:
I prefer to not think of IRQs as special things. They're just single
bits of information that flow through the device
On 09/04/2011 04:41 PM, Anthony Liguori wrote:
See it as you like, but we need the support, not only for device
assigment. And I do not see any gain it hacking this instead of
designing it.
You can design a hack but it's still a hack.
Device state belongs in devices. Trying to extract
On 09/04/2011 08:57 AM, Anthony Liguori wrote:
On 09/04/2011 08:49 AM, Jan Kiszka wrote:
On 2011-09-04 15:41, Anthony Liguori wrote:
On 09/04/2011 08:36 AM, Jan Kiszka wrote:
Having some sort of global interrupt routing table is just going to add
a layer of complexity for very little obvious
On 09/04/2011 09:12 AM, Avi Kivity wrote:
On 09/04/2011 04:41 PM, Anthony Liguori wrote:
See it as you like, but we need the support, not only for device
assigment. And I do not see any gain it hacking this instead of
designing it.
You can design a hack but it's still a hack.
Device state
On 09/03/2011 04:01 PM, Blue Swirl wrote:
On Sat, Sep 3, 2011 at 7:53 PM, Anthony Liguorianth...@codemonkey.ws wrote:
On 08/31/2011 11:59 AM, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivitya...@redhat.comwrote:
On 08/30/2011 10:19 PM, Blue Swirl wrote:
We need some
On 09/04/2011 05:43 PM, Anthony Liguori wrote:
Pet peeve - saying something is by definition a hack is just rhetoric
unless the definition of device state is something that cannot be
extracted and externalized. Let's avoid this.
Likewise, I would prefer to avoid stating that something is a
On 09/04/2011 10:03 AM, Avi Kivity wrote:
On 09/04/2011 05:43 PM, Anthony Liguori wrote:
In fact it's exactly what we do with the memory API. Memory routing is
part of device state, yet we expose it to the memory API and let it do
its thing instead of going through the hierarchy on every single
On Sun, Sep 4, 2011 at 2:37 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 09/04/2011 08:57 AM, Anthony Liguori wrote:
On 09/04/2011 08:49 AM, Jan Kiszka wrote:
On 2011-09-04 15:41, Anthony Liguori wrote:
On 09/04/2011 08:36 AM, Jan Kiszka wrote:
Having some sort of global interrupt
On Sun, Sep 4, 2011 at 2:43 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 09/04/2011 09:12 AM, Avi Kivity wrote:
On 09/04/2011 04:41 PM, Anthony Liguori wrote:
See it as you like, but we need the support, not only for device
assigment. And I do not see any gain it hacking this instead
On 09/04/2011 10:20 AM, Blue Swirl wrote:
On Sun, Sep 4, 2011 at 2:37 PM, Anthony Liguorianth...@codemonkey.ws wrote:
On 09/04/2011 08:57 AM, Anthony Liguori wrote:
On 09/04/2011 08:49 AM, Jan Kiszka wrote:
On 2011-09-04 15:41, Anthony Liguori wrote:
On 09/04/2011 08:36 AM, Jan Kiszka
On 09/04/2011 06:19 PM, Anthony Liguori wrote:
Yes, and the memory API is complicated and invasive :-) But it's worth
it at the end of the day (although I think it could be simplified at
the expensive of not allowing as much flattening).
(we should have spent a few hours at kf2011 to convince
On Sun, Sep 4, 2011 at 3:31 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 09/04/2011 10:20 AM, Blue Swirl wrote:
On Sun, Sep 4, 2011 at 2:37 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
On 09/04/2011 08:57 AM, Anthony Liguori wrote:
On 09/04/2011 08:49 AM, Jan Kiszka wrote:
On
On 08/31/2011 11:59 AM, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivitya...@redhat.com wrote:
On 08/30/2011 10:19 PM, Blue Swirl wrote:
We need some kind of two phase restore. In the first phase all state is
restored; since some of that state drivers outputs that are
On 08/31/2011 05:53 AM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszkajan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place (pushing downward, querying upward - required to skip IRQ routers
for
On 09/01/2011 12:58 AM, Avi Kivity wrote:
On 08/31/2011 07:59 PM, Blue Swirl wrote:
That makes it impossible to migrate level-triggered irq lines. Or at
least,
the receiver has to remember the state, instead of (or in addition
to) the
sender.
Both ends probably need to remember the state.
On Sat, Sep 3, 2011 at 7:53 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 08/31/2011 11:59 AM, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivitya...@redhat.com wrote:
On 08/30/2011 10:19 PM, Blue Swirl wrote:
We need some kind of two phase restore. In the first phase
On Sat, Sep 3, 2011 at 8:07 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 09/01/2011 12:58 AM, Avi Kivity wrote:
On 08/31/2011 07:59 PM, Blue Swirl wrote:
That makes it impossible to migrate level-triggered irq lines. Or at
least,
the receiver has to remember the state, instead of
On 09/03/2011 04:10 PM, Blue Swirl wrote:
On Sat, Sep 3, 2011 at 8:07 PM, Anthony Liguorianth...@codemonkey.ws wrote:
On 09/01/2011 12:58 AM, Avi Kivity wrote:
On 08/31/2011 07:59 PM, Blue Swirl wrote:
That makes it impossible to migrate level-triggered irq lines. Or at
least,
the
On 30 August 2011 20:28, Jan Kiszka jan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place (pushing downward, querying upward - required to skip IRQ routers
for fast, lockless deliveries), that should change again.
Can you elaborate a bit more on
On 08/30/2011 10:19 PM, Blue Swirl wrote:
We need some kind of two phase restore. In the first phase all state is
restored; since some of that state drivers outputs that are input to other
devices, they may experience an edge, and we need to supress that. In the
second phase edge
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszka jan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place (pushing downward, querying upward - required to skip IRQ routers
for fast, lockless deliveries), that should
On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivity a...@redhat.com wrote:
On 08/30/2011 10:19 PM, Blue Swirl wrote:
We need some kind of two phase restore. In the first phase all state is
restored; since some of that state drivers outputs that are input to
other
devices, they may
On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszka jan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place (pushing downward, querying upward -
On Wed, Aug 31, 2011 at 04:59:40PM +, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivity a...@redhat.com wrote:
On 08/30/2011 10:19 PM, Blue Swirl wrote:
We need some kind of two phase restore. In the first phase all state is
restored; since some of that state
On 2011-08-31 19:41, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszka jan.kis...@web.de wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place
On 2011-08-31 20:04, Edgar E. Iglesias wrote:
On Wed, Aug 31, 2011 at 04:59:40PM +, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivity a...@redhat.com wrote:
On 08/30/2011 10:19 PM, Blue Swirl wrote:
We need some kind of two phase restore. In the first phase all state is
On Wed, Aug 31, 2011 at 6:17 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-08-31 19:41, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszka jan.kis...@web.de wrote:
On 08/31/2011 07:59 PM, Blue Swirl wrote:
That makes it impossible to migrate level-triggered irq lines. Or at least,
the receiver has to remember the state, instead of (or in addition to) the
sender.
Both ends probably need to remember the state. That should work
without any multiphase
On Mon, Aug 29, 2011 at 9:13 PM, Avi Kivity a...@redhat.com wrote:
On 08/30/2011 12:06 AM, Jan Kiszka wrote:
Does this need to be save/restored for migration?
Nope, but we need some other measure. I thought to remember the pic was
refreshing this after load, but I do not find any traces
On 2011-08-30 21:19, Blue Swirl wrote:
On Mon, Aug 29, 2011 at 9:13 PM, Avi Kivity a...@redhat.com wrote:
On 08/30/2011 12:06 AM, Jan Kiszka wrote:
Does this need to be save/restored for migration?
Nope, but we need some other measure. I thought to remember the pic was
refreshing this
On Tue, Aug 30, 2011 at 7:28 PM, Jan Kiszka jan.kis...@web.de wrote:
On 2011-08-30 21:19, Blue Swirl wrote:
On Mon, Aug 29, 2011 at 9:13 PM, Avi Kivity a...@redhat.com wrote:
On 08/30/2011 12:06 AM, Jan Kiszka wrote:
Does this need to be save/restored for migration?
Nope, but we need some
On 08/27/2011 09:16 AM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
The master PIC is connected to the LINTIN0 of the APICs. As the APIC
currently does not track the state of that line, we have to ask the PIC
to re-inject its IRQ after the CPU picked up an event from the APIC.
On 2011-08-29 21:25, Anthony Liguori wrote:
On 08/27/2011 09:16 AM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
The master PIC is connected to the LINTIN0 of the APICs. As the APIC
currently does not track the state of that line, we have to ask the PIC
to re-inject its IRQ after
On 08/30/2011 12:06 AM, Jan Kiszka wrote:
Does this need to be save/restored for migration?
Nope, but we need some other measure. I thought to remember the pic was
refreshing this after load, but I do not find any traces of this now. We
likely need a post_load handler in the i8259 that
On 2011-08-29 23:13, Avi Kivity wrote:
On 08/30/2011 12:06 AM, Jan Kiszka wrote:
Does this need to be save/restored for migration?
Nope, but we need some other measure. I thought to remember the pic was
refreshing this after load, but I do not find any traces of this now. We
likely need
On Sat, Aug 27, 2011 at 2:16 PM, Jan Kiszka jan.kis...@web.de wrote:
From: Jan Kiszka jan.kis...@siemens.com
The master PIC is connected to the LINTIN0 of the APICs. As the APIC
currently does not track the state of that line, we have to ask the PIC
to re-inject its IRQ after the CPU picked
On 2011-08-28 09:10, Blue Swirl wrote:
On Sat, Aug 27, 2011 at 2:16 PM, Jan Kiszka jan.kis...@web.de wrote:
From: Jan Kiszka jan.kis...@siemens.com
The master PIC is connected to the LINTIN0 of the APICs. As the APIC
currently does not track the state of that line, we have to ask the PIC
to
From: Jan Kiszka jan.kis...@siemens.com
The master PIC is connected to the LINTIN0 of the APICs. As the APIC
currently does not track the state of that line, we have to ask the PIC
to re-inject its IRQ after the CPU picked up an event from the APIC.
Adds the proper state tracking so that we can
62 matches
Mail list logo
