Hi all,
I have 2 physical machines, same installation, maybe some minor hardware
differences, but basically the same CPU, HDD.
I would like to experiment "the cloud" home.
I create a KVM VM (usually with virt-install) on the first machine.
I would like to
- duplicate & synchronize the 1rst VM
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
---
tools/kvm/powerpc/kvm.c
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
---
tools/kvm/powerpc/cpu_info.c | 38 +-
tools/kvm/powerpc/cpu_info.h |6 +++
Matt's enter key was broken when he wrote this ;)
Signed-off-by: Michael Ellerman
---
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 7326f5b..586b232 100644
--- a/tools/kv
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
---
tools/kvm/powerpc/cpu_info.c | 16 +++-
tools/kvm/powerpc/
Signed-off-by: Michael Ellerman
---
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
+++ b/tools/kvm/powerpc/cpu_info.c
@
So we can use it on powerpc.
Signed-off-by: Michael Ellerman
---
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 a/tools/kvm/include/kvm/ut
Signed-off-by: Michael Ellerman
---
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 b/tools/kvm/powerpc/cpu_info.c
index 82a9d4f..
Signed-off-by: Michael Ellerman
---
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 b/tools/kvm/powerpc/cpu_info.c
index 1
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
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.
Signed-off-
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 t
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,
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 u
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-b
On Mon, 16 Jul 2012 16:24:37 +0200, Paolo Bonzini 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!
Rusty.
--
To unsubscri
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++;
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
> ---
>
> include/linux/kvm_host.h |3 ++
> v
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
> ---
>
> include/linux/kvm_host.h |3 ++
> v
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 t
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
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 exce
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
---
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
---
include/linux/kvm_host.h |3 ++
virt/kvm/irq_comm.c | 78 ++
2
v5:
- irqfds now have a one-to-one mapping with eoifds to prevent users
from consuming all of kernel memory by repeatedly creating eoifds
from a single irqfd.
- implement a kvm_clear_irq() which does a test_and_clear_bit of
the irq_state, only updating the pic/ioapic if changes and allow
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
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 (yet), but this
particular problem can maybe circumvented by using mmap wi
On 07/16/2012 03:37 PM, Avi Kivity wrote:
On 07/16/2012 11:25 AM, Raghavendra K T wrote:
From: Raghavendra K T
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 t
On 07/16/2012 03:31 PM, Avi Kivity wrote:
On 07/16/2012 11:25 AM, Raghavendra K T wrote:
From: Raghavendra K T
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 intercept
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 ex
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 = !vcpu->p
On Mon, Jul 16, 2012 at 5:14 PM, Avi Kivity 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, I d
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)
+
(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. http://sou
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 *eo
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: [] tid_fd_revalida
On Mon, Jul 16, 2012 at 4:11 PM, Veruca Salt 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 had no issues using 2.
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: [] tid_fd_revalidate+0x84/0x1a0
[ 3117.379978] PGD 6ea4e0067 PUD 0
[ 3117.380012]
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 o
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,
Ni
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
Signed-off-by: Paolo Bonzini
---
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 */
#define VIRTIO_SCSI_F_IN
Signed-off-by: Paolo Bonzini
---
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
+++ b/hw/scsi-bus.c
@@ -1072,6 +107
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
---
hw/scsi-bus.c | 52 ++
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
---
hw/scsi-bus.c |5 +
hw/scsi-disk.c | 15 +++
hw/scsi.h |2 ++
3 files changed, 18 insertions(+), 4 deletions(-)
di
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
---
hw/scsi-disk.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
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 fo
All currently defined event structs have the same fields. Simplify the
driver by enforcing this also for future structs.
Signed-off-by: Paolo Bonzini
---
virtio-spec.lyx | 69 +++
1 file changed, 65 insertions(+), 4 deletions(-)
diff --git
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 SCSI
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
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
--
On Thu, Jul 12, 2012 at 7:35 AM, 김민규 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 same CPU.
> +
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:
> >> > >>
> >> > >> >
On Sun, 2012-07-15 at 11:33 +0300, Avi Kivity wrote:
> On 07/12/2012 07:19 PM, 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 KVM device assignment to provide fast-path INTx
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 somebo
On Thu, Jul 12, 2012 at 4:35 PM, Asias He wrote:
> This patchset adds vhost-blk support. vhost-blk is a in kernel virito-blk
> device accelerator. Compared to userspace virtio-blk implementation, vhost-blk
> gives about 5% to 15% performance improvement.
Why is it 5-15% faster? vhost-blk and the
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 u
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 reques
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: [] tid_fd_revalidate+0x84/0x1a0
PGD 66989
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 i
On 07/16/2012 11:25 AM, Raghavendra K T wrote:
> From: Raghavendra K T
>
> 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
On 07/16/2012 11:25 AM, Raghavendra K T wrote:
> From: Raghavendra K T
>
> 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
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.
--
* Michael S. Tsirkin 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 will take pla
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 t
From: Raghavendra K T
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.
The patchset keeps track of the
From: Raghavendra K T
Suggested-by: Avi Kivity
Signed-off-by: Raghavendra K T
---
arch/s390/kvm/Kconfig |1 +
arch/x86/kvm/Kconfig |1 +
virt/kvm/Kconfig |3 +++
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig
index
From: Raghavendra K T
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.
Signed-off-by: Raghavendra K T
---
V2 was:
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
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
70 matches
Mail list logo
