On Thu, 2012-07-12 at 11:12 +0300, Avi Kivity wrote:
On 07/12/2012 05:17 AM, Benjamin Herrenschmidt wrote:
ARM doesn't have an instruction for cpu_relax(), so it can't intercept
it. Given ppc's dislike of overcommit, and the way it implements
cpu_relax() by adjusting hw thread priority
On Thu, 2012-07-12 at 00:25 +0200, Alexander Graf wrote:
Or just free up another register early on, like here.
If you're going to do that, you want to measure the impact on null
syscall performance though.
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the
On Thu, 2012-07-12 at 00:35 +0200, Alexander Graf wrote:
On Thu, 2012-07-12 at 00:25 +0200, Alexander Graf wrote:
Or just free up another register early on, like here.
If you're going to do that, you want to measure the impact on null
syscall performance though.
That should hold true
ARM doesn't have an instruction for cpu_relax(), so it can't intercept
it. Given ppc's dislike of overcommit, and the way it implements
cpu_relax() by adjusting hw thread priority, I'm guessing it doesn't
intercept those either, but I'm copying the ppc people in case I'm
wrong. So it's s390
On Wed, 2012-07-11 at 14:23 +0300, Avi Kivity wrote:
On 07/11/2012 02:16 PM, Alexander Graf wrote:
yes the data structure itself seems based on the algorithm
and not on arch specific things. That should work. If we move that to
common
code then s390 will use that scheme automatically
On Thu, 2012-07-12 at 00:25 +0200, Alexander Graf wrote:
Or just free up another register early on, like here.
If you're going to do that, you want to measure the impact on null
syscall performance though.
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the
On Thu, 2012-07-12 at 00:35 +0200, Alexander Graf wrote:
On Thu, 2012-07-12 at 00:25 +0200, Alexander Graf wrote:
Or just free up another register early on, like here.
If you're going to do that, you want to measure the impact on null
syscall performance though.
That should hold true
On Wed, 2012-06-27 at 22:10 +1000, Benjamin Herrenschmidt wrote:
From: David Gibson da...@gibson.dropbear.id.au
This adds support for then new reset htab ioctl which allows qemu
to properly cleanup the MMU hash table when the guest is reset. With
the corresponding kernel support, reset
On Tue, 2012-07-10 at 17:25 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-06-27 at 22:10 +1000, Benjamin Herrenschmidt wrote:
From: David Gibson da...@gibson.dropbear.id.au
This adds support for then new reset htab ioctl which allows qemu
to properly cleanup the MMU hash table when
H_CEDE should enable the vcpu's MSR:EE bit. It does on HV KVM (it's
burried in the assembly code though) and as far as I can tell, qemu
does it as well.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Alex, you probably want that in -now- (and maybe even in stable).
Without
On Wed, 2012-06-27 at 22:10 +1000, Benjamin Herrenschmidt wrote:
From: David Gibson da...@gibson.dropbear.id.au
This adds support for then new reset htab ioctl which allows qemu
to properly cleanup the MMU hash table when the guest is reset. With
the corresponding kernel support, reset
On Tue, 2012-07-10 at 17:25 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-06-27 at 22:10 +1000, Benjamin Herrenschmidt wrote:
From: David Gibson da...@gibson.dropbear.id.au
This adds support for then new reset htab ioctl which allows qemu
to properly cleanup the MMU hash table when
H_CEDE should enable the vcpu's MSR:EE bit. It does on HV KVM (it's
burried in the assembly code though) and as far as I can tell, qemu
does it as well.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Alex, you probably want that in -now- (and maybe even in stable).
Without
On Wed, 2012-07-04 at 16:14 +0200, Alexander Graf wrote:
+#ifdef CONFIG_64BIT
+#define _hard_irq_disable() hard_irq_disable()
+#else
+#define _hard_irq_disable() local_irq_disable()
+#endif
So you only swap out the disable bit, but not the enable one? Ben,
would this work out?
On Wed, 2012-07-04 at 16:29 +0200, Alexander Graf wrote:
+#ifdef CONFIG_KVM_BOOKE_HV
+#define KVM_BOOKE_HV_MFSPR(reg, spr) \
+ BEGIN_FTR_SECTION \
+ mfspr reg, spr; \
+
On Wed, 2012-07-04 at 16:14 +0200, Alexander Graf wrote:
+#ifdef CONFIG_64BIT
+#define _hard_irq_disable() hard_irq_disable()
+#else
+#define _hard_irq_disable() local_irq_disable()
+#endif
So you only swap out the disable bit, but not the enable one? Ben,
would this work out?
On Wed, 2012-07-04 at 16:29 +0200, Alexander Graf wrote:
+#ifdef CONFIG_KVM_BOOKE_HV
+#define KVM_BOOKE_HV_MFSPR(reg, spr) \
+ BEGIN_FTR_SECTION \
+ mfspr reg, spr; \
+
On Mon, 2012-07-02 at 14:20 +0200, Alexander Graf wrote:
Ben, would you be opposed to a macro that does this? Open-coding
subtile details like this always makes me wary we could screw them
up :)
That's definitely material for a macro (and fixup the gazillion places
where we do it by hand
On Mon, 2012-07-02 at 14:20 +0200, Alexander Graf wrote:
Ben, would you be opposed to a macro that does this? Open-coding
subtile details like this always makes me wary we could screw them
up :)
That's definitely material for a macro (and fixup the gazillion places
where we do it by hand
a different size hash table
to the kernel and for the kernel to be able to impose limits on
the requested size.
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
hw/spapr.c | 88
On Wed, 2012-06-27 at 22:10 +1000, Benjamin Herrenschmidt wrote:
From: David Gibson da...@gibson.dropbear.id.au
This adds support for then new reset htab ioctl which allows qemu
to properly cleanup the MMU hash table when the guest is reset. With
the corresponding kernel support, reset
On Wed, 2012-06-27 at 14:30 +0200, Alexander Graf wrote:
Thanks, applied to ppc-next. Next time, please base on top of a newer
git base - I had to manually fix the patch to apply.
It was based on top of qemu master from yesterday. As you know that's
what I work on top of. Did you make sure you
a different size hash table
to the kernel and for the kernel to be able to impose limits on
the requested size.
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
hw/spapr.c | 88
On Wed, 2012-06-27 at 22:10 +1000, Benjamin Herrenschmidt wrote:
From: David Gibson da...@gibson.dropbear.id.au
This adds support for then new reset htab ioctl which allows qemu
to properly cleanup the MMU hash table when the guest is reset. With
the corresponding kernel support, reset
On Wed, 2012-06-27 at 14:30 +0200, Alexander Graf wrote:
Thanks, applied to ppc-next. Next time, please base on top of a newer
git base - I had to manually fix the patch to apply.
It was based on top of qemu master from yesterday. As you know that's
what I work on top of. Did you make sure you
On Wed, 2012-06-27 at 16:43 +0200, Alexander Graf wrote:
On 14.06.2012, at 06:29, Alexey Kardashevskiy wrote:
The following patches add MSIX support for PCI on POWER.
The first aim is virtio-pci so it was tested. It will also support
VFIO when it becomes available in public.
Wrong CC
On Mon, 2012-06-25 at 22:55 -0600, Alex Williamson wrote:
Hi,
VFIO has been kicking around for well over a year now and has been
posted numerous times for review. The pre-requirements are finally
available in linux-next (or will be in the 20120626 build) so I'd like
to request a new branch
On Mon, 2012-06-25 at 15:26 +0300, Mihai Caraman wrote:
Refactor exception prolog to allow save/restore register parameters. Add
addition none definition for exception prolog usage.
This is needed for exceptions like Guest Doorbell that use GSRRx regsiters
which do not map on exception type.
On Mon, 2012-06-25 at 15:26 +0300, Mihai Caraman wrote:
Machine check exception handler was using a wrong prolog. Hypervisors, like
KVM, which are called early from the exception handler rely on the interrupt
source.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
Ack.
Please
On Mon, 2012-06-25 at 15:26 +0300, Mihai Caraman wrote:
Embedded.Hypervisor category defines GSPRG0..3 physical registers for guests.
Avoid SPRG4-7 usage as scratch in host exception handlers, otherwise guest
SPRG4-7 registers will be clobbered.
For bolted TLB miss exception handlers, which is
On Mon, 2012-06-25 at 15:26 +0300, Mihai Caraman wrote:
Refactor exception prolog to allow save/restore register parameters. Add
addition none definition for exception prolog usage.
This is needed for exceptions like Guest Doorbell that use GSRRx regsiters
which do not map on exception type.
On Mon, 2012-06-25 at 15:26 +0300, Mihai Caraman wrote:
Embedded.Hypervisor category defines GSPRG0..3 physical registers for guests.
Avoid SPRG4-7 usage as scratch in host exception handlers, otherwise guest
SPRG4-7 registers will be clobbered.
For bolted TLB miss exception handlers, which is
On Mon, 2012-06-25 at 13:03 +0200, Alexander Graf wrote:
On 25.06.2012, at 11:07, Avi Kivity wrote:
On 06/25/2012 09:33 AM, k...@buildbot.b1-systems.de wrote:
The Buildbot has detected a new failure on builder ppc64 while building
kvm.
Full details are available at:
We were incorrectly g_free'ing an object that isn't allocated
in one error path and failed to release it completely in another
This fixes qemu crashes with some cases of IO errors.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
hw/spapr_vscsi.c |4 +++-
1 file changed, 3
internally calls H_RTAS.
We might in the future implement part (or even all) of RTAS inside the
guest like IBM's firmware does and replace H_RTAS with some finer grained
set of private hypercalls.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
This should address all your
On Tue, 2012-06-19 at 13:31 +0200, Andreas Färber wrote:
Tab alert. :)
Argh :-) Gotta get an emacs config for use with qemu :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, 2012-06-19 at 22:20 +0200, Alexander Graf wrote:
So do you want to resend? I can just fix it on the fly too.
If you can then sure, please do :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
We were incorrectly g_free'ing an object that isn't allocated
in one error path and failed to release it completely in another
This fixes qemu crashes with some cases of IO errors.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
hw/spapr_vscsi.c |4 +++-
1 file changed, 3
internally calls H_RTAS.
We might in the future implement part (or even all) of RTAS inside the
guest like IBM's firmware does and replace H_RTAS with some finer grained
set of private hypercalls.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
This should address all your
On Tue, 2012-06-19 at 13:31 +0200, Andreas Färber wrote:
Tab alert. :)
Argh :-) Gotta get an emacs config for use with qemu :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, 2012-06-19 at 22:20 +0200, Alexander Graf wrote:
So do you want to resend? I can just fix it on the fly too.
If you can then sure, please do :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More
this property using the supported page size
information that's already in the CPUState.
Signed-off-by: Nishanth Aravamudan n...@us.ibm.com
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
hw/spapr.c | 43
which should do the right thing for
existing HV and PR implementations. The fallback might not be correct
for future versions, but that's ok, because they'll have
KVM_PPC_GET_SMMU_INFO.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: David Gibson da
this property using the supported page size
information that's already in the CPUState.
Signed-off-by: Nishanth Aravamudan n...@us.ibm.com
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
hw/spapr.c | 43
which should do the right thing for
existing HV and PR implementations. The fallback might not be correct
for future versions, but that's ok, because they'll have
KVM_PPC_GET_SMMU_INFO.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: David Gibson da
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/bitops.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/bitops.h
b/arch/powerpc/include/asm/bitops.h
index efdc926..dc2cf9c 100644
--- a/arch
On Wed, 2012-06-13 at 12:44 +1000, Alexey Kardashevskiy wrote:
Ping?
FYI. The way it normally works on pseries is that RTAS, which is the
part of the firmware that lives inside the partition alongside the OS,
performs the accesses to configure the MSI/MSI-X.
With qemu pseries machine we don't
On Wed, 2012-06-13 at 13:39 +1000, Alexey Kardashevskiy wrote:
On 13/06/12 13:22, Benjamin Herrenschmidt wrote:
On Wed, 2012-06-13 at 12:44 +1000, Alexey Kardashevskiy wrote:
Ping?
FYI. The way it normally works on pseries is that RTAS, which is the
part of the firmware that lives
On Wed, 2012-06-06 at 17:17 -0600, Alex Williamson wrote:
diff --git a/drivers/vfio/pci/vfio_pci.c
b/drivers/vfio/pci/vfio_pci.c
index 1e5315c..6e7c12d 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -88,6 +88,8 @@ static void vfio_pci_disable(struct
On Wed, 2012-06-06 at 21:56 -0600, Alex Williamson wrote:
In so far as vfio should only have to call pci_reset_function and
device
quirks take care of everything else, I agree with you, but that
doesn't
answer any of my questions. Sure, we may want pre- and post-reset
fixup
quirks and a
On Thu, 2012-05-24 at 09:02 -0300, Jan Kiszka wrote:
Since PCI 2.3, this bit is mandatory, and it should be independent of
the masking bit. The question is, if your device is supposed to support
2.3, thus is just buggy,
It's a PCI Express device :-)
or if our detection algorithm is
Yep, that's what I'd suggest as well, add a blacklist to
pci_intx_mask_supported() so this device returns false and we require an
exclusive interrupt for it. Thanks,
BTW, we should consider supporting an MSI-only option for guests as
well:
LSIs are a problem for virtualization, especially
On Tue, 2012-06-05 at 03:44 +0200, Alexander Graf wrote:
Wouldn't the no LSI setting be a flag to the vfio configuration? So
when you set up the device group, you say this group can only do
MSI. That way the interface would be sysfs and QEMU wouldn't have
anything to do with it :)
Sure
On Mon, 2012-05-28 at 13:40 +0300, Avi Kivity wrote:
Depends. How do you detect it exists? Are you detecting kvm, or qemu,
or the hypercall itself?
I'd hate us to find ourselves in a maze of disconnected documentation
with no clear guidelines on when a feature is available and when it is
On Mon, 2012-05-28 at 13:40 +0300, Avi Kivity wrote:
Depends. How do you detect it exists? Are you detecting kvm, or qemu,
or the hypercall itself?
I'd hate us to find ourselves in a maze of disconnected documentation
with no clear guidelines on when a feature is available and when it is
On Fri, 2012-05-25 at 17:35 +1000, Alexey Kardashevskiy wrote:
Some adapters (like NEC PCI USB controller) do not flush their config
on a sioftware reset and remember DMA config, etc.
If we use such an adapter with QEMU, then crash QEMU (stop it with
ctrl-A ctrl-X), and try to use it in QEMU
On Fri, 2012-05-25 at 10:30 +0200, Alexander Graf wrote:
+while (count--) {
+switch (esize) {
+case 0: tmp = ldub_phys(src);
I'm surprised checkpatch didn't complain here. Please do
case x:
foo();
break();
break;
+case 1: tmp =
On Fri, 2012-05-25 at 10:54 +0200, Alexander Graf wrote:
case x:
foo();
break();
break;
+case 1: tmp = lduw_phys(src); break;
+case 2: tmp = ldl_phys(src); break;
+case 3: tmp = ldq_phys(src); break;
+default:
+return
I find your lack of taste disturbing Luke :-)
Heh :). I merely try to not collide with laws I can't influence easily and
don't bother to change enough ;).
Compliance with established authority has never been my strong point :-)
Yeah, it's a shame I didn't read through it more
On Fri, 2012-05-25 at 10:30 +0200, Alexander Graf wrote:
+while (count--) {
+switch (esize) {
+case 0: tmp = ldub_phys(src);
I'm surprised checkpatch didn't complain here. Please do
case x:
foo();
break();
break;
+case 1: tmp =
On Fri, 2012-05-25 at 10:54 +0200, Alexander Graf wrote:
case x:
foo();
break();
break;
+case 1: tmp = lduw_phys(src); break;
+case 2: tmp = ldl_phys(src); break;
+case 3: tmp = ldq_phys(src); break;
+default:
+return
I find your lack of taste disturbing Luke :-)
Heh :). I merely try to not collide with laws I can't influence easily and
don't bother to change enough ;).
Compliance with established authority has never been my strong point :-)
Yeah, it's a shame I didn't read through it more
On Thu, 2012-05-24 at 09:12 -0600, Alex Williamson wrote:
--- /dev/null
+++ b/arch/powerpc/kernel/iommu_vfio.c
Should this be drivers/vfio/vfio_iommu_powerpc.c?
Very minor bike shed painting... too long file names suck, in
this case what's the point of the vfio prefix for files already
in
On Mon, 2012-05-21 at 16:55 +0300, Avi Kivity wrote:
As to adding things to PAPR, let's assume for now that this isn't
possible :-) Besides, those two hypercalls are pretty specific to
the
way things are implemented in qemu and are in both case more or less
private mechanisms used to
and so would
otherwise require an hcall per 8 bytes access.
The performance is still not great but usable, and can be improved
with a more complex implementation of the hcall itself if needed.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2: - Added documentation for our
On Mon, 2012-05-21 at 16:55 +0300, Avi Kivity wrote:
As to adding things to PAPR, let's assume for now that this isn't
possible :-) Besides, those two hypercalls are pretty specific to
the
way things are implemented in qemu and are in both case more or less
private mechanisms used to
and so would
otherwise require an hcall per 8 bytes access.
The performance is still not great but usable, and can be improved
with a more complex implementation of the hcall itself if needed.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2: - Added documentation for our
the KVM_CAP_IRQCHIP symbol is defined on all platforms (though the
capability only exists on x86), whereas KVM_IRQCHIP_PIC_MASTER is
only defined on x86. (If a better symbol exists it could be used
instead.)
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
An equivalent of this is already
-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
This appears to be unnecessary on qemu-kvm master or the main qemu
hw/i8254.c |3 ++-
hw/i8259.c |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/i8254.c b/hw/i8254.c
index 019c7b8..878a47b 100644
--- a/hw/i8254.c
, in either the new
or the old form, this removes the check that caused qemu to bail out
if the ioctl returns an error. In fact we don't even print a message,
since it got printed once per vcpu, which gets a bit tedious with more
than a few vcpus.
Signed-off-by: Benjamin Herrenschmidt b
An equivalent of this is already in qemu-kvm master as commit id
20ad1def644494f5055d129961d46b050c0a6158
What is the interest of patching qemu-kvm for non-x86? It is not
supposed to be used for this. And the affected bits are history in 1.1
(or 1.2 latest). Are there distros proving
On Tue, 2012-05-22 at 09:13 +0200, Alexander Graf wrote:
On 22.05.2012, at 09:01, Alexey Kardashevskiy wrote:
This is internal kitchen of PCIDevice which I do not want to touch
from anywhere but pci.c. And
there is no fixup_capability or something.
Hrm. Maybe we should have one? :) Or
and so would
otherwise require an hcall per 8 bytes access.
The performance is still not great but usable, and can be improved
with a more complex implementation of the hcall itself if needed.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
hw/spapr.h |3 ++-
hw
On Mon, 2012-05-21 at 10:38 +0200, Alexander Graf wrote:
On 21.05.2012, at 09:24, Benjamin Herrenschmidt wrote:
This adds a kvm-specific hypervisor call to the pseries machine
which allows to do what amounts to memmove, memcpy and xor over
regions of physical memory
On Mon, 2012-05-21 at 12:47 +0300, Avi Kivity wrote:
On 05/21/2012 10:24 AM, Benjamin Herrenschmidt wrote:
This adds a kvm-specific hypervisor call to the pseries machine
which allows to do what amounts to memmove, memcpy and xor over
regions of physical memory such as the framebuffer
On Mon, 2012-05-21 at 13:07 +0300, Avi Kivity wrote:
Now I'm adding another one, so yes, it's looking like a trend :-) I'll
look into it, at this stage with only those two, adding some comments in
the header might be plenty enough.
Documentation/virtual/kvm/ppc-pv.txt is a nice central
On Mon, 2012-05-21 at 16:55 +0300, Avi Kivity wrote:
Okay. But let's have a spec, even a kvm-private one, and then an
implementation of that spec, instead of an implementation and some
documentation added as an afterthought (or not).
It's a bit like if you had private calls between
On Fri, 2012-05-18 at 15:12 +1000, Alexey Kardashevskiy wrote:
Alexander,
Is that any better? :)
Alex (Graf that is), ping ?
The original patch from Alexey was fine btw.
VFIO will always call things with the existing capability offset so
there's no real risk of doing the wrong thing or
and so would
otherwise require an hcall per 8 bytes access.
The performance is still not great but usable, and can be improved
with a more complex implementation of the hcall itself if needed.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
hw/spapr.h |3 ++-
hw
On Mon, 2012-05-21 at 12:47 +0300, Avi Kivity wrote:
On 05/21/2012 10:24 AM, Benjamin Herrenschmidt wrote:
This adds a kvm-specific hypervisor call to the pseries machine
which allows to do what amounts to memmove, memcpy and xor over
regions of physical memory such as the framebuffer
On Mon, 2012-05-21 at 13:07 +0300, Avi Kivity wrote:
Now I'm adding another one, so yes, it's looking like a trend :-) I'll
look into it, at this stage with only those two, adding some comments in
the header might be plenty enough.
Documentation/virtual/kvm/ppc-pv.txt is a nice central
On Mon, 2012-05-21 at 16:55 +0300, Avi Kivity wrote:
Okay. But let's have a spec, even a kvm-private one, and then an
implementation of that spec, instead of an implementation and some
documentation added as an afterthought (or not).
It's a bit like if you had private calls between
On Thu, 2012-05-17 at 12:16 +1000, Alexey Kardashevskiy wrote:
It actually can change dynamically on x86 due to acpi interrupt links
which allow the guest a generic way to select from a set of possible
interrupt routing schemes. And of course a chipset driver could twiddle
bits if it
this property using the supported page size
information that's already in the CPUState.
Signed-off-by: Nishanth Aravamudan n...@us.ibm.com
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2: - Passes checkpatch
- Removed
this property using the supported page size
information that's already in the CPUState.
Signed-off-by: Nishanth Aravamudan n...@us.ibm.com
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2: - Passes checkpatch
- Removed
On Sun, 2012-05-13 at 22:16 -0600, Alex Williamson wrote:
However theoretically we might want to show these 3 PCIe bridges as well
(but not the root complex).
For example, INTx lines should be swizzled when the guest parses a device
tree and
tries to calculate a real IRQ number. VFIO
On Sat, 2012-05-12 at 17:31 +1000, Alexey Kardashevskiy wrote:
And drivers/vfio/vfio_iommu_x86.c works perfect for POWER except a DMA
window setup
which I dropped for now and simply use quite popular configuration on
power (1Gb DMA window starting
from 0x0).
As for me, it is too
On Thu, 2012-05-10 at 20:55 +0300, Avi Kivity wrote:
On 05/10/2012 08:49 PM, Alexander Graf wrote:
+#if defined(TARGET_PPC64)
+if (def-sps)
+memcpy(env-sps, def-sps, sizeof(*def-sps));
I never know if *def-... would dereference def or the complete
construct.
'man
+for (count = 0; count PPC_PAGE_SIZES_MAX_SZ; count++) {
+if (sps-enc[count].page_shift == 0) {
+break;
+}
+}
+if ((p - prop)= (maxcells - 3 - count * 2))
Is this valid C? Can you substract one pointer from another
On Wed, 2012-05-09 at 13:10 -0700, H. Peter Anvin wrote:
On 05/09/2012 01:07 PM, Michael S. Tsirkin wrote:
In practice ATM any of the above will work. We probably don't even need
to add barrier() calls since what we do afterwards is apic access which
has an optimization barrier anyway.
This is a small collection of build fixes that allow the
qemu-kvm tree to build a ppc64-softmmu target with kvm
enabled (provided device-assignment is disabled).
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Avi, Marcelo: This is really only for qemu-kvm, not upstream qemu
On Wed, 2012-05-02 at 15:32 +0200, Alexander Graf wrote:
This function needs to be available in real mode on HV, but the ones
below must be on module code when kvm is compiled as a module,
because
they call kvm infrastructure which lives in module code.
Yes, I realized that, can you fix it
On Wed, 2012-05-02 at 23:21 +0200, Alexander Graf wrote:
If you're too busy to fix it up, I can give it another wuick try
though...
That would be great... I'll have no time til at least next week.
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
On Wed, 2012-05-02 at 15:32 +0200, Alexander Graf wrote:
This function needs to be available in real mode on HV, but the ones
below must be on module code when kvm is compiled as a module,
because
they call kvm infrastructure which lives in module code.
Yes, I realized that, can you fix it
On Wed, 2012-05-02 at 23:21 +0200, Alexander Graf wrote:
If you're too busy to fix it up, I can give it another wuick try
though...
That would be great... I'll have no time til at least next week.
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of
On Fri, 2012-04-27 at 13:23 +0200, Alexander Graf wrote:
On 27.04.2012, at 07:48, Paul Mackerras wrote:
On Thu, Apr 26, 2012 at 12:19:03PM +0200, Alexander Graf wrote:
So switch the code over to call into the Linux C handlers from C code,
speeding up everything along the way.
I
On Fri, 2012-04-27 at 13:23 +0200, Alexander Graf wrote:
On 27.04.2012, at 07:48, Paul Mackerras wrote:
On Thu, Apr 26, 2012 at 12:19:03PM +0200, Alexander Graf wrote:
So switch the code over to call into the Linux C handlers from C code,
speeding up everything along the way.
I
+static void kvmppc_fill_pt_regs(struct pt_regs *regs)
+{
+ ulong r1, ip, msr, lr;
+
+ asm(mr %0, 1 : =r(r1));
+ asm(mflr %0 : =r(lr));
+ asm(mfmsr %0 : =r(msr));
+ asm(bl 1f; 1: mflr %0 : =r(ip));
+
+ memset(regs, 0, sizeof(*regs));
+ regs-gpr[1] = r1;
+
On Thu, 2012-04-26 at 16:54 -0500, Scott Wood wrote:
On 04/26/2012 05:19 AM, Alexander Graf wrote:
+ asm(mfmsr %0 : =r(msr));
Why not just mfmsr()?
+ asm(bl 1f; 1: mflr %0 : =r(ip));
You'll want to tell the compiler that you're trashing LR.
We probably also want to make sure
On Fri, 2012-04-27 at 00:24 +0200, Alexander Graf wrote:
This is to actually enable interrupts for real, regardless of ppc64
and ppc32. In fact, the previous code was pretty buggy - it was
running the handlers with interrupts disabled ;).
They should be run with interrupts disabled.. tho
401 - 500 of 689 matches
Mail list logo
