On 08/08/2012 12:09 AM, Benjamin Herrenschmidt wrote:
On Tue, 2012-08-07 at 16:13 +0300, Avi Kivity wrote:
Peter has started to fix up this naming mess in qemu. I guess we should
do the same for the kernel (except for ABIs) and document it, because it
keeps generating confusion.
Ok so
On 08/08/2012 03:49 AM, David Gibson wrote:
We never have irqchip in kernel (because we haven't written that yet)
but we still sleep in-kernel for CEDE. I haven't spotted any problem
with that, but now I'm wondering if there is one, since x86 don't do
it in what seems like the analogous
On Wed, 2012-08-08 at 11:52 +0300, Avi Kivity wrote:
So for now I'm just doing my own version of CREATE_IRQCHIP to create it
and KVM_INTERRUPT to trigger the various interrupts. None of the mapping
stuff (which we really don't need).
You mean KVM_IRQ_LINE. KVM_INTERRUPT is a synchronous
On Wed, Aug 08, 2012 at 11:58:58AM +0300, Avi Kivity wrote:
On 08/08/2012 03:49 AM, David Gibson wrote:
We never have irqchip in kernel (because we haven't written that yet)
but we still sleep in-kernel for CEDE. I haven't spotted any problem
with that, but now I'm wondering if there is
On 08/08/2012 02:59 PM, David Gibson wrote:
No, you're correct. HLT could have been emulated in userspace, it just
wasn't. The correct statement is that HLT was arbitrarily chosen to be
emulated in userspace with the synchronous model, but the asynchronous
model forced it into the kernel.
On 08/08/2012 12:09 AM, Benjamin Herrenschmidt wrote:
On Tue, 2012-08-07 at 16:13 +0300, Avi Kivity wrote:
Peter has started to fix up this naming mess in qemu. I guess we should
do the same for the kernel (except for ABIs) and document it, because it
keeps generating confusion.
Ok so
On 08/08/2012 03:49 AM, David Gibson wrote:
We never have irqchip in kernel (because we haven't written that yet)
but we still sleep in-kernel for CEDE. I haven't spotted any problem
with that, but now I'm wondering if there is one, since x86 don't do
it in what seems like the analogous
On Wed, 2012-08-08 at 11:52 +0300, Avi Kivity wrote:
So for now I'm just doing my own version of CREATE_IRQCHIP to create it
and KVM_INTERRUPT to trigger the various interrupts. None of the mapping
stuff (which we really don't need).
You mean KVM_IRQ_LINE. KVM_INTERRUPT is a synchronous
On Wed, Aug 08, 2012 at 11:58:58AM +0300, Avi Kivity wrote:
On 08/08/2012 03:49 AM, David Gibson wrote:
We never have irqchip in kernel (because we haven't written that yet)
but we still sleep in-kernel for CEDE. I haven't spotted any problem
with that, but now I'm wondering if there is
On 08/08/2012 02:59 PM, David Gibson wrote:
No, you're correct. HLT could have been emulated in userspace, it just
wasn't. The correct statement is that HLT was arbitrarily chosen to be
emulated in userspace with the synchronous model, but the asynchronous
model forced it into the kernel.
On Tue, Aug 07, 2012 at 11:46:35AM +0300, Avi Kivity wrote:
On 08/07/2012 04:32 AM, David Gibson wrote:
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still trying to nut out the implications for
On 08/07/2012 03:14 PM, David Gibson wrote:
On Tue, Aug 07, 2012 at 11:46:35AM +0300, Avi Kivity wrote:
On 08/07/2012 04:32 AM, David Gibson wrote:
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still
On Tue, 2012-08-07 at 16:13 +0300, Avi Kivity wrote:
Peter has started to fix up this naming mess in qemu. I guess we should
do the same for the kernel (except for ABIs) and document it, because it
keeps generating confusion.
Ok so our current situation is that the XICS and MPIC are
On Tue, Aug 07, 2012 at 04:13:49PM +0300, Avi Kivity wrote:
On 08/07/2012 03:14 PM, David Gibson wrote:
On Tue, Aug 07, 2012 at 11:46:35AM +0300, Avi Kivity wrote:
On 08/07/2012 04:32 AM, David Gibson wrote:
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon,
On 08/06/2012 11:25 PM, Scott Wood wrote:
On 08/05/2012 04:00 AM, Avi Kivity wrote:
On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c.
On 08/07/2012 04:32 AM, David Gibson wrote:
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still trying to nut out the implications for H_CEDE, and think
if there are any other hypercalls that might want
On 08/06/2012 11:25 PM, Scott Wood wrote:
On 08/05/2012 04:00 AM, Avi Kivity wrote:
On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c.
On 08/07/2012 04:32 AM, David Gibson wrote:
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still trying to nut out the implications for H_CEDE, and think
if there are any other hypercalls that might want
On Tue, Aug 07, 2012 at 11:46:35AM +0300, Avi Kivity wrote:
On 08/07/2012 04:32 AM, David Gibson wrote:
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still trying to nut out the implications for
On 08/07/2012 03:14 PM, David Gibson wrote:
On Tue, Aug 07, 2012 at 11:46:35AM +0300, Avi Kivity wrote:
On 08/07/2012 04:32 AM, David Gibson wrote:
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still
On Tue, 2012-08-07 at 16:13 +0300, Avi Kivity wrote:
Peter has started to fix up this naming mess in qemu. I guess we should
do the same for the kernel (except for ABIs) and document it, because it
keeps generating confusion.
Ok so our current situation is that the XICS and MPIC are
On Tue, Aug 07, 2012 at 04:13:49PM +0300, Avi Kivity wrote:
On 08/07/2012 03:14 PM, David Gibson wrote:
On Tue, Aug 07, 2012 at 11:46:35AM +0300, Avi Kivity wrote:
On 08/07/2012 04:32 AM, David Gibson wrote:
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon,
On 08/05/2012 04:00 AM, Avi Kivity wrote:
On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c.
The whole thing is fragile, though: we rely
On Sun, 2012-08-05 at 12:00 +0300, Avi Kivity wrote:
So we'll need to test but it looks like we might be able to fix our
problem without a kernel or API change, just by changing qemu to
do the same exit_request trick for our reboot hypercall.
Long run however, I wonder whether we should
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still trying to nut out the implications for H_CEDE, and think
if there are any other hypercalls that might want to block the guest
for a time. We were considering blocking H_PUT_TCE if qemu devices
had active dma maps on the
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still trying to nut out the implications for H_CEDE, and think
if there are any other hypercalls that might want to block the guest
for a time. We were
On 08/05/2012 04:00 AM, Avi Kivity wrote:
On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c.
The whole thing is fragile, though: we rely
On Sun, 2012-08-05 at 12:00 +0300, Avi Kivity wrote:
So we'll need to test but it looks like we might be able to fix our
problem without a kernel or API change, just by changing qemu to
do the same exit_request trick for our reboot hypercall.
Long run however, I wonder whether we should
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still trying to nut out the implications for H_CEDE, and think
if there are any other hypercalls that might want to block the guest
for a time. We were considering blocking H_PUT_TCE if qemu devices
had active dma maps on the
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still trying to nut out the implications for H_CEDE, and think
if there are any other hypercalls that might want to block the guest
for a time. We were
On 08/02/2012 11:29 PM, Benjamin Herrenschmidt wrote:
On Thu, 2012-08-02 at 16:05 +0300, Avi Kivity wrote:
Yeah, we stumbled over this chunk as well. So you're saying we
should delay the reset by invoking a self-signal if we're in such an
operation?
Yes. Qemu of course already supports
On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c.
The whole thing is fragile, though: we rely on the order events
are processed
On Sun, 2012-08-05 at 11:55 +0300, Avi Kivity wrote:
I'm afraid I no longer know the details so closely, the code has
changed
quite a lot. But the self-signal happens in kvm_cpu_exec(), see also
env-exit_request.
Right, I think I eventually grasped it :-) It is fairly fragile however,
it
On Sat, Aug 04, 2012 at 08:30:08AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2012-08-03 at 14:41 -0300, Marcelo Tosatti wrote:
Hrm, except that doing KVM_RUN with a signal is very cumbersome to do
and I couldn't quite find the logic in qemu to do it ... but I might
just have missed
On 08/02/2012 11:29 PM, Benjamin Herrenschmidt wrote:
On Thu, 2012-08-02 at 16:05 +0300, Avi Kivity wrote:
Yeah, we stumbled over this chunk as well. So you're saying we
should delay the reset by invoking a self-signal if we're in such an
operation?
Yes. Qemu of course already supports
On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c.
The whole thing is fragile, though: we rely on the order events
are processed
On Sun, 2012-08-05 at 11:55 +0300, Avi Kivity wrote:
I'm afraid I no longer know the details so closely, the code has
changed
quite a lot. But the self-signal happens in kvm_cpu_exec(), see also
env-exit_request.
Right, I think I eventually grasped it :-) It is fairly fragile however,
it
On Fri, Aug 03, 2012 at 02:41:13PM -0300, Marcelo Tosatti wrote:
On Fri, Aug 03, 2012 at 06:20:18AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2012-08-02 at 15:35 +0300, Avi Kivity wrote:
This is actually documented in api.txt, though not in relation to
reset:
NOTE: For
On Fri, 2012-08-03 at 14:41 -0300, Marcelo Tosatti wrote:
Hrm, except that doing KVM_RUN with a signal is very cumbersome to do
and I couldn't quite find the logic in qemu to do it ... but I might
just have missed it. I can see indeed that in the migration case you
want to actually
On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c.
The whole thing is fragile, though: we rely on the order events
are processed inside KVM_RUN, in x86:
1) If there is pending MMIO,
On Fri, Aug 03, 2012 at 06:20:18AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2012-08-02 at 15:35 +0300, Avi Kivity wrote:
This is actually documented in api.txt, though not in relation to
reset:
NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI, the
corresponding operations
On Fri, Aug 03, 2012 at 02:41:13PM -0300, Marcelo Tosatti wrote:
On Fri, Aug 03, 2012 at 06:20:18AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2012-08-02 at 15:35 +0300, Avi Kivity wrote:
This is actually documented in api.txt, though not in relation to
reset:
NOTE: For
On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c.
The whole thing is fragile, though: we rely on the order events
are processed inside KVM_RUN, in x86:
1) If there is pending MMIO,
Avi, Marcelo, Jan? Any thoughts on this?
Alex
On 01.08.2012, at 05:17, Benjamin Herrenschmidt wrote:
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to make sure
we are on the right track first
On Thu, 2012-08-02 at 12:46 +0200, Alexander Graf wrote:
Avi, Marcelo, Jan? Any thoughts on this?
Had a chat with Anthony and it looks like we can do it using the MP
state stuff which we don't currently use on powerpc, at least it seems
that's how x86 breaks IO emulation on reset.
Cheers,
Ben.
On 08/01/2012 06:17 AM, Benjamin Herrenschmidt wrote:
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to make sure
we are on the right track first before proposing an actual patch as we
would like
On 02.08.2012, at 14:35, Avi Kivity wrote:
On 08/01/2012 06:17 AM, Benjamin Herrenschmidt wrote:
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to make sure
we are on the right track first before
On 08/02/2012 03:59 PM, Alexander Graf wrote:
On 02.08.2012, at 14:35, Avi Kivity wrote:
On 08/01/2012 06:17 AM, Benjamin Herrenschmidt wrote:
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to
On Thu, 2012-08-02 at 15:35 +0300, Avi Kivity wrote:
This is actually documented in api.txt, though not in relation to
reset:
NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI, the
corresponding operations are complete (and guest state is
consistent)
only after userspace has
On Thu, 2012-08-02 at 16:05 +0300, Avi Kivity wrote:
Yeah, we stumbled over this chunk as well. So you're saying we
should delay the reset by invoking a self-signal if we're in such an
operation?
Yes. Qemu of course already supports this for migration, so it should
be easy to add.
Adding
Avi, Marcelo, Jan? Any thoughts on this?
Alex
On 01.08.2012, at 05:17, Benjamin Herrenschmidt wrote:
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to make sure
we are on the right track first
On Thu, 2012-08-02 at 12:46 +0200, Alexander Graf wrote:
Avi, Marcelo, Jan? Any thoughts on this?
Had a chat with Anthony and it looks like we can do it using the MP
state stuff which we don't currently use on powerpc, at least it seems
that's how x86 breaks IO emulation on reset.
Cheers,
Ben.
On 08/01/2012 06:17 AM, Benjamin Herrenschmidt wrote:
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to make sure
we are on the right track first before proposing an actual patch as we
would like
On 02.08.2012, at 14:35, Avi Kivity wrote:
On 08/01/2012 06:17 AM, Benjamin Herrenschmidt wrote:
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to make sure
we are on the right track first before
On 08/02/2012 03:59 PM, Alexander Graf wrote:
On 02.08.2012, at 14:35, Avi Kivity wrote:
On 08/01/2012 06:17 AM, Benjamin Herrenschmidt wrote:
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to
On Thu, 2012-08-02 at 15:35 +0300, Avi Kivity wrote:
This is actually documented in api.txt, though not in relation to
reset:
NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI, the
corresponding operations are complete (and guest state is
consistent)
only after userspace has
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to make sure
we are on the right track first before proposing an actual patch as we
would like the patch to go in ASAP (ie not waiting the next merge
window)
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to make sure
we are on the right track first before proposing an actual patch as we
would like the patch to go in ASAP (ie not waiting the next merge
window)
58 matches
Mail list logo
