On 02/21/2010 07:23 PM, Chris Webb wrote:
Some sort of race where a client disconnects and is removed from the client
list while the vnc_refresh() loop is iterating over it, maybe?
Looks like c727a05459, and high time for 0.12.3. Anthony?
--
error compiling committee.c: too many
On 02/21/2010 03:00 PM, Gleb Natapov wrote:
vcpu-run is initialized on vcpu creation and can never be NULL
here.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 02/18/2010 12:14 AM, Marcelo Tosatti wrote:
See individual patches for details.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
Hi Lucas
Thanks for your comments! I am sorry for replying your email so late!
A new patch will be sent out according to your comments.
Best Regards
Feng Yang
- Lucas Meneghel Rodrigues l...@redhat.com wrote:
From: Lucas Meneghel Rodrigues l...@redhat.com
To: Feng Yang fy...@redhat.com
Signed-off-by: Feng Yang fy...@redhat.com
---
client/tests/kvm/scripts/check_image.py | 85 +++
client/tests/kvm/tests_base.cfg.sample |4 ++
2 files changed, 89 insertions(+), 0 deletions(-)
create mode 100755 client/tests/kvm/scripts/check_image.py
diff
On 02/18/2010 06:13 PM, Jan Kiszka wrote:
Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
under QEMU as it enforces protection, keep them in spare vectors of the
interrupt table, namely INT 0x80 and 0x81.
Applied both, thanks.
Don't forget to update extboot.bin
Avi Kivity wrote:
On 02/18/2010 06:13 PM, Jan Kiszka wrote:
Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
under QEMU as it enforces protection, keep them in spare vectors of the
interrupt table, namely INT 0x80 and 0x81.
Applied both, thanks.
Don't forget
Current status of gPXE virtio support:
Virtio-net support has been in mainline gPXE since August 2008.
Virtio-blk patches exist and I'd like to get them merged so both types
of devices are supported.
These are PCI option ROMs and they have a BEV entry point to hook into
the boot menu. With
Jan Kiszka wrote:
Avi Kivity wrote:
On 02/18/2010 06:13 PM, Jan Kiszka wrote:
Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
under QEMU as it enforces protection, keep them in spare vectors of the
interrupt table, namely INT 0x80 and 0x81.
Applied both, thanks.
Hi Avi,
forgot this one? I did not find it in your tree.
Joerg
On Fri, Feb 19, 2010 at 04:23:01PM +0100, Joerg Roedel wrote:
The nested_svm_intr() function does not execute the vmexit
anymore. Therefore we may still be in the nested state after
that function ran. This patch changes the
On 02/22/2010 11:59 AM, Jan Kiszka wrote:
We don't carry a precompiled binary (well, we have
qemu/pc-bios/extboot.bin, but that's bogus and I've removed it).
You do:
qemu-kvm/qemu/pc-bios/extboot.bin (what is that for?)
Artifact, removed.
And as I had to copy the built
On 02/22/2010 12:29 PM, Joerg Roedel wrote:
Hi Avi,
forgot this one? I did not find it in your tree.
Whoops, dropped it accidentally. Thanks for checking. Applied now.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line
On 02/21/2010 03:21 PM, jer wrote:
Hello,
The 1920x1080 aka Full HD resolution has become standard on many displays so it
was lacking for me and other kvm users so I have added it to the vbe table.
Could you merge it so it can become available to everyone ?
Please repost with a
Hello,
The 1920x1080 (aka Full HD) resolution has become standard on many displays and
was lacking. This patch adds this resolution to the vbe table.
Signed-off-by: Jérôme Marty jerome.ma...@laposte.net
--
patch
Description: Binary data
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: qemu/kvm-all.c
===
--- qemu.orig/kvm-all.c
+++ qemu/kvm-all.c
@@ -718,6 +718,9 @@ static int kvm_handle_io(uint16_t port,
return
On 02/22/2010 03:59 PM, Marcelo Tosatti wrote:
VIRTIO_PCI_QUEUE_NOTIFY is used to inform availability of new buffers,
so wakeup the iothread to process that information immediately.
Reported-by: Amit Shahamit.s...@redhat.com
Signed-off-by: Marcelo Tosattimtosa...@redhat.com
Index:
On 02/22/2010 03:59 PM, Marcelo Tosatti wrote:
Cc: Michael S. Tsirkinm...@redhat.com
Signed-off-by: Marcelo Tosattimtosa...@redhat.com
Index: qemu/kvm-all.c
===
--- qemu.orig/kvm-all.c
+++ qemu/kvm-all.c
@@ -718,6 +718,9 @@ static
(forgot to CC list on my last reply)
2010/2/22 raincatsd...@me.com:
I followed the tutorial How to assign devices with KVM VT-d.
Giving the command dmesg | grep-e-e dmar IOMMU prompt does not return
anything!
Ok, if dmesg | grep -e DMAR -e IOMMU doesn't give you any output,
it doesn't make
On Mon, Feb 22, 2010 at 04:23:32PM +0200, Avi Kivity wrote:
On 02/22/2010 03:59 PM, Marcelo Tosatti wrote:
Cc: Michael S. Tsirkinm...@redhat.com
Signed-off-by: Marcelo Tosattimtosa...@redhat.com
Index: qemu/kvm-all.c
===
---
On Mon, Feb 22, 2010 at 04:20:52PM +0200, Avi Kivity wrote:
On 02/22/2010 03:59 PM, Marcelo Tosatti wrote:
VIRTIO_PCI_QUEUE_NOTIFY is used to inform availability of new buffers,
so wakeup the iothread to process that information immediately.
Reported-by: Amit Shahamit.s...@redhat.com
On Mon, Feb 22, 2010 at 10:59:08AM -0300, Marcelo Tosatti wrote:
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
We'll need implementation for other arches, I'll dust off
my patch that adds it and repost,
On 02/22/2010 04:29 PM, Marcelo Tosatti wrote:
On Mon, Feb 22, 2010 at 04:20:52PM +0200, Avi Kivity wrote:
On 02/22/2010 03:59 PM, Marcelo Tosatti wrote:
VIRTIO_PCI_QUEUE_NOTIFY is used to inform availability of new buffers,
so wakeup the iothread to process that information
On 02/22/2010 04:45 PM, Marcelo Tosatti wrote:
On Mon, Feb 22, 2010 at 04:23:32PM +0200, Avi Kivity wrote:
On 02/22/2010 03:59 PM, Marcelo Tosatti wrote:
Cc: Michael S. Tsirkinm...@redhat.com
Signed-off-by: Marcelo Tosattimtosa...@redhat.com
Index: qemu/kvm-all.c
On Mon, Feb 22, 2010 at 04:57:29PM +0200, Avi Kivity wrote:
On 02/22/2010 04:45 PM, Marcelo Tosatti wrote:
On Mon, Feb 22, 2010 at 04:23:32PM +0200, Avi Kivity wrote:
On 02/22/2010 03:59 PM, Marcelo Tosatti wrote:
Cc: Michael S. Tsirkinm...@redhat.com
Signed-off-by: Marcelo
On 02/22/2010 04:57 PM, Michael S. Tsirkin wrote:
There is no need (for this case). Older read cannot be reordered with
write, writes are not reordered with other writes, writes by a single
processor are observed in the same order by all processors.
Well, Linux does use sfence.
On Mon, Feb 22, 2010 at 05:08:00PM +0200, Avi Kivity wrote:
On 02/22/2010 04:57 PM, Michael S. Tsirkin wrote:
There is no need (for this case). Older read cannot be reordered with
write, writes are not reordered with other writes, writes by a single
processor are observed in the same
On Mon, Feb 22, 2010 at 04:51:46PM +0200, Avi Kivity wrote:
On 02/22/2010 04:29 PM, Marcelo Tosatti wrote:
On Mon, Feb 22, 2010 at 04:20:52PM +0200, Avi Kivity wrote:
On 02/22/2010 03:59 PM, Marcelo Tosatti wrote:
VIRTIO_PCI_QUEUE_NOTIFY is used to inform availability of new buffers,
so
On 02/22/2010 05:08 PM, Michael S. Tsirkin wrote:
I imagine all arches need an instruction. For reads as well.
Note, gcc has a __sync_synchronize() builtin that compiles to mfence on
x86. We might use that as a baseline for both rmb and wmb, and let each
arch override it incrementally.
On 02/22/2010 09:16 AM, Marcelo Tosatti wrote:
Are you concerned about spurious wakeups?
Yes. Also, qemu_notify_event() is an undirected notification (wakes
up all iothreads, and all devices), whereas -handle_output() is
directed (wakes up exactly what is needed).
What's the
On 02/22/2010 05:29 PM, Anthony Liguori wrote:
On 02/22/2010 09:16 AM, Marcelo Tosatti wrote:
Are you concerned about spurious wakeups?
Yes. Also, qemu_notify_event() is an undirected notification (wakes
up all iothreads, and all devices), whereas -handle_output() is
directed (wakes up
On 02/22/2010 09:32 AM, Avi Kivity wrote:
On 02/22/2010 05:29 PM, Anthony Liguori wrote:
On 02/22/2010 09:16 AM, Marcelo Tosatti wrote:
Are you concerned about spurious wakeups?
Yes. Also, qemu_notify_event() is an undirected notification (wakes
up all iothreads, and all devices), whereas
While converting the kzalloc we used to allocate our vcpu struct to
vmalloc, I forgot to memset the contents to zeros. That broke quite
a lot.
This patch memsets it to zero again.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/book3s.c |1 +
1 files changed, 1
When we destory a vcpu, we should also make sure to kill all pending
timers that could still be up. When not doing this, hrtimers might
dereference null pointers trying to call our code.
This patch fixes spontanious kernel panics seen after closing VMs.
Signed-off-by: Alexander Graf
On 02/22/2010 05:42 PM, Anthony Liguori wrote:
Spurious calls to qemu_notify_event() also make it difficult to tell
when it's actually necessary to call qemu_notify_event() vs. when
it's just something that doesn't hurt.
One improvement in this area would be to add a context parameter
(which
On 02/19/2010 04:47 AM, Mark Cave-Ayland wrote:
sati...@pacific.net.hk wrote:
Hi folks
KVM
Host - Fedora 12 64bit
VM (guest) - Windows Server 2008 64bit
Fail to attach CDWriter.
$ sudo virsh -c qemu:///system start vm06_wser08
Domain vm06_wser08 started
$ cat VM/DEV/cd.xml
disk
On 02/21/2010 02:10 AM, Joerg Roedel wrote:
On Sat, Feb 20, 2010 at 01:26:49PM -1000, Zachary Amsden wrote:
The infrastructure is already there to import / export and migrate MSR
settings. MSRs are also 64-bit, and hold model-specific settings, so
if you don't mind thinking of the nested
On 02/21/2010 02:24 AM, Avi Kivity wrote:
On 02/21/2010 02:10 PM, Joerg Roedel wrote:
It is doable but I still think its
complicated to get this right. The simplest approach would be to
disallow migration when the vcpu is running in guest mode.
Agree, though I dislike the need to introduce a
On 02/22/2010 06:42 PM, Zachary Amsden wrote:
On 02/21/2010 02:24 AM, Avi Kivity wrote:
On 02/21/2010 02:10 PM, Joerg Roedel wrote:
It is doable but I still think its
complicated to get this right. The simplest approach would be to
disallow migration when the vcpu is running in guest mode.
On 02/21/2010 03:09 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 02:54:01PM +0200, Avi Kivity wrote:
So, if some other cpu (or the guest itself, with appropriate
permissions) modifies the msr permission bitmap, svm will not notice
this? svm loads the bitmap during entry?
Yes.
On 02/21/2010 04:43 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 03:40:55PM +0200, Avi Kivity wrote:
On 02/21/2010 03:14 PM, Avi Kivity wrote:
(Either synthetic msrs, or an new state ioctl). The state would
contain a bit that says whether the guest is in guest or host mode.
On 02/21/2010 05:56 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 05:07:45PM +0200, Avi Kivity wrote:
On 02/21/2010 04:43 PM, Joerg Roedel wrote:
Difficult. We could use an instruction intercept which has no side
effect on guest state (invlpg for example).
Especially as
Acked-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: qemu/kvm-all.c
===
--- qemu.orig/kvm-all.c
+++ qemu/kvm-all.c
@@ -21,6 +21,7 @@
#include linux/kvm.h
#include qemu-common.h
On 02/22/2010 06:56 PM, Zachary Amsden wrote:
In the SVM case this still leaves the problem that the MSR bitmap must
be read again from guests memory on unfreeze but that is not a real
problem.
This is easily solved by shadowing the MSR bitmap. Too bad we have to
do it, but at least the
On 02/22/2010 06:44 AM, Avi Kivity wrote:
On 02/22/2010 06:42 PM, Zachary Amsden wrote:
On 02/21/2010 02:24 AM, Avi Kivity wrote:
On 02/21/2010 02:10 PM, Joerg Roedel wrote:
It is doable but I still think its
complicated to get this right. The simplest approach would be to
disallow migration
On 02/22/2010 07:00 PM, Zachary Amsden wrote:
The force vmexit would generate an INTR #vmexit even if the INTR
intercept was disabled and even if no INTR is pending. However this
was shot down since there was no equivalent vmx exit reason that we
can except the guest to reasonably handle.
On 02/22/2010 06:57 PM, Marcelo Tosatti wrote:
Acked-by: Michael S. Tsirkinm...@redhat.com
Signed-off-by: Marcelo Tosattimtosa...@redhat.com
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
On 02/22/2010 07:02 AM, Avi Kivity wrote:
On 02/22/2010 07:00 PM, Zachary Amsden wrote:
The force vmexit would generate an INTR #vmexit even if the INTR
intercept was disabled and even if no INTR is pending. However this
was shot down since there was no equivalent vmx exit reason that we
can
On Mon, Feb 22, 2010 at 06:46:19AM -1000, Zachary Amsden wrote:
On 02/21/2010 03:09 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 02:54:01PM +0200, Avi Kivity wrote:
So, if some other cpu (or the guest itself, with appropriate
permissions) modifies the msr permission bitmap, svm will not
On 02/22/2010 07:07 PM, Zachary Amsden wrote:
On 02/22/2010 07:02 AM, Avi Kivity wrote:
On 02/22/2010 07:00 PM, Zachary Amsden wrote:
The force vmexit would generate an INTR #vmexit even if the INTR
intercept was disabled and even if no INTR is pending. However
this was shot down since there
On 02/22/2010 07:11 AM, Avi Kivity wrote:
On 02/22/2010 07:07 PM, Zachary Amsden wrote:
On 02/22/2010 07:02 AM, Avi Kivity wrote:
On 02/22/2010 07:00 PM, Zachary Amsden wrote:
The force vmexit would generate an INTR #vmexit even if the INTR
intercept was disabled and even if no INTR is
Support both guest- as well as host-owned EFLAGS.TF while emulating
instructions. For guest-owned TF, we simply inject DB and update DR6.BS
after completing an instruction that has TF set on entry. To support
guest single-stepping under host control, we store the pending step
along with its CS and
Call directly into the vendor services for getting/setting rflags in
emulate_instruction to ensure injected TF survives the emulation.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/x86.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
We intercept #BP while in guest debugging mode. As VM exits due to
intercepted exceptions do not necessarily come with valid
idt_vectoring, we have to update event_exit_inst_len explicitly in such
cases. At least in the absence of migration, this ensures that
re-injections of #BP will find and use
When in guest debugging mode, we have to reinject those #BP software
exceptions that are caused by guest-injected INT3. As older AMD
processors to not support the required nRIP VMCB field, try to emulate
it by moving RIP by one on injection. Fix it up again in case the
injection failed and we were
RF is not required for injecting TF as the latter will trigger only
after an instruction execution anyway. So do not touch RF when arming or
disarming guest single-step mode.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/x86.c |4 ++--
1 files changed, 2 insertions(+), 2
This marks the guest single-step API improvement of 94fe45da and
91586a3b with a capability flag to allow reliable detection by user
space.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/x86.c |1 +
include/linux/kvm.h |1 +
2 files changed, 2 insertions(+), 0
Patch 12 are well-known, but I think no longer disputed. Patch 3 was
requested by Avi while merging some qemu-kvm bits of mine, it should be
pushed into 2.6.33 as well. And the other patches came out of my attempt
to step over some APIC MMIO access of a guest.
So far my stable bits, the rest is
This is my motherboard:
http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01324212lc=encc=cadlc=enproduct=3691066
The virtualization technology is enabled from bios and KVM (not QEMU) virtual
machine work correctly!
1. Your hardware (your chipset) doesn't support VT-d
During the
Avi Kivity a...@redhat.com writes:
On 02/21/2010 07:23 PM, Chris Webb wrote:
Some sort of race where a client disconnects and is removed from the client
list while the vnc_refresh() loop is iterating over it, maybe?
Looks like c727a05459, and high time for 0.12.3. Anthony?
Ah yes, looks
* raincatsd...@me.com (raincatsd...@me.com) wrote:
This is my motherboard:
http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01324212lc=encc=cadlc=enproduct=3691066
The virtualization technology is enabled from bios and KVM (not QEMU) virtual
machine work correctly!
VT-x is needed for
On 02/22/2010 02:03 AM, Stefan Hajnoczi wrote:
These are PCI option ROMs and they have a BEV entry point to hook into
the boot menu. With SeaBIOS BBS and PMM support the gPXE ROMs can
provide your virtio support.
Typically a disk device would use a BCV, not a BEV.
-hpa
--
To
This is an implementation of KSM testing. The basic idea behind the
test is to start guests, copy the script allocator.py to them. Once
executed, the process accepts input commands on its main loop.
The script will allow to fill up memory pages of the guests, according
to patterns, this way it's
Le 22/02/2010 06:40, Nikola Ciprich a écrit :
Hi Gilles, maybe You have the same problem I experienced?
see http://www.mail-archive.com/kvm@vger.kernel.org/msg28572.html
nik
Hi,
The linux headers do include the MADV_MERGEABLE settings, and the libc
is the debian one which happened to work
Change the way the internal qemu signal, used for communication between
iothread and vcpus, is handled.
Block and consume it with sigtimedwait on the outer vcpu loop, which
allows more precise timing control.
Change from standard signal (SIGUSR1) to real-time one, so multiple
signals are not
The following changes since commit bf76bafa5ade434ef2747caa95510ecb7946:
Edgar E. Iglesias (1):
crisv10: Prettify.
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master
Jan Kiszka (1):
kvm: Fix eflags corruption in kvm mode
In KVM mode the global mutex is released when vcpus are executing,
which means acquiring the fairness mutex is not required.
Also for KVM there is one thread per vcpu, so tcg_has_work is meaningless.
Add a new qemu_wait_io_event_common function to hold common code
between TCG/KVM.
From: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
---
osdep.c | 32
qemu-common.h |1 +
vl.c |9 +
3 files changed, 38 insertions(+), 4 deletions(-)
On 02/22/2010 02:54 AM, Avi Kivity wrote:
On 02/21/2010 07:23 PM, Chris Webb wrote:
Some sort of race where a client disconnects and is removed from the
client
list while the vnc_refresh() loop is iterating over it, maybe?
Looks like c727a05459, and high time for 0.12.3. Anthony?
Indeed.
On 02/22/2010 03:26 PM, Marcelo Tosatti wrote:
The following changes since commit bf76bafa5ade434ef2747caa95510ecb7946:
Edgar E. Iglesias (1):
crisv10: Prettify.
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master
Jan Kiszka
2010/2/22 Chris Wright chr...@sous-sol.org:
* raincatsd...@me.com (raincatsd...@me.com) wrote:
This is my motherboard:
http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01324212lc=encc=cadlc=enproduct=3691066
The virtualization technology is enabled from bios and KVM (not QEMU)
virtual
Please send in any agenda items you are interested in covering.
thanks,
-chris
--
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
* Kenni Lund (ke...@kelu.dk) wrote:
I've updated the KVM VT-d wikipage with a short section on VT-d support.
Nice, thank you Kenni.
thanks,
-chris
--
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
Thank you really for availability!
Now I realize that my solution is wrong because of my ignorance (VT-x and VT-d).
Practically there is another solution to communicate with a PCI card with a
virtual machine? Or should I completely change the system?
Thank you again, after reading the wikipage
2010/2/23 Paolo Rivetti raincatsd...@me.com:
Now I realize that my solution is wrong because of my ignorance (VT-x and
VT-d).
Practically there is another solution to communicate with a PCI card with a
virtual machine? Or should I completely change the system?
If you want to use KVM you'll
Bugs item #2929111, was opened at 2010-01-10 04:48
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2929111group_id=180599
Please note that this message will contain a full copy of the comment
Bugs item #2924683, was opened at 2010-01-01 21:53
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2924683group_id=180599
Please note that this message will contain a full copy of the comment
Bugs item #2793994, was opened at 2009-05-19 17:52
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2793994group_id=180599
Please note that this message will contain a full copy of the comment
Bugs item #2944508, was opened at 2010-02-02 09:46
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2944508group_id=180599
Please note that this message will contain a full copy of the comment
Add copying the keyval of guest test into client results so that server can
get it in autotest case.
Signed-off-by: sshang ssh...@redhat.com
---
client/tests/kvm/tests/autotest.py |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/tests/autotest.py
79 matches
Mail list logo
