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 thus the -stable
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
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
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 updated whenever state is
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
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 need to overwrite
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
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 API comes with
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
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 of this race.
On 11/17/2009 04:12 PM, Jan Kiszka wrote:
The alternative would be a complex getlock/putunlock + 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 communicate the
Avi Kivity wrote:
On 11/17/2009 04:12 PM, Jan Kiszka wrote:
The alternative would be a complex getlock/putunlock + 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
Jan Kiszka wrote:
Avi Kivity wrote:
On 11/17/2009 04:12 PM, Jan Kiszka wrote:
The alternative would be a complex getlock/putunlock + 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
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
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
Am 16.11.2009 um 18:00 schrieb Jan Kiszka jan.kis...@siemens.com:
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
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
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
(which
18 matches
Mail list logo
