On 07/13/2012 07:24 PM, Srikar Dronamraju wrote:
On 12/07/12 21:18, Raghavendra K T wrote:
+#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
[...]
+ struct {
+ bool cpu_relax_intercepted;
+ bool dy_eligible;
+ } ple;
+#endif
[...]
}
vcpu-run
Currently Pause Loop Exit (PLE) handler is doing directed yield to a
random vcpu on pl-exit. We already have filtering while choosing
the candidate to yield_to. This change adds more checks while choosing
a candidate to yield_to.
On a large vcpu guests, there is a high probability of
yielding to
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Noting pause loop exited vcpu or cpu relax intercepted helps in
filtering right candidate to yield. Wrong selection of vcpu;
i.e., a vcpu that just did a pl-exit or cpu relax intercepted may
contribute to performance degradation.
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Suggested-by: Avi Kivity a...@redhat.com
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
arch/s390/kvm/Kconfig |1 +
arch/x86/kvm/Kconfig |1 +
virt/kvm/Kconfig |3 +++
3 files changed, 5
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Currently, on a large vcpu guests, there is a high probability of
yielding to the same vcpu who had recently done a pause-loop exit or
cpu relax intercepted. Such a yield can lead to the vcpu spinning
again and hence degrade the performance.
Hi Christoph,
On 07/14/2012 03:49 PM, Christoph Hellwig wrote:
Please send a version that does direct block I/O similar to xen-blkback
for now.
Seems xen-blkback converts the guest IO request to host bio and submit
them directly. I was wondering whether this has a performance gain
compared
* Michael S. Tsirkin m...@redhat.com wrote:
KVM PV EOI optimization overrides eoi_write apic op with its own
version. Add an API for this to avoid meddling with core x86 apic driver
data structures directly.
For KVM use, we don't need any guarantees about when the switch to the
new op
On 07/15/2012 03:56 PM, Michael S. Tsirkin wrote:
KVM PV EOI optimization overrides eoi_write apic op with its own
version. at Ingo's suggestion, add an API for this and switch kvm to use
it, to avoid meddling with core x86 apic driver data structures
directly.
Applied to next, thanks.
--
On 07/16/2012 11:25 AM, Raghavendra K T wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Noting pause loop exited vcpu or cpu relax intercepted helps in
filtering right candidate to yield. Wrong selection of vcpu;
i.e., a vcpu that just did a pl-exit or cpu relax intercepted
On 07/16/2012 11:25 AM, Raghavendra K T wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Currently, on a large vcpu guests, there is a high probability of
yielding to the same vcpu who had recently done a pause-loop exit or
cpu relax intercepted. Such a yield can lead to the
qemu-kvm-1.1.1 is now available. This release is based on the upstream
qemu 1.1.1, plus kvm-specific enhancements. Please see the
original QEMU 1.1.1 release announcement [1] for details.
This release can be used with the kvm kernel modules provided by your
distribution kernel, or by the modules
Hello,
with linux kernel 3.5rc6 and 3.5rc7
I do not test with other kernel 3.5.
On linux kernel 3.3.8 , threre is no problem.
If I start qemu-kvm process, system is overload and
dmesg :
BUG: unable to handle kernel paging request at 0001003b
IP: [8119f694]
On 07/16/2012 02:06 PM, nicolas prochazka wrote:
Hello,
with linux kernel 3.5rc6 and 3.5rc7
I do not test with other kernel 3.5.
On linux kernel 3.3.8 , threre is no problem.
If I start qemu-kvm process, system is overload and
dmesg :
BUG: unable to handle kernel paging request at
On 07/14/2012 03:55 PM, Jan Kiszka wrote:
The only way we can avoid that, is that we get a hint from the
underlying irq chip/ handler setup with an extra flag to tell the
core, that it's safe to avoid the ONESHOT/finalize magic.
So now it took a full month of ignorance to come up with the
Hello,
I suspect upgrading my system to glibc-2.15 was a mistake. It seems to
be qemu-1.0.1, and latter versions including qemu-1.1.1, can't be
compiled anymore. Yes, I did search around and that led me to glibc,
resp. http://sourceware.org/ml/libc-ports/2011-08/msg00019.html
Please, could
On Sun, 2012-07-15 at 13:09 +0300, Avi Kivity wrote:
On 07/12/2012 08:38 PM, Alex Williamson wrote:
On Thu, 2012-07-12 at 10:19 -0600, Alex Williamson wrote:
On Thu, 2012-07-12 at 12:35 +0300, Avi Kivity wrote:
On 07/11/2012 10:57 PM, Alex Williamson wrote:
We still have classic
On Thu, Jul 12, 2012 at 7:35 AM, 김민규 mingyu84@samsung.com wrote:
+ /*
+* Make sure preemption is disabled while calling handle_exit
+* as exit handling touches CPU-specific resources, such as
+* caches, and we must stay on the
Hi Bexoff,
I can confirm that we are currently using a patched 2.13 on my project; it may
be that 2.14 produces issues, or requires special instructions or patches to
make it work with late qemu-kvm.
I have had no issues using 2.13 on k-q 1.1 and below.
Simon
This makes some changes to the virtio-scsi event specification, so that
it is now possible to use virtio-scsi events in the implementation of
the QEMU block_resize command.
Thanks to Cong Meng for finally implementing virtio-scsi hotplug, which
made me look at block_resize again!
Paolo Bonzini
All currently defined event structs have the same fields. Simplify the
driver by enforcing this also for future structs.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
virtio-spec.lyx | 69 +++
1 file changed, 65 insertions(+), 4
This adds an event for changes to LUN parameters, for example capacity. These
are reported in virtio-blk via configuration changes, and we want a similar
functionality in virtio-scsi too.
There is no list of supported parameter changes, instead we just refer to
the list of sense codes in the
This series adds support for block_resize to virtio-scsi. Events
are reported via a new event type. Patches to the spec are on the
list.
Paolo Bonzini (5):
scsi-disk: removable hard disks support START/STOP
scsi-disk: report resized disk via sense codes
scsi: establish precedence levels
Support for START/STOP UNIT right now is limited to CD-ROMs. This is wrong,
since removable hard disks (in the real world: SD card readers) also support
it in pretty much the same way.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/scsi-disk.c |2 +-
1 file changed, 1 insertion(+),
Linux will not use these, but a very similar mechanism will be used to
report the condition via virtio-scsi events.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/scsi-bus.c |5 +
hw/scsi-disk.c | 15 +++
hw/scsi.h |2 ++
3 files changed, 18
When a device is resized, we will report a unit attention condition
for CAPACITY DATA HAS CHANGED. However, we should ensure that this
condition does not override a more important unit attention condition.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/scsi-bus.c | 52
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/scsi-bus.c | 10 ++
hw/scsi-disk.c |2 +-
hw/scsi.h |2 ++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index d5e1fb0..77aa946 100644
--- a/hw/scsi-bus.c
+++
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/virtio-scsi.c | 16
1 file changed, 16 insertions(+)
diff --git a/hw/virtio-scsi.c b/hw/virtio-scsi.c
index 83dbabd..80a47d7 100644
--- a/hw/virtio-scsi.c
+++ b/hw/virtio-scsi.c
@@ -27,6 +27,7 @@
/* Feature Bits */
On 07/16/2012 05:03 PM, Alex Williamson wrote:
This is what I meant, except I forgot that we already do direct path for
MSI.
Ok, vfio now does it for the unmask irqfd-line interface too. Except
when we re-inject from eoifd we have to do the eventfd_signal from a
work queue as we can't
No, It is not 100% reproductible, I'm trying to find the case, but :
Now when i start a qemu-kvm ,
there is a kvm-pit/ which takes a lot of cpu time ( ~ 20 %) , (
not with kernel 3.3.8 )
for the complete stack trace, which kernel options should i set,
i've already kernel debug .
Regards,
On 07/16/2012 05:37 PM, nicolas prochazka wrote:
No, It is not 100% reproductible, I'm trying to find the case, but :
Now when i start a qemu-kvm ,
there is a kvm-pit/ which takes a lot of cpu time ( ~ 20 %) , (
not with kernel 3.3.8 )
for the complete stack trace, which kernel
sorry,
i recompile kernel with some option, and crash again :
( it seems i need to run a lot of qemu process to bug )
[ 3117.379546] BUG: unable to handle kernel paging request at 0001003b
[ 3117.379783] IP: [811a3654] tid_fd_revalidate+0x84/0x1a0
[ 3117.379978] PGD 6ea4e0067 PUD
On Mon, Jul 16, 2012 at 4:11 PM, Veruca Salt verucasal...@hotmail.co.uk wrote:
Hi Bexoff,
I can confirm that we are currently using a patched 2.13 on my project; it
may be that 2.14 produces issues, or requires special instructions or patches
to make it work with late qemu-kvm.
I have
On 07/16/2012 05:46 PM, nicolas prochazka wrote:
sorry,
i recompile kernel with some option, and crash again :
( it seems i need to run a lot of qemu process to bug )
[ 3117.379546] BUG: unable to handle kernel paging request at 0001003b
[ 3117.379783] IP: [811a3654]
On Sun, 2012-07-15 at 19:32 +0300, Michael S. Tsirkin wrote:
On Fri, Jul 13, 2012 at 01:41:05PM -0600, Alex Williamson wrote:
+static int kvm_assign_eoifd(struct kvm *kvm, struct kvm_eoifd *args)
+{
+ struct eventfd_ctx *level_irqfd = NULL, *eventfd = NULL;
+ struct _eoifd *eoifd =
(fixed mailing list)
On 07/16/2012 03:37 PM, X O wrote:
Hello,
I suspect upgrading my system to glibc-2.15 was a mistake. It seems to
be qemu-1.0.1, and latter versions including qemu-1.1.1, can't be
compiled anymore. Yes, I did search around and that led me to glibc,
resp.
On 07/16/2012 06:07 AM, Avi Kivity wrote:
+{
+ bool eligible;
+
+ eligible = !vcpu-ple.cpu_relax_intercepted ||
+ (vcpu-ple.cpu_relax_intercepted
+vcpu-ple.dy_eligible);
+
+ if (vcpu-ple.cpu_relax_intercepted)
+
On Mon, Jul 16, 2012 at 5:14 PM, Avi Kivity a...@redhat.com wrote:
(fixed mailing list)
On 07/16/2012 03:37 PM, X O wrote:
Hello,
I suspect upgrading my system to glibc-2.15 was a mistake. It seems to
be qemu-1.0.1, and latter versions including qemu-1.1.1, can't be
compiled anymore. Yes,
On 07/16/2012 09:40 PM, Rik van Riel wrote:
On 07/16/2012 06:07 AM, Avi Kivity wrote:
+{
+ bool eligible;
+
+ eligible = !vcpu-ple.cpu_relax_intercepted ||
+ (vcpu-ple.cpu_relax_intercepted
+ vcpu-ple.dy_eligible);
+
+ if (vcpu-ple.cpu_relax_intercepted)
+ vcpu-ple.dy_eligible =
On 07/09/2012 12:34 PM, Bharat Bhushan wrote:
This patch adds the watchdog emulation in KVM. The watchdog
emulation is enabled by KVM_ENABLE_CAP(KVM_CAP_PPC_WDT) ioctl.
The kernel timer are used for watchdog emulation and emulates
h/w watchdog state machine. On watchdog timer expiry, it exit
On 07/16/2012 03:31 PM, Avi Kivity wrote:
On 07/16/2012 11:25 AM, Raghavendra K T wrote:
From: Raghavendra K Traghavendra...@linux.vnet.ibm.com
Noting pause loop exited vcpu or cpu relax intercepted helps in
filtering right candidate to yield. Wrong selection of vcpu;
i.e., a vcpu that just
On 07/16/2012 03:37 PM, Avi Kivity wrote:
On 07/16/2012 11:25 AM, Raghavendra K T wrote:
From: Raghavendra K Traghavendra...@linux.vnet.ibm.com
Currently, on a large vcpu guests, there is a high probability of
yielding to the same vcpu who had recently done a pause-loop exit or
cpu relax
Hi
Please send in any agenda items you are interested in covering.
Later, Juan.
--
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 http://vger.kernel.org/majordomo-info.html
This is an alternative to kvm_set_irq(,,,0) which returns the previous
assertion state of the interrupt and does nothing if it isn't changed.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
include/linux/kvm_host.h |3 ++
virt/kvm/irq_comm.c | 78
We can drop any kind of serialization on the injection side as we
expect spurious injections to be both rare and safe. On the EOI
side, this continues to filter out both the pic/ioapic work and
the eventfd signaling if our source ID has not set the interrupt.
Signed-off-by: Alex Williamson
In order to inject a level interrupt from an external source using an
irqfd, we need to allocate a new irq_source_id. This allows us to
assert and (later) de-assert an interrupt line independently from
users of KVM_IRQ_LINE and avoid lost interrupts.
We also add what may appear like a bit of
This new ioctl enables an eventfd to be triggered when an EOI is
written for a specified irqchip pin. The first user of this will
be external device assignment through VFIO, using a level irqfd
for asserting a PCI INTx interrupt and this interface for de-assert
and notification once the interrupt
On Mon, Jul 16, 2012 at 08:16:12PM +0200, Dominic Eschweiler wrote:
Am Freitag, den 13.07.2012, 21:19 +0300 schrieb Michael S. Tsirkin:
UIO has the same property, doesn't it? Multiple users can
access device memory through sysfs.
Indeed, that's a similar problem. I haven't tried it
On Mon, Jul 16, 2012 at 02:34:03PM -0600, Alex Williamson wrote:
This is an alternative to kvm_set_irq(,,,0) which returns the previous
assertion state of the interrupt and does nothing if it isn't changed.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
On Mon, Jul 16, 2012 at 02:34:03PM -0600, Alex Williamson wrote:
This is an alternative to kvm_set_irq(,,,0) which returns the previous
assertion state of the interrupt and does nothing if it isn't changed.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
On 07/16/2012 12:18 PM, Alexander Graf wrote:
+/*
+ * Return the number of jiffies until the next timeout. If the
timeout is
+ * longer than the NEXT_TIMER_MAX_DELTA, that
then?
return NEXT_TIMER_MAX_DELTA
+ * instead.
I can read code.
Come on, it's not exactly x++; /* add one to
On Mon, 16 Jul 2012 16:24:37 +0200, Paolo Bonzini pbonz...@redhat.com wrote:
This adds an event for changes to LUN parameters, for example capacity. These
are reported in virtio-blk via configuration changes, and we want a similar
functionality in virtio-scsi too.
Both applied.
Thanks!
On Tue, 2012-07-17 at 03:51 +0300, Michael S. Tsirkin wrote:
On Mon, Jul 16, 2012 at 02:34:03PM -0600, Alex Williamson wrote:
This is an alternative to kvm_set_irq(,,,0) which returns the previous
assertion state of the interrupt and does nothing if it isn't changed.
Signed-off-by: Alex
Hi all,
I have a question as the subject above, the reason I want to know this is that,
if I attach some disks on the guest,
for example, I specified /dev/vdc/dev/vdd(target device) at the cmd line by
using 'virsh attach-disk', but they may be /dev/vdb/dev/vdc in the guest os,
so if the guest
Changes since v3:
- using bitmap_set() instead of set_bit() in numa_add() routine.
- removed call to bitmak_zero() since bitmap_new() also zeros' the bitmap.
- Rebased to the latest qemu.
Changes since v2:
- Using unsigned long * for the node_cpumask[].
- Use bitmap_new() instead
Hi all,
This is a series for kvmtool that uses a newish kernel API to get
MMU info, which is then fed to the guest.
Currently we just make a good guess based on the PVR, but that is
potentially flakey in a few ways. The most notable is that if you don't
specify hugepages we don't boot - because
On some powerpc platforms we need to make sure we only advertise page
sizes to the guest which are = the size of the pages backing guest RAM.
So have mmap_hugetblfs() save the hugetblfs page size for us, and also
teach mmap_anon_or_hugetblfs() to set the page size for anonymous mmap.
Recent kernels (= v3.5-rc1) have an ioctl which allows us to retrieve the
list of page sizes supported for the guest.
So rework the cpu info code to use that ioctl when available, falling
back to the same values we used previously if the ioctl is not present.
We may also need to filter the list
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/powerpc/cpu_info.c |7 ---
tools/kvm/powerpc/cpu_info.h |2 --
tools/kvm/powerpc/kvm.c |7 ---
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/powerpc/cpu_info.c |3 +--
tools/kvm/powerpc/cpu_info.h |1 -
tools/kvm/powerpc/kvm.c |5 +++--
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c
So we can use it on powerpc.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/include/kvm/util.h |2 +-
tools/kvm/util/util.c| 13 +
tools/kvm/x86/kvm.c | 13 -
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/powerpc/cpu_info.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index ad27451..7326f5b 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++
We are about to add more logic to find_cpu_info(). To support this we
need to pass kvm through to it, and also restructure the return flow
so we can operate on info before it is returned.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/powerpc/cpu_info.c | 16
Matt's enter key was broken when he wrote this ;)
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/powerpc/cpu_info.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index
Using designated initializers for structs is preferable because it
is self documenting, and more robust against changes to the structure
layout.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/powerpc/cpu_info.c | 38 +-
It implements essentially the same logic. The one difference is it sets
MAP_NORESERVE when using anonymous mmap, but I think that is OK.
Reword the comment about hugetblfs, we are no longer required to use
hugepages to back the guest.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
On 07/12/2012 01:07 PM, Bharat Bhushan wrote:
Linux mpic driver uses (changes may be in pipeline to get upstreamed soon)
BRR1. This patch adds the support to emulate readonly BRR1.
Signed-off-by: Bharat Bhushanbharat.bhus...@freescale.com
---
hw/openpic.c |6 ++
1 files changed, 6
On 16.07.2012, at 18:21, Bhushan Bharat-R65777 r65...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Monday, July 16, 2012 8:25 PM
To: Bhushan Bharat-R65777
Cc: qemu-...@nongnu.org; kvm-ppc@vger.kernel.org; Bhushan Bharat-R65777
On 07/16/2012 11:21 AM, Bhushan Bharat-R65777 wrote:
+case 0x00: /* BRR1 */
+retval = 0x00400200;
Please unmagicify this one :)
/* BRR1 ( Block revision register ) */
#define IPID 0x0040 /* IP-block ID */
#define IPMJ 0x0200 /* IP major number */
#define IPMN
-Original Message-
From: Wood Scott-B07421
Sent: Monday, July 16, 2012 10:34 PM
To: Bhushan Bharat-R65777
Cc: Alexander Graf; qemu-...@nongnu.org; kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] openpic: Added BRR1 register
On 07/16/2012 11:21 AM, Bhushan Bharat-R65777 wrote:
+
On 07/16/2012 12:09 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Monday, July 16, 2012 10:34 PM
To: Bhushan Bharat-R65777
Cc: Alexander Graf; qemu-...@nongnu.org; kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] openpic: Added BRR1 register
On
On 07/16/2012 02:29 PM, Yoder Stuart-B08248 wrote:
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org]
On Behalf Of Scott Wood
Sent: Monday, July 16, 2012 12:12 PM
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421; Alexander Graf;
On 16.07.2012, at 21:32, Scott Wood wrote:
On 07/16/2012 02:29 PM, Yoder Stuart-B08248 wrote:
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org]
On Behalf Of Scott Wood
Sent: Monday, July 16, 2012 12:12 PM
To: Bhushan Bharat-R65777
On 07/16/2012 12:18 PM, Alexander Graf wrote:
+/*
+ * Return the number of jiffies until the next timeout. If the
timeout is
+ * longer than the NEXT_TIMER_MAX_DELTA, that
then?
return NEXT_TIMER_MAX_DELTA
+ * instead.
I can read code.
Come on, it's not exactly x++; /* add one to
FYI, MPIC version on P4080 is 0401.
#define IPMJ 0x0400
#define IPMN 0x0001
Best Regards,
Olivia
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
Behalf Of Bhushan Bharat-R65777
Sent: Tuesday, July 17, 2012 1:10 AM
To: Wood
Hi all,
This is a series for kvmtool that uses a newish kernel API to get
MMU info, which is then fed to the guest.
Currently we just make a good guess based on the PVR, but that is
potentially flakey in a few ways. The most notable is that if you don't
specify hugepages we don't boot - because
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/powerpc/cpu_info.c |7 ---
tools/kvm/powerpc/cpu_info.h |2 --
tools/kvm/powerpc/kvm.c |7 ---
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/powerpc/cpu_info.c |3 +--
tools/kvm/powerpc/cpu_info.h |1 -
tools/kvm/powerpc/kvm.c |5 +++--
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c
Recent kernels (= v3.5-rc1) have an ioctl which allows us to retrieve the
list of page sizes supported for the guest.
So rework the cpu info code to use that ioctl when available, falling
back to the same values we used previously if the ioctl is not present.
We may also need to filter the list
So we can use it on powerpc.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/include/kvm/util.h |2 +-
tools/kvm/util/util.c| 13 +
tools/kvm/x86/kvm.c | 13 -
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git
Using designated initializers for structs is preferable because it
is self documenting, and more robust against changes to the structure
layout.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
tools/kvm/powerpc/cpu_info.c | 38 +-
It implements essentially the same logic. The one difference is it sets
MAP_NORESERVE when using anonymous mmap, but I think that is OK.
Reword the comment about hugetblfs, we are no longer required to use
hugepages to back the guest.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
81 matches
Mail list logo
