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 Mon, Sep 5, 2011 at 8:38 AM, Edgar E. Iglesias
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 Kivity wrote:
>> >> On 08/30/2011 10:19 PM, Blue Swirl wrote:
>> >>>
>>
>>
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 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 speci
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 upd
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 d
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
On 5 September 2011 09:51, Avi Kivity 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 case
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 sta
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 Kivity wrote:
> >> On 08/30/2011 10:19 PM, Blue Swirl wrote:
> >>>
>
> We need some kind of two phase restore. In the first phase all st
On Sun, Sep 4, 2011 at 3:31 PM, Anthony Liguori wrote:
> On 09/04/2011 10:20 AM, Blue Swirl wrote:
>>
>> On Sun, Sep 4, 2011 at 2:37 PM, Anthony Liguori
>> 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 1
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 y
On 09/04/2011 10:20 AM, Blue Swirl wrote:
On Sun, Sep 4, 2011 at 2:37 PM, Anthony Liguori 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
On Sun, Sep 4, 2011 at 2:43 PM, Anthony Liguori 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 of
>>
On Sun, Sep 4, 2011 at 2:37 PM, Anthony Liguori 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 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 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/03/2011 04:01 PM, Blue Swirl wrote:
On Sat, Sep 3, 2011 at 7:53 PM, Anthony Liguori wrote:
On 08/31/2011 11:59 AM, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivitywrote:
On 08/30/2011 10:19 PM, Blue Swirl wrote:
We need some kind of two phase restore. In the fir
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 be
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 ga
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 device
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 mod
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 b
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 rep
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 Kiszka wrote:
>> Yes, that's th
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 wr
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 Kiszka wrote:
Yes, that's the current state. Once we have bidirectional IRQ
links in
plac
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 Kiszka wrote:
>> Yes, that's t
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 Kiszka wrote:
>> Yes, that's the current state. Once we have bidirectional IRQ links in
>> place (pushing downward, querying upward - requi
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 Kiszka wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place (
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 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 Kiszka wrote:
>> >> Yes, that's the current state. Once we have bidirectional IRQ
>> links in
>> >> place (pushing downward, querying
> On Wed, Aug 31, 2011 at 6:17 PM, Jan Kiszka wrote:
>> On 2011-08-31 19:41, Blue Swirl wrote:
>>> On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
> On 30 August 2011 20:28, Jan Kiszka wrote:
>> Yes, that's the current state. Once we hav
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 Kiszka 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, l
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 Kiszka wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place (pushing downward, querying upw
On Wed, Aug 31, 2011 at 7:44 PM, Blue Swirl wrote:
> On Wed, Aug 31, 2011 at 6:17 PM, Jan Kiszka wrote:
>> On 2011-08-31 19:41, Blue Swirl wrote:
>>> On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka wrote:
On 2011-08-31 10:25, Peter Maydell wrote:
> On 30 August 2011 20:28, Jan Kiszka wrot
On Sat, Sep 3, 2011 at 9:41 PM, Anthony Liguori wrote:
> On 09/03/2011 04:10 PM, Blue Swirl wrote:
>>
>> On Sat, Sep 3, 2011 at 8:07 PM, Anthony Liguori
>> wrote:
>>>
>>> On 09/01/2011 12:58 AM, Avi Kivity wrote:
On 08/31/2011 07:59 PM, Blue Swirl wrote:
>
>>
>> That makes i
On 09/03/2011 04:10 PM, Blue Swirl wrote:
On Sat, Sep 3, 2011 at 8:07 PM, Anthony Liguori 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 t
On Sat, Sep 3, 2011 at 8:07 PM, Anthony Liguori 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 o
On Sat, Sep 3, 2011 at 7:53 PM, Anthony Liguori wrote:
> On 08/31/2011 11:59 AM, Blue Swirl wrote:
>>
>> On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivity 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
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 stat
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 Kiszka 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 deliv
On 08/31/2011 11:59 AM, Blue Swirl wrote:
On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivity 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
dev
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 multiph
On Wed, Aug 31, 2011 at 6:17 PM, Jan Kiszka wrote:
> On 2011-08-31 19:41, Blue Swirl wrote:
>> On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka wrote:
>>> On 2011-08-31 10:25, Peter Maydell wrote:
On 30 August 2011 20:28, Jan Kiszka wrote:
> Yes, that's the current state. Once we have bidir
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 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 2011-08-31 19:41, Blue Swirl wrote:
> On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka wrote:
>> On 2011-08-31 10:25, Peter Maydell wrote:
>>> On 30 August 2011 20:28, Jan Kiszka wrote:
Yes, that's the current state. Once we have bidirectional IRQ links in
place (pushing downward, queryi
On Wed, Aug 31, 2011 at 04:59:40PM +, Blue Swirl wrote:
> On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivity 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 driv
On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka wrote:
> On 2011-08-31 10:25, Peter Maydell wrote:
>> On 30 August 2011 20:28, Jan Kiszka 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 8:28 AM, Avi Kivity 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 experie
On 2011-08-31 10:25, Peter Maydell wrote:
> On 30 August 2011 20:28, Jan Kiszka 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.
>
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 d
On 30 August 2011 20:28, Jan Kiszka 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 this? I don't t
On Tue, Aug 30, 2011 at 7:28 PM, Jan Kiszka wrote:
> On 2011-08-30 21:19, Blue Swirl wrote:
>> On Mon, Aug 29, 2011 at 9:13 PM, 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 othe
On 2011-08-30 21:19, Blue Swirl wrote:
> On Mon, Aug 29, 2011 at 9:13 PM, 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 t
On Mon, Aug 29, 2011 at 9:13 PM, 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 o
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
>
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 re-a
On 2011-08-29 21:25, Anthony Liguori wrote:
> On 08/27/2011 09:16 AM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> 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 pic
On 08/27/2011 09:16 AM, Jan Kiszka wrote:
From: Jan Kiszka
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 trac
On 2011-08-28 09:10, Blue Swirl wrote:
> On Sat, Aug 27, 2011 at 2:16 PM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> 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 C
On Sat, Aug 27, 2011 at 2:16 PM, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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
From: Jan Kiszka
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 already re-assert the C
63 matches
Mail list logo
