On 11/17/2009 06:58 PM, Jan Kiszka wrote:
That wouldn't be required anymore with the "always queue" policy.
Hmm, unless we need mp_state manipulation analogously to KVM_NMI vs.
KVM_SET_VCPU_STATE: The former will queue, the latter write, but may be
overwritten by anything queued. If you
On 11/18/2009 11:50 AM, Jan Kiszka wrote:
INIT, too.
INIT should be handled by queuing up the next mp_state.
And clearing the previous queue; otherwise our queue is unbounded.
BTW, as we do not inject mp_state changes from user space during
runtime, the issue I saw with the curre
Avi Kivity wrote:
> On 11/17/2009 06:50 PM, Jan Kiszka wrote:
>>
>>> I think we're not on the same page here. As I see it, no interface
>>> change is needed at all.
>>>
>>> It's true that existing kernels don't handle this properly, which is why
>>> I said I'm willing to treat it as a bug (and thu
On 11/17/2009 06:50 PM, Jan Kiszka wrote:
I think we're not on the same page here. As I see it, no interface
change is needed at all.
It's true that existing kernels don't handle this properly, which is why
I said I'm willing to treat it as a bug (and thus the -stable treatment
etc.). I admi
Jan Kiszka wrote:
> Avi Kivity wrote:
>> On 11/17/2009 04:12 PM, Jan Kiszka wrote:
> The alternative would be a complex get&lock/put&unlock + a queue for
> async events during the lock + an option to ignore what was queued when
> doing a true reset. Back to square #1: we would still nee
Avi Kivity wrote:
> On 11/17/2009 04:12 PM, Jan Kiszka wrote:
The alternative would be a complex get&lock/put&unlock + a queue for
async events during the lock + an option to ignore what was queued when
doing a true reset. Back to square #1: we would still need the proposed
high
On 11/17/2009 04:12 PM, Jan Kiszka wrote:
>>
>>> The alternative would be a complex get&lock/put&unlock + a queue for
>>> async events during the lock + an option to ignore what was queued when
>>> doing a true reset. Back to square #1: we would still need the proposed
>>> high-level interface to c
Avi Kivity wrote:
> On 11/17/2009 03:05 PM, Jan Kiszka wrote:
>>
>>> Problem is, the inject channels are implied (APIC messages in smp
>>> guests). Documentation is good, but if we can avoid it that's better.
>>>
>>> Note the only way to rmw vcpu events during smp is pausing the guest,
>>> because
On 11/17/2009 03:05 PM, Jan Kiszka wrote:
Problem is, the inject channels are implied (APIC messages in smp
guests). Documentation is good, but if we can avoid it that's better.
Note the only way to rmw vcpu events during smp is pausing the guest,
because of this race.
That's what qemu
Avi Kivity wrote:
> On 11/17/2009 11:16 AM, Jan Kiszka wrote:
>>
>>> That's because qemu has no need for this. But kvm is more than just
>>> serving qemu, we try to be more general. That said, I can't really see
>>> anyone wanting to arbitrarily inject an exception.
>>>
>> Well, the current
On 11/17/2009 11:16 AM, Jan Kiszka wrote:
That's because qemu has no need for this. But kvm is more than just
serving qemu, we try to be more general. That said, I can't really see
anyone wanting to arbitrarily inject an exception.
Well, the current API comes with millions of ways to s
Avi Kivity wrote:
> On 11/17/2009 10:14 AM, Jan Kiszka wrote:
>>
>>
>>> state that is updated outside the vcpu thread. These are particularly
>>> bad since we can't exclude them from updates without excluding other
>>> state as well.
>>>
>> We easily can, using the very same mechanism: No ne
On 11/17/2009 10:14 AM, Jan Kiszka wrote:
state that is updated outside the vcpu thread. These are particularly
bad since we can't exclude them from updates without excluding other
state as well.
We easily can, using the very same mechanism: No need to overwrite any
of the kvm_vcpu_eve
Avi Kivity wrote:
> On 11/16/2009 11:22 PM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>
>>> On 11/16/2009 07:00 PM, Jan Kiszka wrote:
>>>
This patch aims at addressing the mp_state writeback issue in a cleaner
fashion.
>>> What's the issue? the fact that mp_state is up
On 11/16/2009 11:22 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 11/16/2009 07:00 PM, Jan Kiszka wrote:
This patch aims at addressing the mp_state writeback issue in a cleaner
fashion.
What's the issue? the fact that mp_state is updated whenever state is
synchronized, while it
Avi Kivity wrote:
> On 11/16/2009 07:00 PM, Jan Kiszka wrote:
>> This patch aims at addressing the mp_state writeback issue in a cleaner
>> fashion.
>
> What's the issue? the fact that mp_state is updated whenever state is
> synchronized, while it could be simultaneously updated from other vcpus
On 11/16/2009 07:00 PM, Jan Kiszka wrote:
This patch aims at addressing the mp_state writeback issue in a cleaner
fashion.
What's the issue? the fact that mp_state is updated whenever state is
synchronized, while it could be simultaneously updated from other vcpus
(which latter updates are t
Am 16.11.2009 um 18:00 schrieb Jan Kiszka :
This patch aims at addressing the mp_state writeback issue in a
cleaner
fashion. By introducing additional information about the scope of the
scheduled vcpu state writeback, we can simply skin mp_state (and maybe
other specific states in the future)
This patch aims at addressing the mp_state writeback issue in a cleaner
fashion. By introducing additional information about the scope of the
scheduled vcpu state writeback, we can simply skin mp_state (and maybe
other specific states in the future) when updating the in-kernel state.
The writeback
19 matches
Mail list logo