On 02/07/2011 09:30 PM, Anthony Liguori wrote:
For the purposes of this, I think passing an opaque is better because
the signature stays the same as the existing timer callback. That
makes conversion a bit friendlier.
I think it's better to avoid introducing stylistic changes with new
inte
On 02/07/2011 09:08 AM, Avi Kivity wrote:
On 02/07/2011 05:01 PM, Jan Kiszka wrote:
>
> On the other hand, we need a way to inject lost ticks into a
> PeriodicTimer. If interrupt injection detects that an interrupt was
> coalesced, we want the timer to schedule a new tick for us.
Isn't abse
On 02/07/2011 05:14 PM, Jan Kiszka wrote:
On 2011-02-07 16:08, Avi Kivity wrote:
> On 02/07/2011 05:01 PM, Jan Kiszka wrote:
>>>
>>> On the other hand, we need a way to inject lost ticks into a
>>> PeriodicTimer. If interrupt injection detects that an interrupt was
>>> coalesced, we want
On 02/07/2011 08:58 AM, Avi Kivity wrote:
On 02/07/2011 04:54 PM, Anthony Liguori wrote:
Why the accumulated_ticks argument?
Then the missing ticks is stored in the PeriodicTimer instead of
storing it in the device state. That means we won't forget to save
it in vmstate.
It's convenie
On 2011-02-07 16:13, Avi Kivity wrote:
>>
>> PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque);
>>
>
> void periodic_timer_init(PeriodicTimer *timer, PeriodicTimerFunc *cb);
>
> It is better to embed than to reference.
And embedding means making the layout (at least the size
On 02/07/2011 03:23 PM, Anthony Liguori wrote:
If it doesn't solve the majority of the problems it isn't very useful
IMO. It's a good first step, but not sufficient for real world use
with overcommit.
Even if we have a way to detect coalescing, we still need to make sure
we don't lose ticks
On 02/07/2011 03:11 PM, Anthony Liguori wrote:
On 02/07/2011 06:34 AM, Avi Kivity wrote:
On 02/04/2011 10:56 AM, Jan Kiszka wrote:
>
> This should be a rare event. If you are missing 50% of your
> notifications, not amount of gradual catchup is going to help you
out.
But that's the only t
On 02/07/2011 08:57 AM, Jan Kiszka wrote:
There should rather be a special vmstate struct for PeriodicTimer, just
like we already have for normal timers.
Agreed.
It's convenient because then if we lose ticks in the PeriodicTimer
layer, the devices have instance access to that info. When
On 02/04/2011 10:56 AM, Jan Kiszka wrote:
>
> This should be a rare event. If you are missing 50% of your
> notifications, not amount of gradual catchup is going to help you out.
But that's the only thing this patch is after: lost ticks at QEMU level.
Most lost ticks will happen at the vcpu
On 02/07/2011 03:41 PM, Gleb Natapov wrote:
On Mon, Feb 07, 2011 at 07:23:22AM -0600, Anthony Liguori wrote:
> On 02/07/2011 07:14 AM, Avi Kivity wrote:
> >On 02/07/2011 03:11 PM, Anthony Liguori wrote:
> >>On 02/07/2011 06:34 AM, Avi Kivity wrote:
> >>>On 02/04/2011 10:56 AM, Jan Kiszka wrot
Hi Ulrich,
Mike Roth just posted a mechanism to implement per-device unit tests. I
think this is a great example to use for what type of testing we should
be doing in QEMU.
Please take a look at Mike's series and see if you can do something
similar for HPET as he's doing for the RTC.
Rega
On Mon, Feb 07, 2011 at 07:23:22AM -0600, Anthony Liguori wrote:
> On 02/07/2011 07:14 AM, Avi Kivity wrote:
> >On 02/07/2011 03:11 PM, Anthony Liguori wrote:
> >>On 02/07/2011 06:34 AM, Avi Kivity wrote:
> >>>On 02/04/2011 10:56 AM, Jan Kiszka wrote:
> >
> > This should be a rare event.
On 02/07/2011 05:20 PM, Jan Kiszka wrote:
On 2011-02-07 16:13, Avi Kivity wrote:
>>
>> PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque);
>>
>
> void periodic_timer_init(PeriodicTimer *timer, PeriodicTimerFunc *cb);
>
> It is better to embed than to reference.
And embeddi
On Mon, Feb 07, 2011 at 03:51:27PM +0200, Avi Kivity wrote:
> On 02/07/2011 03:48 PM, Gleb Natapov wrote:
> >>
> >> That's quite pointless, since those interrupts will be coalesced by
> >> the guest.
> >>
> >Yes, of course, and this is what I remember happening. At this point
> >interrupt de-coal
On 02/07/2011 04:54 PM, Anthony Liguori wrote:
Why the accumulated_ticks argument?
Then the missing ticks is stored in the PeriodicTimer instead of
storing it in the device state. That means we won't forget to save it
in vmstate.
It's convenient because then if we lose ticks in the Per
On 2011-02-07 16:08, Avi Kivity wrote:
> On 02/07/2011 05:01 PM, Jan Kiszka wrote:
>>>
>>> On the other hand, we need a way to inject lost ticks into a
>>> PeriodicTimer. If interrupt injection detects that an interrupt was
>>> coalesced, we want the timer to schedule a new tick for us.
>>
>> I
On 02/07/2011 03:48 PM, Gleb Natapov wrote:
>
> That's quite pointless, since those interrupts will be coalesced by
> the guest.
>
Yes, of course, and this is what I remember happening. At this point
interrupt de-coalescing kicks in.
Maybe a more useful API would be to supply the callback wit
On 02/07/2011 05:01 PM, Anthony Liguori wrote:
typedef struct PeriodicTimer PeriodicTimer;
/**
* @accumulated_ticks: the number of unacknowledged ticks in total
since the creation of the timer
**/
Outdated comment even before the code is committed. Will be hard to beat.
typedef void (
On 02/07/2011 05:01 PM, Jan Kiszka wrote:
>
> On the other hand, we need a way to inject lost ticks into a
> PeriodicTimer. If interrupt injection detects that an interrupt was
> coalesced, we want the timer to schedule a new tick for us.
Isn't absence of corresponding call to periodic_timer
On 02/03/2011 9:07 PM, Anthony Liguori wrote:
> On 02/03/2011 09:28 AM, Jan Kiszka wrote:
>> On 2011-02-03 14:43, Ulrich Obergfell wrote:
...
>>> This is an RFC through which I would like to get feedback on how the
>>> idea of a patch to compensate those lost interrupts would be received:
>>>
>>>
On Mon, Feb 07, 2011 at 03:46:54PM +0200, Avi Kivity wrote:
> On 02/07/2011 03:41 PM, Gleb Natapov wrote:
> >On Mon, Feb 07, 2011 at 07:23:22AM -0600, Anthony Liguori wrote:
> >> On 02/07/2011 07:14 AM, Avi Kivity wrote:
> >> >On 02/07/2011 03:11 PM, Anthony Liguori wrote:
> >> >>On 02/07/2011 0
On 2011-02-07 15:58, Avi Kivity wrote:
> On 02/07/2011 04:54 PM, Anthony Liguori wrote:
>>
>>> Why the accumulated_ticks argument?
>>
>> Then the missing ticks is stored in the PeriodicTimer instead of
>> storing it in the device state. That means we won't forget to save it
>> in vmstate.
>>
>
On 02/07/2011 06:34 AM, Avi Kivity wrote:
On 02/04/2011 10:56 AM, Jan Kiszka wrote:
>
> This should be a rare event. If you are missing 50% of your
> notifications, not amount of gradual catchup is going to help you
out.
But that's the only thing this patch is after: lost ticks at QEMU lev
On 2011-02-07 15:28, Anthony Liguori wrote:
> On 02/07/2011 08:10 AM, Jan Kiszka wrote:
>> Again: please not in an ad-hoc fashion but as a generic services usable
>> by _all_ periodic timer sources that want to implement compensation.
>> This infrastructure should also be designed to once integrate
On 02/07/2011 08:43 AM, Jan Kiszka wrote:
On 2011-02-07 15:28, Anthony Liguori wrote:
On 02/07/2011 08:10 AM, Jan Kiszka wrote:
Again: please not in an ad-hoc fashion but as a generic services usable
by _all_ periodic timer sources that want to implement compensation.
This infrastruct
On 2011-02-07 16:01, Anthony Liguori wrote:
> On 02/07/2011 08:57 AM, Jan Kiszka wrote:
>> There should rather be a special vmstate struct for PeriodicTimer, just
>> like we already have for normal timers.
>>
>
> Agreed.
>
>>> It's convenient because then if we lose ticks in the PeriodicTimer
On 02/07/2011 05:17 PM, Jan Kiszka wrote:
On 2011-02-07 16:13, Avi Kivity wrote:
> On 02/07/2011 05:01 PM, Anthony Liguori wrote:
>>
>> typedef struct PeriodicTimer PeriodicTimer;
>>
>> /**
>> * @accumulated_ticks: the number of unacknowledged ticks in total
>> since the creation of the ti
On 02/07/2011 08:10 AM, Jan Kiszka wrote:
Again: please not in an ad-hoc fashion but as a generic services usable
by _all_ periodic timer sources that want to implement compensation.
This infrastructure should also be designed to once integrate IRQ
coalescing information as well.
The point why I
On 02/07/2011 09:20 AM, Jan Kiszka wrote:
On 2011-02-07 16:13, Avi Kivity wrote:
PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque);
void periodic_timer_init(PeriodicTimer *timer, PeriodicTimerFunc *cb);
It is better to embed than to reference.
And embed
On 02/07/2011 09:29 AM, Avi Kivity wrote:
On 02/07/2011 05:17 PM, Jan Kiszka wrote:
On 2011-02-07 16:13, Avi Kivity wrote:
> On 02/07/2011 05:01 PM, Anthony Liguori wrote:
>>
>> typedef struct PeriodicTimer PeriodicTimer;
>>
>> /**
>> * @accumulated_ticks: the number of unacknowledged tick
On 2011-02-07 14:23, Anthony Liguori wrote:
> On 02/07/2011 07:14 AM, Avi Kivity wrote:
>> On 02/07/2011 03:11 PM, Anthony Liguori wrote:
>>> On 02/07/2011 06:34 AM, Avi Kivity wrote:
On 02/04/2011 10:56 AM, Jan Kiszka wrote:
> >
> > This should be a rare event. If you are missing 50
On 2011-02-07 16:13, Avi Kivity wrote:
> On 02/07/2011 05:01 PM, Anthony Liguori wrote:
>>
>> typedef struct PeriodicTimer PeriodicTimer;
>>
>> /**
>> * @accumulated_ticks: the number of unacknowledged ticks in total
>> since the creation of the timer
>> **/
>
> Outdated comment even before th
On 2011-02-07 15:54, Anthony Liguori wrote:
> On 02/07/2011 08:43 AM, Jan Kiszka wrote:
>> On 2011-02-07 15:28, Anthony Liguori wrote:
>>
>>> On 02/07/2011 08:10 AM, Jan Kiszka wrote:
>>>
Again: please not in an ad-hoc fashion but as a generic services usable
by _all_ periodic t
On 02/07/2011 07:14 AM, Avi Kivity wrote:
On 02/07/2011 03:11 PM, Anthony Liguori wrote:
On 02/07/2011 06:34 AM, Avi Kivity wrote:
On 02/04/2011 10:56 AM, Jan Kiszka wrote:
>
> This should be a rare event. If you are missing 50% of your
> notifications, not amount of gradual catchup is goin
Anthony,
in reply to:
> My point is that there's really low hanging fruit and while for some
> curious reason I don't actually see this patch, I believe that a patch
> like this probably can help us quite a lot in the short term.
I've sent the patch in two separate emails:
- code part 1 (intro
On 2011-02-04 03:06, Anthony Liguori wrote:
> On 02/03/2011 03:24 PM, Jan Kiszka wrote:
>> On 2011-02-03 21:07, Anthony Liguori wrote:
>>
>>> On 02/03/2011 09:28 AM, Jan Kiszka wrote:
>>>
On 2011-02-03 14:43, Ulrich Obergfell wrote:
> Hi,
>
> I am observing
On 02/03/2011 03:24 PM, Jan Kiszka wrote:
On 2011-02-03 21:07, Anthony Liguori wrote:
On 02/03/2011 09:28 AM, Jan Kiszka wrote:
On 2011-02-03 14:43, Ulrich Obergfell wrote:
Hi,
I am observing severe backward time drift in a MS Windows Vista(tm)
guest running on a Fedora 14
On 2011-02-03 21:07, Anthony Liguori wrote:
> On 02/03/2011 09:28 AM, Jan Kiszka wrote:
>> On 2011-02-03 14:43, Ulrich Obergfell wrote:
>>
>>> Hi,
>>>
>>> I am observing severe backward time drift in a MS Windows Vista(tm)
>>> guest running on a Fedora 14 KVM host. I can reproduce the problem
>>
On 02/03/2011 09:28 AM, Jan Kiszka wrote:
On 2011-02-03 14:43, Ulrich Obergfell wrote:
Hi,
I am observing severe backward time drift in a MS Windows Vista(tm)
guest running on a Fedora 14 KVM host. I can reproduce the problem
with the following steps:
1. Use 'vncviewer' to connect to the g
On 2011-02-03 14:43, Ulrich Obergfell wrote:
>
> Hi,
>
> I am observing severe backward time drift in a MS Windows Vista(tm)
> guest running on a Fedora 14 KVM host. I can reproduce the problem
> with the following steps:
>
> 1. Use 'vncviewer' to connect to the guest's desktop.
> 2. Click on th
40 matches
Mail list logo
