. The
local_irq_enable() call takes care of replaying them and lets the interrupts
hard enabled.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
Ben, could you please review?
That does look like the right thing to do indeed.
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
On Wed, 2013-03-20 at 12:48 -0600, Alex Williamson wrote:
Perhaps my problem is that I don't have a clear picture of where
you're
going with this like I do for AER. For AER we're starting with
notification of an error, from that we build into how to retrieve the
error information, and
On Mon, 2013-03-18 at 22:18 -0600, Alex Williamson wrote:
Yes, EEH firmware call needn't going through VFIO. However, EEH has
very close relationship with PCI and so VFIO-PCI does. Eventually, EEH
has close relationship with VFIO-PCI :-)
Is there some plan to do more with EEH through VFIO
On Fri, 2013-03-15 at 13:41 -0600, Alex Williamson wrote:
This basically gives userspace free access to any regions that aren't
covered by known capabilities.
And ?
I mean seriously :-) We already had that discussion ... trying to
protect config space is just plain doomed. There is no
On Sat, 2013-03-16 at 09:34 +0800, Gavin Shan wrote:
Could you explain further how this will be used? How the device is
exposed to a guest is entirely a userspace construct, so why does vfio
need to know or care about this? I had assumed for AER that QEMU would
do the translation from host
On Mon, 2013-03-04 at 23:20 +0100, Alexander Graf wrote:
7) Interrupt line connections to vcpus are implicit
We don't explicitly mark which in-kernel irqchip interrupt line goes
to which vcpu. This is done implicitly. If we see a need for it, we
create a new irqchip device type that allows
On Wed, 2013-02-13 at 23:49 -0600, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need to access device state,
it is done through inflexible
On Tue, 2013-03-05 at 21:36 -0600, Scott Wood wrote:
Which file is this in?
A few hits:
$ grep anon arch/powerpc/kvm/*
arch/powerpc/kvm/book3s_64_mmu_hv.c:#include linux/anon_inodes.h
arch/powerpc/kvm/book3s_64_mmu_hv.c:ret = anon_inode_getfd(kvm-htab,
kvm_htab_fops, ctx, rwflag);
On Mon, 2013-03-04 at 23:20 +0100, Alexander Graf wrote:
7) Interrupt line connections to vcpus are implicit
We don't explicitly mark which in-kernel irqchip interrupt line goes
to which vcpu. This is done implicitly. If we see a need for it, we
create a new irqchip device type that allows
On Tue, 2013-03-05 at 21:36 -0600, Scott Wood wrote:
Which file is this in?
A few hits:
$ grep anon arch/powerpc/kvm/*
arch/powerpc/kvm/book3s_64_mmu_hv.c:#include linux/anon_inodes.h
arch/powerpc/kvm/book3s_64_mmu_hv.c:ret = anon_inode_getfd(kvm-htab,
kvm_htab_fops, ctx, rwflag);
On Thu, 2013-01-31 at 12:49 +0200, Michael S. Tsirkin wrote:
OK but this appears behind a bridge. So the bridge configuration tells
the root complex where to send accesses to the VGA.
Sort-of, again the root complex isn't sending anything targeted here.
PCIe is point to point and any device
On Thu, 2013-01-31 at 09:34 -0700, Alex Williamson wrote:
Luckily guests do not seem to be worried as long as we use ACPI.
Yes, in fact I just figured out last night that Windows is unhappy with
assigned PCI devices on bus 0 that claim to be an endpoint in their PCIe
capability rather than
On Wed, 2013-01-30 at 07:59 -0600, Anthony Liguori wrote:
An x86 CPU has a MMIO capability that's essentially 65 bits. Whether
the top bit is set determines whether it's a PIO transaction or an
MMIO transaction. A large chunk of that address space is invalid of
course.
PCI has a 65 bit
On Wed, 2013-01-30 at 17:54 +0100, Andreas Färber wrote:
That would require polymorphism since we already need to derive from
PCIDevice or ISADevice respectively for interfacing with the bus...
Modern object-oriented languages have tried to avoid multi-inheritence
due to arising
On Wed, 2013-01-30 at 18:08 +0100, Paolo Bonzini wrote:
Make VGACommonState a proper QOM object and use it as the base class
for
QXL, CirrusVGA, QEMUVGA (std-vga), and VMwareVGA.
I think QXL should have-a VGA rather than being one. It completely
bypasses the VGA infrastructure if not in
On Wed, 2013-01-30 at 15:39 -0600, Anthony Liguori wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org writes:
There also exists P2P bridges doing such substractive
decoding, this used to be fairly common with transparent bridges used for
laptop docking.
I'm not sure I understand how
On Thu, 2013-01-31 at 00:20 +0200, Michael S. Tsirkin wrote:
Well you can have a PCI bridge and a legacy device behind that.
I think real PCI express devices can not be mapped onto legacy address
ranges.
In practice they do (VGA at least)
From a SW modelling standpoint, I don't think it's
On Thu, 2013-01-31 at 00:49 +0200, Michael S. Tsirkin wrote:
In practice they do (VGA at least)
From a SW modelling standpoint, I don't think it's worth
differentiating
PCI and PCIE.
Cheers,
Ben.
Interesting.
Do you have such hardware? Could you please dump
the output of
On Sat, 2012-12-15 at 01:46 +0100, Alexander Graf wrote:
On 05.11.2012, at 04:18, Paul Mackerras wrote:
This series implements in-kernel emulation of the XICS interrupt
controller specified in the PAPR specification and used by pseries
guests. Since the XICS is organized a bit
On Sat, 2012-12-15 at 01:46 +0100, Alexander Graf wrote:
On 05.11.2012, at 04:18, Paul Mackerras wrote:
This series implements in-kernel emulation of the XICS interrupt
controller specified in the PAPR specification and used by pseries
guests. Since the XICS is organized a bit
On Wed, 2012-12-12 at 07:34 -0700, Alex Williamson wrote:
But what would I put there?... IOMMU ID is more than enough at the moment
and struct iommu_table does not have anything what would have made sense to
show in the sysfs...
I believe David mentioned that PEs had user visible names.
On Wed, 2012-12-12 at 16:30 -0700, Alex Williamson wrote:
Locked page accounting in this version is very, very broken. How do
powerpc folks feel about seemingly generic kernel iommu interfaces
messing with the current task mm? Besides that, more problems below...
Not good at all :-)
I
On Wed, 2012-12-12 at 16:30 -0700, Alex Williamson wrote:
Locked page accounting in this version is very, very broken. How do
powerpc folks feel about seemingly generic kernel iommu interfaces
messing with the current task mm? Besides that, more problems
below...
After a second look
On Mon, 2012-11-26 at 11:04 -0700, Alex Williamson wrote:
Ok, I see tces are put on shutdown via tce_iommu_detach_group, so you're
more concerned about the guest simply mapping over top of it's own
mappings. Is that common? Is it common enough for every multi-page
mapping to assume it will
On Thu, 2012-11-22 at 11:25 +0100, Paolo Bonzini wrote:
Again, from memory, you were volunteered to do the initial x86
change so
we could piggy back on it :-) Or do I remember wrong ?
Please suggest an API, then we can work out the x86 changes. I can
volunteer myself, but I wasn't in the
Hi Jan !
David (CC) want to make some progress with our in-kernel PIC. From
memory, one of the outcomes of the BOF was that we need to move the
existing enable in-kernel PIC from generic KVM init to machine init in
order to be able to add an argument indicating the model use by the
arch/platform
On Fri, 2012-11-09 at 14:45 +0100, Peter Maydell wrote:
On 22 October 2012 08:51, Christoffer Dall
c.d...@virtualopensystems.com wrote:
+struct kvm_device_address {
+ __u32 id;
+ __u64 addr;
+};
Ben suggested that this should either be a 64 bit id or have explicit
On Sat, 2012-10-27 at 11:01 +0100, Peter Maydell wrote:
This is more or less how ARM has done it (though our specific encoding
of interrupt numbers is different, obviously).
If I were designing an interface for this kind of thing from scratch
I'd probably want it to look like create a
On Sat, 2012-10-27 at 11:01 +0100, Peter Maydell wrote:
This is more or less how ARM has done it (though our specific encoding
of interrupt numbers is different, obviously).
If I were designing an interface for this kind of thing from scratch
I'd probably want it to look like create a
On Fri, 2012-10-26 at 11:58 +0200, Paolo Bonzini wrote:
Il 25/10/2012 21:40, Benjamin Herrenschmidt ha scritto:
Probably you do need a variant of KVM_CREATE_IRQCHIP to create the
IOAPICs/source controllers (Paul's proposal at
http://permalink.gmane.org
On Fri, 2012-10-26 at 12:15 +0200, Paolo Bonzini wrote:
Whether you want to do startup configuration and board wiring via
the same ioctl that handles runtime state save/load/migration is
a different question, of course.
QEMU's MSI-X routing is not x86-specific, so it should use the same
On Fri, 2012-10-26 at 13:00 +0200, Jan Kiszka wrote:
And at latest there you will need the IRQ routing infrastructure of KVM.
It tells KVM which virtual IRQ (badly named GSI) triggers which
event at which input, e.g. a physical IRQ line at some IRQ controller or
a specific message at some MSI
On Fri, 2012-10-26 at 12:40 +0200, Paolo Bonzini wrote:
Il 26/10/2012 12:37, Benjamin Herrenschmidt ha scritto:
Wiring which MSI-X interrupts go to which source controllers. If you
have one source controller per PCI bridge, you need to tell the kernel
the mapping between MSI messages
On Fri, 2012-10-26 at 12:17 +0100, Peter Maydell wrote:
Well, that's the thing, I haven't managed to figure that out so far,
it
looks very x86-specific to me. To begin with there's no such thing
as a
GSI in our world.
This was roughly the feeling I had looking at these APIs. There
On Fri, 2012-10-26 at 13:57 +0200, Paolo Bonzini wrote:
Il 26/10/2012 13:09, Benjamin Herrenschmidt ha scritto:
The only cases I can think of are the association between a virtual
interrupt (ie, an interrupt in the guest interrupt number space) and an
in-kernel source for that interrupt, ie
On Sat, 2012-10-27 at 07:45 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2012-10-26 at 14:39 +0200, Jan Kiszka wrote:
But we are just talking about sending messages from A to B or soldering
an input to an output pin. That's pretty generic. Give each output event
a virtual IRQ number
On Fri, 2012-10-26 at 11:58 +0200, Paolo Bonzini wrote:
Il 25/10/2012 21:40, Benjamin Herrenschmidt ha scritto:
Probably you do need a variant of KVM_CREATE_IRQCHIP to create the
IOAPICs/source controllers (Paul's proposal at
http://permalink.gmane.org
On Fri, 2012-10-26 at 12:15 +0200, Paolo Bonzini wrote:
Whether you want to do startup configuration and board wiring via
the same ioctl that handles runtime state save/load/migration is
a different question, of course.
QEMU's MSI-X routing is not x86-specific, so it should use the same
On Fri, 2012-10-26 at 13:00 +0200, Jan Kiszka wrote:
And at latest there you will need the IRQ routing infrastructure of KVM.
It tells KVM which virtual IRQ (badly named GSI) triggers which
event at which input, e.g. a physical IRQ line at some IRQ controller or
a specific message at some MSI
On Fri, 2012-10-26 at 12:17 +0100, Peter Maydell wrote:
Well, that's the thing, I haven't managed to figure that out so far,
it
looks very x86-specific to me. To begin with there's no such thing
as a
GSI in our world.
This was roughly the feeling I had looking at these APIs. There
On Fri, 2012-10-26 at 14:39 +0200, Jan Kiszka wrote:
But we are just talking about sending messages from A to B or soldering
an input to an output pin. That's pretty generic. Give each output event
a virtual IRQ number and define where its output line should be linked
to (input pin of target
On Sat, 2012-10-27 at 07:45 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2012-10-26 at 14:39 +0200, Jan Kiszka wrote:
But we are just talking about sending messages from A to B or soldering
an input to an output pin. That's pretty generic. Give each output event
a virtual IRQ number
On Thu, 2012-10-25 at 18:14 +0200, Paolo Bonzini wrote:
As Jan said, there's more than a few similarities between the x86 and
PPC model.
Taking inspiration from the x86 API, configuring the source controller
seems to be more of a task for KVM_SET_GSI_ROUTING (a very x86-centric
name, I must
On Thu, 2012-10-25 at 20:27 +0200, Paolo Bonzini wrote:
Probably you do need a variant of KVM_CREATE_IRQCHIP to create the
IOAPICs/source controllers (Paul's proposal at
http://permalink.gmane.org/gmane.comp.emulators.kvm.powerpc.devel/5674
for example), assign chip ids to them, set the number
On Thu, 2012-10-25 at 20:27 +0200, Paolo Bonzini wrote:
Probably you do need a variant of KVM_CREATE_IRQCHIP to create the
IOAPICs/source controllers (Paul's proposal at
http://permalink.gmane.org/gmane.comp.emulators.kvm.powerpc.devel/5674
for example), assign chip ids to them, set the number
On Wed, 2012-10-17 at 16:39 -0400, Christoffer Dall wrote:
Have you talked to Ben about this one? He wanted to design a new, more
flexible irqchip API that would work for XICS MPIC. Maybe there's some
room for cooperation here?
I have not - Ben, what do you have in mind?
I've been
On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
With the XICS, there are two types of irqchip: a source controller and
a presentation controller. There is one presentation controller per
vcpu and typically one source controller per PCI host bridge (a source
controller can manage
On Wed, 2012-10-17 at 16:39 -0400, Christoffer Dall wrote:
Have you talked to Ben about this one? He wanted to design a new, more
flexible irqchip API that would work for XICS MPIC. Maybe there's some
room for cooperation here?
I have not - Ben, what do you have in mind?
I've been
On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
With the XICS, there are two types of irqchip: a source controller and
a presentation controller. There is one presentation controller per
vcpu and typically one source controller per PCI host bridge (a source
controller can manage
On Tue, 2012-10-16 at 17:00 +1100, Michael Ellerman wrote:
Thanks for looking at this - but in fact this is fixed by my patch
entitled KVM: PPC: Book3S HV: Fix some races in starting secondary
threads submitted back on August 28.
OK thanks. It seems that patch didn't make 3.7 ?
I don't
now be
sure that they will not come online while the guest is running.
Signed-off-by: Paul Mackerras pau...@samba.org
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/smp.h |8 +++
arch/powerpc/kernel/smp.c | 46
now be
sure that they will not come online while the guest is running.
Signed-off-by: Paul Mackerras pau...@samba.org
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/smp.h |8 +++
arch/powerpc/kernel/smp.c | 46
interesting approach doing a virtio-vga,
which Anthony and I have been hacking on a bit, but due to time
constraints haven't really finished at this point.
In any case, I'm fine with this patch but does it help anybody ?
Cheers,
Ben.
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off
On Fri, 2012-09-14 at 03:44 +0200, Alexander Graf wrote:
We're slowly moving towards ONE_REG. ARM is already going full steam
ahead and I'd like to have every new register in PPC be modeled with
it as well. The old interface broke on us one time too often now :).
As I said, if we run into
On Thu, 2012-09-06 at 11:56 +0930, Rusty Russell wrote:
Excellent. I have applied and pushed this revision.
I was tempted to ask for an explicit endian marker, as switching to
explicit little endian was high on the TODO list for virtio2. On the
other hand, we could say virtio2-pci config
On Mon, 2012-08-06 at 16:27 +0300, Mihai Caraman wrote:
Critical exception handler on 64-bit booke uses user-visible SPRG3 as scratch.
Restore VDSO information in SPRG3 on exception prolog.
Breaks the build on !BOOKE because of :
diff --git a/arch/powerpc/kernel/vdso.c
On Mon, 2012-08-06 at 16:27 +0300, Mihai Caraman wrote:
Critical exception handler on 64-bit booke uses user-visible SPRG3 as scratch.
Restore VDSO information in SPRG3 on exception prolog.
Breaks the build on !BOOKE because of :
diff --git a/arch/powerpc/kernel/vdso.c
On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
The guest should not expect memory accesses to an address
to behave sanely while changing a BAR anyway.
Yes, compatibility for change of GPA base can be done in the
kernel. I can look into it next week if nobody has done so at
that
-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
This is a bug fix and thus should probably be merged ASAP
arch/powerpc/kvm/book3s_pr.c |3 ++-
arch/powerpc/kvm/booke.c |2 ++
arch/powerpc/kvm/powerpc.c |2 --
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git
by KVM for guest threads to poke each other,
in order to target the guest threads precisely when possible
and avoid that global switch of the core to host state.
Then use this new facility in the in-kernel XICS code
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc
This adds an implementation of the XICS hypercalls in real
mode for HV KVM which allows us to avoid exiting the guest
MMU context on all threads for a variety of operations such
as fetching a pending interrupt, EOI of messages, IPIs, ...
Signed-off-by: Benjamin Herrenschmidt b
For pseries machine emulation, in order to move the interrupt
controller code to the kernel, we need to intercept some RTAS
calls in the kernel itself
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include
.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/kvm.h | 39 ++
arch/powerpc/include/asm/kvm_host.h |8 +
arch/powerpc/include/asm/kvm_ppc.h | 30 +-
arch/powerpc/kvm/Makefile |1 +
arch/powerpc/kvm/book3s.c |3
When making a vcpu non-runnable we incorrectly changed the
thread IDs of all other threads on the core, just remove that
code.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
This is a bug fix and thus should probably be merged ASAP
arch/powerpc/kvm/book3s_hv.c |6
significantly on HV KVM.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/kvm_book3s.h |1 +
arch/powerpc/kvm/book3s.c |2 +-
arch/powerpc/kvm/book3s_xics.c| 781 +
3 files changed, 501
On Fri, 2012-08-17 at 15:39 -0300, Marcelo Tosatti wrote:
On Fri, Aug 17, 2012 at 05:06:18PM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
The guest should not expect memory accesses to an address
to behave sanely while changing a BAR
+/* Please call after prepare_to_enter. This function puts the lazy ee state
+ back to normal mode, without actually enabling interrupts. */
+static inline void kvmppc_lazy_ee_enable(void)
+{
+#ifdef CONFIG_PPC64
+ /* Only need to enable IRQs by hard enabling them after this */
+
On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
The guest should not expect memory accesses to an address
to behave sanely while changing a BAR anyway.
Yes, compatibility for change of GPA base can be done in the
kernel. I can look into it next week if nobody has done so at
that
-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
This is a bug fix and thus should probably be merged ASAP
arch/powerpc/kvm/book3s_pr.c |3 ++-
arch/powerpc/kvm/booke.c |2 ++
arch/powerpc/kvm/powerpc.c |2 --
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git
This adds an implementation of the XICS hypercalls in real
mode for HV KVM which allows us to avoid exiting the guest
MMU context on all threads for a variety of operations such
as fetching a pending interrupt, EOI of messages, IPIs, ...
Signed-off-by: Benjamin Herrenschmidt b
.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/kvm.h | 39 ++
arch/powerpc/include/asm/kvm_host.h |8 +
arch/powerpc/include/asm/kvm_ppc.h | 30 +-
arch/powerpc/kvm/Makefile |1 +
arch/powerpc/kvm/book3s.c |3
When making a vcpu non-runnable we incorrectly changed the
thread IDs of all other threads on the core, just remove that
code.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
This is a bug fix and thus should probably be merged ASAP
arch/powerpc/kvm/book3s_hv.c |6
significantly on HV KVM.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/kvm_book3s.h |1 +
arch/powerpc/kvm/book3s.c |2 +-
arch/powerpc/kvm/book3s_xics.c| 781 +
3 files changed, 501
On Fri, 2012-08-17 at 15:39 -0300, Marcelo Tosatti wrote:
On Fri, Aug 17, 2012 at 05:06:18PM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
The guest should not expect memory accesses to an address
to behave sanely while changing a BAR
+/* Please call after prepare_to_enter. This function puts the lazy ee state
+ back to normal mode, without actually enabling interrupts. */
+static inline void kvmppc_lazy_ee_enable(void)
+{
+#ifdef CONFIG_PPC64
+ /* Only need to enable IRQs by hard enabling them after this */
+
On Fri, 2012-08-10 at 11:27 +0200, Alexander Graf wrote:
Perhaps... these changes are to areas of the PPC KVM code that I
don't
use or maintain, so they're really more a suggestion of one way to
fix
the problem than anything else. That's why I put RFC in the subject
line. It would be
On Fri, 2012-08-10 at 11:27 +0200, Alexander Graf wrote:
Perhaps... these changes are to areas of the PPC KVM code that I
don't
use or maintain, so they're really more a suggestion of one way to
fix
the problem than anything else. That's why I put RFC in the subject
line. It would be
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, 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 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, 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 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 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 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 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, 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, 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,
.
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 before proposing an actual patch
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
.
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 before proposing an actual patch
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)
values.
This is for example the case of the rtas calls used to reboot the
machine where a new CPU state is established and must not be clobbered.
The simple fix is to always clear the hcall_needed flag when a
set-regs happen. This fixes reboot problems.
Signed-off-by: Benjamin Herrenschmidt b
values.
This is for example the case of the rtas calls used to reboot the
machine where a new CPU state is established and must not be clobbered.
The simple fix is to always clear the hcall_needed flag when a
set-regs happen. This fixes reboot problems.
Signed-off-by: Benjamin Herrenschmidt b
On Tue, 2012-07-24 at 12:04 -0700, Linus Torvalds wrote:
Ok, this caused conflicts with the s390 and ppc trees. I think I fixed
them correctly, but the respective arch people really should take a
look.
A quick peek at the merge commit looks allright, but Alex mentioned that
there's some more
301 - 400 of 689 matches
Mail list logo
