On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote:
I'd like to also support EOI handling. When the guest clears the
interrupt condtion, the EOI callback would be called. This could occur
much later than the IRQ delivery time. I'm not sure if we need the
result code in that case.
Gleb Natapov wrote:
On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote:
I'd like to also support EOI handling. When the guest clears the
interrupt condtion, the EOI callback would be called. This could occur
much later than the IRQ delivery time. I'm not sure if we need the
result
On Sun, Jun 6, 2010 at 7:15 AM, Gleb Natapov g...@redhat.com wrote:
On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote:
I'd like to also support EOI handling. When the guest clears the
interrupt condtion, the EOI callback would be called. This could occur
much later than the IRQ
On Sun, Jun 06, 2010 at 09:39:04AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote:
I'd like to also support EOI handling. When the guest clears the
interrupt condtion, the EOI callback would be called. This could occur
much later
On Sun, Jun 06, 2010 at 07:39:49AM +, Blue Swirl wrote:
On Sun, Jun 6, 2010 at 7:15 AM, Gleb Natapov g...@redhat.com wrote:
On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote:
I'd like to also support EOI handling. When the guest clears the
interrupt condtion, the EOI callback
Gleb Natapov wrote:
On Sun, Jun 06, 2010 at 09:39:04AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote:
I'd like to also support EOI handling. When the guest clears the
interrupt condtion, the EOI callback would be called. This could
On Sun, Jun 06, 2010 at 10:07:48AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Jun 06, 2010 at 09:39:04AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote:
I'd like to also support EOI handling. When the guest clears the
Gleb Natapov wrote:
On Sun, Jun 06, 2010 at 10:07:48AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Jun 06, 2010 at 09:39:04AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote:
I'd like to also support EOI handling. When the
On Sun, Jun 06, 2010 at 12:10:07PM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Jun 06, 2010 at 10:07:48AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Jun 06, 2010 at 09:39:04AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan
On Sat, Jun 5, 2010 at 12:04 AM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Thu, Jun 3, 2010 at 7:06 AM, Gleb Natapov g...@redhat.com wrote:
On Thu, Jun 03, 2010 at 10:03:00AM +0300, Gleb Natapov wrote:
On Thu, Jun 03, 2010 at 08:59:23AM +0200, Jan Kiszka wrote:
Gleb Natapov
Blue Swirl wrote:
On Sat, Jun 5, 2010 at 12:04 AM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Thu, Jun 3, 2010 at 7:06 AM, Gleb Natapov g...@redhat.com wrote:
On Thu, Jun 03, 2010 at 10:03:00AM +0300, Gleb Natapov wrote:
On Thu, Jun 03, 2010 at 08:59:23AM +0200, Jan Kiszka
On Sat, Jun 5, 2010 at 8:27 AM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Sat, Jun 5, 2010 at 12:04 AM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Thu, Jun 3, 2010 at 7:06 AM, Gleb Natapov g...@redhat.com wrote:
On Thu, Jun 03, 2010 at 10:03:00AM +0300, Gleb
Blue Swirl wrote:
On Sat, Jun 5, 2010 at 8:27 AM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Sat, Jun 5, 2010 at 12:04 AM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Thu, Jun 3, 2010 at 7:06 AM, Gleb Natapov g...@redhat.com wrote:
On Thu, Jun 03, 2010 at
On Thu, Jun 3, 2010 at 7:06 AM, Gleb Natapov g...@redhat.com wrote:
On Thu, Jun 03, 2010 at 10:03:00AM +0300, Gleb Natapov wrote:
On Thu, Jun 03, 2010 at 08:59:23AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Thu, Jun 03, 2010 at 08:23:46AM +0200, Jan Kiszka wrote:
Blue Swirl wrote:
Blue Swirl wrote:
On Thu, Jun 3, 2010 at 7:06 AM, Gleb Natapov g...@redhat.com wrote:
On Thu, Jun 03, 2010 at 10:03:00AM +0300, Gleb Natapov wrote:
On Thu, Jun 03, 2010 at 08:59:23AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Thu, Jun 03, 2010 at 08:23:46AM +0200, Jan Kiszka wrote:
Blue
Blue Swirl wrote:
But how about if we introduced instead a message based IRQ? Then the
message could specify the originator device, maybe ACK/coalesce/NACK
callbacks and a bigger payload than just 1 bit of level. I think that
could achieve the same coalescing effect as what the bidirectional
On Thu, Jun 03, 2010 at 08:23:46AM +0200, Jan Kiszka wrote:
Blue Swirl wrote:
But how about if we introduced instead a message based IRQ? Then the
message could specify the originator device, maybe ACK/coalesce/NACK
callbacks and a bigger payload than just 1 bit of level. I think that
Gleb Natapov wrote:
On Thu, Jun 03, 2010 at 08:23:46AM +0200, Jan Kiszka wrote:
Blue Swirl wrote:
But how about if we introduced instead a message based IRQ? Then the
message could specify the originator device, maybe ACK/coalesce/NACK
callbacks and a bigger payload than just 1 bit of level.
On Thu, Jun 03, 2010 at 08:59:23AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Thu, Jun 03, 2010 at 08:23:46AM +0200, Jan Kiszka wrote:
Blue Swirl wrote:
But how about if we introduced instead a message based IRQ? Then the
message could specify the originator device, maybe
On Thu, Jun 03, 2010 at 10:03:00AM +0300, Gleb Natapov wrote:
On Thu, Jun 03, 2010 at 08:59:23AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Thu, Jun 03, 2010 at 08:23:46AM +0200, Jan Kiszka wrote:
Blue Swirl wrote:
But how about if we introduced instead a message based IRQ? Then
On Tue, Jun 1, 2010 at 6:30 PM, Gleb Natapov g...@redhat.com wrote:
On Tue, Jun 01, 2010 at 06:00:20PM +, Blue Swirl wrote:
Looks like irr in apic is never cleared. Probably bug in userspace apic
emulation. I'll look into it. Try to route interrupt via APIC (not
ExtInt),
or use
On Mon, May 31, 2010 at 5:19 AM, Gleb Natapov g...@redhat.com wrote:
On Sun, May 30, 2010 at 08:21:30PM +, Blue Swirl wrote:
On Sun, May 30, 2010 at 8:07 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, May 30, 2010 at 07:37:59PM +, Blue Swirl wrote:
On Sun, May 30, 2010 at 1:49 PM,
On Tue, Jun 01, 2010 at 06:00:20PM +, Blue Swirl wrote:
Looks like irr in apic is never cleared. Probably bug in userspace apic
emulation. I'll look into it. Try to route interrupt via APIC (not
ExtInt),
or use qemu-kvm with in kernel irq chip.
With APIC you mean Fixed? Then
Blue Swirl wrote:
On Sun, May 30, 2010 at 12:24 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
Linux don't use RTC as time source and I don't know about BSD, so no
Linux or BSD test case for you, sorry. Run WindowXP standard HAL and put
heavy load on the host. You can run video
On Sat, May 29, 2010 at 09:21:14PM +, Blue Swirl wrote:
On Sat, May 29, 2010 at 4:37 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, May 29, 2010 at 04:13:22PM +, Blue Swirl wrote:
On Sat, May 29, 2010 at 2:46 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, May 29, 2010 at
2010/5/30 Gleb Natapov g...@redhat.com:
On Sat, May 29, 2010 at 08:52:34PM +, Blue Swirl wrote:
On Sat, May 29, 2010 at 4:32 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, May 29, 2010 at 04:03:22PM +, Blue Swirl wrote:
2010/5/29 Gleb Natapov g...@redhat.com:
On Sat, May 29, 2010
On 05/28/2010 01:19 AM, Jan Kiszka wrote:
Still, this does not answer:
- How do you want to detect lost timer ticks?
Your (and Gleb's) approach: during injection
An alternative: during guest ack
The normal pattern is inj/ack/inj/ack; if we see inj/inj/inj we know the
guest isn't
On 05/29/2010 12:15 PM, Blue Swirl wrote:
This would allow counting the executed instructions and limit it. Thus
we could emulate a 500MHz CPU on a 2GHz CPU more accurately.
Why would you want to limit number of instruction executed by guest if
CPU has nothing else to do anyway? The
2010/5/30 Gleb Natapov g...@redhat.com:
On Sat, May 29, 2010 at 09:21:14PM +, Blue Swirl wrote:
On Sat, May 29, 2010 at 4:37 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, May 29, 2010 at 04:13:22PM +, Blue Swirl wrote:
On Sat, May 29, 2010 at 2:46 PM, Gleb Natapov g...@redhat.com
Blue Swirl wrote:
Linux don't use RTC as time source and I don't know about BSD, so no
Linux or BSD test case for you, sorry. Run WindowXP standard HAL and put
heavy load on the host. You can run video inside the gust to trigger
coalescing more easily.
I don't have Windows XP, sorry.
On Sun, May 30, 2010 at 12:10:16PM +, Blue Swirl wrote:
You missed the key word 'stopped'. If the timer is really stopped, no
IRQs should ever come out afterwards, just like on real HW. For the
emulation, this means loss of ticks which should have been delivered
before the change.
2010/5/30 Gleb Natapov g...@redhat.com:
On Sun, May 30, 2010 at 12:10:16PM +, Blue Swirl wrote:
You missed the key word 'stopped'. If the timer is really stopped, no
IRQs should ever come out afterwards, just like on real HW. For the
emulation, this means loss of ticks which should
On Sun, May 30, 2010 at 12:24 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
Linux don't use RTC as time source and I don't know about BSD, so no
Linux or BSD test case for you, sorry. Run WindowXP standard HAL and put
heavy load on the host. You can run video inside the gust to
2010/5/30 Gleb Natapov g...@redhat.com:
On Sun, May 30, 2010 at 12:10:16PM +, Blue Swirl wrote:
You missed the key word 'stopped'. If the timer is really stopped, no
IRQs should ever come out afterwards, just like on real HW. For the
emulation, this means loss of ticks which should
On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote:
Well, I'd like to get the test program also trigger it. Now I'm getting:
apic: write: 0350 =
apic: apic_reset_irq_delivered: old coalescing 0
apic: apic_local_deliver: vector 3 delivery mode 0
apic: apic_set_irq:
On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote:
Well, I'd like to get the test program also trigger it. Now I'm getting:
apic: write: 0350 =
apic: apic_reset_irq_delivered: old coalescing 0
apic:
On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote:
Well, I'd like to get the test program also trigger it. Now I'm getting:
apic: write: 0350 =
apic: apic_reset_irq_delivered: old coalescing 0
apic:
On Sun, May 30, 2010 at 07:37:59PM +, Blue Swirl wrote:
On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote:
Well, I'd like to get the test program also trigger it. Now I'm getting:
apic: write: 0350 =
On Sun, May 30, 2010 at 8:07 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, May 30, 2010 at 07:37:59PM +, Blue Swirl wrote:
On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote:
Well, I'd like to get the test
On Sun, May 30, 2010 at 08:21:30PM +, Blue Swirl wrote:
On Sun, May 30, 2010 at 8:07 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, May 30, 2010 at 07:37:59PM +, Blue Swirl wrote:
On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, May 30, 2010 at
On Sat, May 29, 2010 at 09:15:11AM +, Blue Swirl wrote:
There is no code, because we're still at architecture design stage.
Try to write test code to understand the problem better.
I will.
Please do ASAP. This discussion shows that you don't understand what is the
problem that we
On Sat, May 29, 2010 at 09:35:30AM +, Blue Swirl wrote:
I still don't see how the alternative is supposed to simplify our life
or improve the efficiency of the de-coalescing workaround. It's rather
problematic like Gleb pointed out: The de-coalescing logic needs to be
informed about
On Sat, May 29, 2010 at 10:16 AM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
This is - according to my current understanding - the proposed
alternative architecture:
.---.
| de-coalescing
Blue Swirl wrote:
This is - according to my current understanding - the proposed
alternative architecture:
.---.
| de-coalescing |
| logic |
Gleb Natapov wrote:
On Fri, May 28, 2010 at 08:06:45PM +, Blue Swirl wrote:
2010/5/28 Gleb Natapov g...@redhat.com:
On Thu, May 27, 2010 at 06:37:10PM +, Blue Swirl wrote:
2010/5/27 Gleb Natapov g...@redhat.com:
On Wed, May 26, 2010 at 08:35:00PM +, Blue Swirl wrote:
On Wed, May
Blue Swirl wrote:
2010/5/29 Jan Kiszka jan.kis...@web.de:
Gleb Natapov wrote:
On Fri, May 28, 2010 at 08:06:45PM +, Blue Swirl wrote:
2010/5/28 Gleb Natapov g...@redhat.com:
On Thu, May 27, 2010 at 06:37:10PM +, Blue Swirl wrote:
2010/5/27 Gleb Natapov g...@redhat.com:
On Wed, May
On Sat, May 29, 2010 at 9:45 AM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
2010/5/29 Jan Kiszka jan.kis...@web.de:
Gleb Natapov wrote:
On Fri, May 28, 2010 at 08:06:45PM +, Blue Swirl wrote:
2010/5/28 Gleb Natapov g...@redhat.com:
On Thu, May 27, 2010 at 06:37:10PM +,
Blue Swirl wrote:
On the contrary, APIC is actually the only source of the IRQ ack
information. RTC hack would not work without APIC (or the
bidirectional IRQ) passing this info to RTC.
What APIC doesn't have now is the timer frequency or period info. This
is known by RTC and also higher
2010/5/28 Gleb Natapov g...@redhat.com:
On Fri, May 28, 2010 at 08:06:45PM +, Blue Swirl wrote:
2010/5/28 Gleb Natapov g...@redhat.com:
On Thu, May 27, 2010 at 06:37:10PM +, Blue Swirl wrote:
2010/5/27 Gleb Natapov g...@redhat.com:
On Wed, May 26, 2010 at 08:35:00PM +, Blue
On Sat, May 29, 2010 at 04:03:22PM +, Blue Swirl wrote:
2010/5/29 Gleb Natapov g...@redhat.com:
On Sat, May 29, 2010 at 09:15:11AM +, Blue Swirl wrote:
There is no code, because we're still at architecture design stage.
Try to write test code to understand the problem better.
On Sat, May 29, 2010 at 2:46 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, May 29, 2010 at 09:35:30AM +, Blue Swirl wrote:
I still don't see how the alternative is supposed to simplify our life
or improve the efficiency of the de-coalescing workaround. It's rather
problematic like
Blue Swirl wrote:
On Sat, May 29, 2010 at 10:16 AM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
This is - according to my current understanding - the proposed
alternative architecture:
.---.
On Sat, May 29, 2010 at 04:13:22PM +, Blue Swirl wrote:
On Sat, May 29, 2010 at 2:46 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, May 29, 2010 at 09:35:30AM +, Blue Swirl wrote:
I still don't see how the alternative is supposed to simplify our life
or improve the efficiency of
On Sat, May 29, 2010 at 4:32 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, May 29, 2010 at 04:03:22PM +, Blue Swirl wrote:
2010/5/29 Gleb Natapov g...@redhat.com:
On Sat, May 29, 2010 at 09:15:11AM +, Blue Swirl wrote:
There is no code, because we're still at architecture design
On Sat, May 29, 2010 at 08:52:34PM +, Blue Swirl wrote:
On Sat, May 29, 2010 at 4:32 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, May 29, 2010 at 04:03:22PM +, Blue Swirl wrote:
2010/5/29 Gleb Natapov g...@redhat.com:
On Sat, May 29, 2010 at 09:15:11AM +, Blue Swirl wrote:
On Thu, May 27, 2010 at 06:37:10PM +, Blue Swirl wrote:
2010/5/27 Gleb Natapov g...@redhat.com:
On Wed, May 26, 2010 at 08:35:00PM +, Blue Swirl wrote:
On Wed, May 26, 2010 at 8:09 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Tue, May 25, 2010 at 9:44 PM, Jan
On Thu, May 27, 2010 at 10:19 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Thu, May 27, 2010 at 7:08 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Thu, May 27, 2010 at 6:31 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Wed, May 26, 2010 at 11:26
On Thu, May 27, 2010 at 10:21 PM, Paul Brook p...@codesourcery.com wrote:
Then the amount
of CPU cycles between timer interrupts would increase and hopefully
the guest can keep up. If the guest sleeps, time base could be
accelerated to catch up with wall clock and then set back to 1:1
2010/5/28 Gleb Natapov g...@redhat.com:
On Thu, May 27, 2010 at 06:37:10PM +, Blue Swirl wrote:
2010/5/27 Gleb Natapov g...@redhat.com:
On Wed, May 26, 2010 at 08:35:00PM +, Blue Swirl wrote:
On Wed, May 26, 2010 at 8:09 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Fri, May 28, 2010 at 08:06:45PM +, Blue Swirl wrote:
2010/5/28 Gleb Natapov g...@redhat.com:
On Thu, May 27, 2010 at 06:37:10PM +, Blue Swirl wrote:
2010/5/27 Gleb Natapov g...@redhat.com:
On Wed, May 26, 2010 at 08:35:00PM +, Blue Swirl wrote:
On Wed, May 26, 2010 at
On Wed, May 26, 2010 at 10:09:52PM +0200, Jan Kiszka wrote:
Blue Swirl wrote:
On Tue, May 25, 2010 at 9:44 PM, Jan Kiszka jan.kis...@web.de wrote:
Anthony Liguori wrote:
On 05/25/2010 02:09 PM, Blue Swirl wrote:
On Mon, May 24, 2010 at 8:13 PM, Jan Kiszkajan.kis...@web.de wrote:
On Wed, May 26, 2010 at 08:35:00PM +, Blue Swirl wrote:
On Wed, May 26, 2010 at 8:09 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Tue, May 25, 2010 at 9:44 PM, Jan Kiszka jan.kis...@web.de wrote:
Anthony Liguori wrote:
On 05/25/2010 02:09 PM, Blue Swirl wrote:
On
On Wed, May 26, 2010 at 08:14:38PM +, Blue Swirl wrote:
On Wed, May 26, 2010 at 8:08 AM, Gleb Natapov g...@redhat.com wrote:
On Tue, May 25, 2010 at 11:44:50PM +0200, Jan Kiszka wrote:
I think the real solution to coalescing is put the logic inside one
device, in this case APIC
On Wed, May 26, 2010 at 11:26 PM, Paul Brook p...@codesourcery.com wrote:
At the other extreme, would it be possible to make the educated guests
aware of the virtualization also in clock aspect: virtio-clock?
The guest doesn't even need to be aware of virtualization. It just needs to be
able
2010/5/27 Gleb Natapov g...@redhat.com:
On Wed, May 26, 2010 at 08:35:00PM +, Blue Swirl wrote:
On Wed, May 26, 2010 at 8:09 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Tue, May 25, 2010 at 9:44 PM, Jan Kiszka jan.kis...@web.de wrote:
Anthony Liguori wrote:
On
Blue Swirl wrote:
On Wed, May 26, 2010 at 11:26 PM, Paul Brook p...@codesourcery.com wrote:
At the other extreme, would it be possible to make the educated guests
aware of the virtualization also in clock aspect: virtio-clock?
The guest doesn't even need to be aware of virtualization. It just
On Thu, May 27, 2010 at 6:31 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Wed, May 26, 2010 at 11:26 PM, Paul Brook p...@codesourcery.com wrote:
At the other extreme, would it be possible to make the educated guests
aware of the virtualization also in clock aspect:
Blue Swirl wrote:
On Thu, May 27, 2010 at 6:31 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Wed, May 26, 2010 at 11:26 PM, Paul Brook p...@codesourcery.com wrote:
At the other extreme, would it be possible to make the educated guests
aware of the virtualization also in clock
On Thu, May 27, 2010 at 7:08 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Thu, May 27, 2010 at 6:31 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Wed, May 26, 2010 at 11:26 PM, Paul Brook p...@codesourcery.com wrote:
At the other extreme, would it be possible to
In some cases we don't even do that, and just reschedule the event some
arbitrarily small amount of time later. This assumes the guest to do
useful work in that time. In a single threaded environment this is
probably true - qemu got enough CPU to inject the first interrupt, so
will
Blue Swirl wrote:
On Thu, May 27, 2010 at 7:08 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Thu, May 27, 2010 at 6:31 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Wed, May 26, 2010 at 11:26 PM, Paul Brook p...@codesourcery.com
wrote:
At the other extreme,
Then the amount
of CPU cycles between timer interrupts would increase and hopefully
the guest can keep up. If the guest sleeps, time base could be
accelerated to catch up with wall clock and then set back to 1:1 rate.
Can't follow you ATM, sorry. What should be slowed down then? And
On Tue, May 25, 2010 at 11:44:50PM +0200, Jan Kiszka wrote:
I think the real solution to coalescing is put the logic inside one
device, in this case APIC because it has the information about irq
delivery. APIC could monitor incoming RTC irqs for frequency
information and whether they
On Tue, May 25, 2010 at 9:44 PM, Jan Kiszka jan.kis...@web.de wrote:
Anthony Liguori wrote:
On 05/25/2010 02:09 PM, Blue Swirl wrote:
On Mon, May 24, 2010 at 8:13 PM, Jan Kiszkajan.kis...@web.de wrote:
From: Jan Kiszkajan.kis...@siemens.com
This allows to communicate potential IRQ
On Tue, May 25, 2010 at 8:16 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 05/25/2010 02:09 PM, Blue Swirl wrote:
On Mon, May 24, 2010 at 8:13 PM, Jan Kiszkajan.kis...@web.de wrote:
From: Jan Kiszkajan.kis...@siemens.com
This allows to communicate potential IRQ coalescing during
Blue Swirl wrote:
On Tue, May 25, 2010 at 9:44 PM, Jan Kiszka jan.kis...@web.de wrote:
Anthony Liguori wrote:
On 05/25/2010 02:09 PM, Blue Swirl wrote:
On Mon, May 24, 2010 at 8:13 PM, Jan Kiszkajan.kis...@web.de wrote:
From: Jan Kiszkajan.kis...@siemens.com
This allows to communicate
On Wed, May 26, 2010 at 8:08 AM, Gleb Natapov g...@redhat.com wrote:
On Tue, May 25, 2010 at 11:44:50PM +0200, Jan Kiszka wrote:
I think the real solution to coalescing is put the logic inside one
device, in this case APIC because it has the information about irq
delivery. APIC could
On Wed, May 26, 2010 at 8:09 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Tue, May 25, 2010 at 9:44 PM, Jan Kiszka jan.kis...@web.de wrote:
Anthony Liguori wrote:
On 05/25/2010 02:09 PM, Blue Swirl wrote:
On Mon, May 24, 2010 at 8:13 PM, Jan Kiszkajan.kis...@web.de wrote:
Blue Swirl wrote:
I think the real solution to coalescing is put the logic inside one
device, in this case APIC because it has the information about irq
delivery. APIC could monitor incoming RTC irqs for frequency
information and whether they get delivered or not. If not, an internal
timer is
At the other extreme, would it be possible to make the educated guests
aware of the virtualization also in clock aspect: virtio-clock?
The guest doesn't even need to be aware of virtualization. It just needs to be
able to accommodate the lack of guaranteed realtime behavior.
The fundamental
On Mon, May 24, 2010 at 8:13 PM, Jan Kiszka jan.kis...@web.de wrote:
From: Jan Kiszka jan.kis...@siemens.com
This allows to communicate potential IRQ coalescing during delivery from
the sink back to the source. Targets that support IRQ coalescing
workarounds need to register handlers that
On 05/25/2010 02:09 PM, Blue Swirl wrote:
On Mon, May 24, 2010 at 8:13 PM, Jan Kiszkajan.kis...@web.de wrote:
From: Jan Kiszkajan.kis...@siemens.com
This allows to communicate potential IRQ coalescing during delivery from
the sink back to the source. Targets that support IRQ coalescing
Anthony Liguori wrote:
On 05/25/2010 02:09 PM, Blue Swirl wrote:
On Mon, May 24, 2010 at 8:13 PM, Jan Kiszkajan.kis...@web.de wrote:
From: Jan Kiszkajan.kis...@siemens.com
This allows to communicate potential IRQ coalescing during delivery from
the sink back to the source. Targets that
83 matches
Mail list logo
