On Tue, 2009-07-21 at 14:42 +0200, Kevin Wolf wrote:
Ram Pai schrieb:
Problem: It is impossible to feed filenames with the character colon because
qemu interprets such names as a protocol. For example filename scsi:0, is
interpreted as a protocol by name scsi.
This patch allows user to
Problem: It is impossible to feed filenames with the character colon because
qemu interprets such names as a protocol. For example filename scsi:0, is
interpreted as a protocol by name scsi.
This patch allows user to espace colon characters. For example the above
filename can now be expressed
On 06/30/2009 01:54 PM, Amit Shah wrote:
We ignore writes to the perfctr msrs. Ignore reads as well.
Kaspersky antivirus crashes Windows guests if it can't read
these MSRs.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list:
It was broken by commit 55b23c7377c9f9f0b4a4b90950f0e18b26ac45e8.
APIC_ID is handled by default clause anyway so remove the special
handling.
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 6c3cd2c..fdddf48 100644
---
On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
(Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
These are guest drivers, right? Merging the guest first means relying on
kernel interface from an out of tree driver, which well might change
before it goes
On Sun, 02 Aug 2009 19:32:02 +0300, Avi Kivity wrote:
Paralleling the qemu upstream 0.11 release cycle, qemu-kvm-0.11.0-rc1 is
now available. qemu-kvm-0.11.0-rc1 can be used with kvm kernel modules
from your distribution kernel, or with the modules provided by the
kvm-kmod package.
Please
On 08/06/2009 11:07 AM, Gleb Natapov wrote:
It was broken by commit 55b23c7377c9f9f0b4a4b90950f0e18b26ac45e8.
APIC_ID is handled by default clause anyway so remove the special
handling.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe
On 08/05/2009 09:47 PM, Michael Goldish wrote:
I can find out if the parent process is alive by checking a lock file.
A little while ago I couldn't afford to do that in is_alive() because
it would cause a deadlock, but now this shouldn't be a problem.
I'll test it and if it works it'll greatly
On (Wed) Aug 05 2009 [18:57:13], Jamie Lokier wrote:
Anthony Liguori wrote:
Richard W.M. Jones wrote:
Have you considered using a usb serial device? Something attractive
about it is that a productid/vendorid can be specified which means that
you can use that as a method of enumerating
On (Wed) Aug 05 2009 [13:00:57], Anthony Liguori wrote:
Jamie Lokier wrote:
Anthony Liguori wrote:
Richard W.M. Jones wrote:
Have you considered using a usb serial device? Something attractive
about it is that a productid/vendorid can be specified which means
that you can use that as
- Avi Kivity a...@redhat.com wrote:
On 08/05/2009 09:47 PM, Michael Goldish wrote:
I can find out if the parent process is alive by checking a lock
file.
A little while ago I couldn't afford to do that in is_alive()
because
it would cause a deadlock, but now this shouldn't be a
On Thu, Aug 6, 2009 at 2:41 AM, sudhir kumarsmalik...@gmail.com wrote:
Lets not make it a python script. Since the purpose of providing this
script is that the user can copy it to /etc also and not bother
updating it to kvm_tests.cfg, so let us keep it bash only. Also as
Michael pointed there
On 8/6/2009 at 6:17 AM, in message 20090806101702.ga10...@redhat.com,
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Aug 06, 2009 at 11:19:56AM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
(Applies to v2.6.31-rc5, proposed for
On 08/06/2009 03:08 PM, Gregory Haskins wrote:
Merging the guest first means relying on
kernel interface from an out of tree driver, which well might change
before it goes in.
ABI compatibility is already addressed/handled, so even if that is true its not
a problem.
Really the
On 8/6/2009 at 8:24 AM, in message 20090806122449.gc11...@redhat.com,
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Aug 06, 2009 at 06:08:27AM -0600, Gregory Haskins wrote:
Hi Michael,
On 8/6/2009 at 4:19 AM, in message 20090806081955.ga9...@redhat.com,
Michael S. Tsirkin
On 8/6/2009 at 8:54 AM, in message 4a7ad29e.50...@redhat.com, Avi Kivity
a...@redhat.com wrote:
On 08/06/2009 03:08 PM, Gregory Haskins wrote:
Merging the guest first means relying on
kernel interface from an out of tree driver, which well might change
before it goes in.
ABI
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
There certainly is from me. The userspace interface is not reasonable
for guest applications to use.
Regards,
Anthony Liguori
On 08/06/2009 04:03 PM, Gregory Haskins wrote:
It's true that vbus is a separate project (in fact even virtio is
completely separate from kvm). Still I think it would be of interest to
many kvm@ readers.
Well, my goal was to not annoy KVM readers. ;) So if you feel as though there
is
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
There certainly is from me. The userspace interface is not reasonable
for
On 8/6/2009 at 9:44 AM, in message 4a7ade23.5010...@redhat.com, Avi
Kivity
a...@redhat.com wrote:
On 08/06/2009 04:03 PM, Gregory Haskins wrote:
It's true that vbus is a separate project (in fact even virtio is
completely separate from kvm). Still I think it would be of interest to
many
On 08/06/2009 04:45 PM, Gregory Haskins wrote:
(though still rooting for virtio).
Heh...not to belabor the point to death, but virtio is orthogonal (you keep
forgetting that ;).
Its really the vbus device-model vs the qemu device-model (and possibly vs the
in-kernel pci emulation
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
There certainly is from me. The userspace
On Thu, Aug 06, 2009 at 07:45:30AM -0600, Gregory Haskins wrote:
(though still rooting for virtio).
Heh...not to belabor the point to death, but virtio is orthogonal (you keep
forgetting that ;).
venet and virtio aren't orthogonal, are they?
--
MST
--
To unsubscribe from this list: send
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
On 8/6/2009 at 9:57 AM, in message 4a7ae150.7040...@redhat.com, Avi
Kivity
a...@redhat.com wrote:
On 08/06/2009 04:45 PM, Gregory Haskins wrote:
(though still rooting for virtio).
Heh...not to belabor the point to death, but virtio is orthogonal (you keep
forgetting that ;).
On 8/6/2009 at 9:59 AM, in message 20090806135903.ga11...@redhat.com,
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Aug 06, 2009 at 07:45:30AM -0600, Gregory Haskins wrote:
(though still rooting for virtio).
Heh...not to belabor the point to death, but virtio is orthogonal (you keep
On Thursday 06 August 2009, Gregory Haskins wrote:
We can exchange out the virtio-pci module like this:
(guest-side)
|--
| virtio-net
|--
| virtio-ring
|--
| virtio-bus
|--
| virtio-vbus
On 08/06/2009 06:40 PM, Arnd Bergmann wrote:
3. The ioq method seems to be the real core of your work that makes
venet perform better than virtio-net with its virtqueues. I don't see
any reason to doubt that your claim is correct. My conclusion from
this would be to add support for ioq to virtio
On Thu, Aug 06, 2009 at 05:40:04PM +0200, Arnd Bergmann wrote:
3. The ioq method seems to be the real core of your work that makes
venet perform better than virtio-net with its virtqueues. I don't see
any reason to doubt that your claim is correct. My conclusion from
this would be to add
How hard would it be to implement virtio over vbus and perhaps the
virtio-net backend?
This would leave only one variable in the comparison, clear misconceptions and
make evaluation easier by judging each of vbus, venet etc separately on its own
merits.
The way things are now, it is unclear
On 8/6/2009 at 11:40 AM, in message 200908061740.04276.a...@arndb.de, Arnd
Bergmann a...@arndb.de wrote:
On Thursday 06 August 2009, Gregory Haskins wrote:
We can exchange out the virtio-pci module like this:
(guest-side)
|--
| virtio-net
Michael suggested to me a while ago to try MSI with virtio-blk and I
played with this small patch:
Index: qemu-kvm/hw/virtio-blk.c
===
--- qemu-kvm.orig/hw/virtio-blk.c
+++ qemu-kvm/hw/virtio-blk.c
@@ -416,6 +416,7 @@ VirtIODevice
On 8/6/2009 at 11:50 AM, in message 4a7afbe3.5080...@redhat.com, Avi
Kivity
a...@redhat.com wrote:
On 08/06/2009 06:40 PM, Arnd Bergmann wrote:
3. The ioq method seems to be the real core of your work that makes
venet perform better than virtio-net with its virtqueues. I don't see
any
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we
I found two mistakes (so far) in the TAP patchset:
- Two import lines in kvm_utils.py were commented out (for personal testing)
and I forgot to uncomment them before committing, and this breaks kvm_install
- qemu-ifup should be executable, but isn't
The following patches (1, 3, 11) replace the
Add function get_mac_ip_pair_from_dict() which gets a dict (specified in the
config file by the user) and fetches a MAC-IP address pair according to a
certain syntax. The syntax allows the user to specify a group of MAC-IP
address ranges. For example:
address_ranges = r1 r2 r3
The script adds a requested interface to an existing bridge. It is meant to be
used by qemu when running in TAP mode.
Note: the user is responsible for setting up the bridge before running any
tests. This can be done with brctl or in any manner that is appropriate for
the host OS. It can be
In VM.get_address(), return an IP address from the MAC-IP cache if an IP
address base wasn't specified by the user, or if the user requested that IP
addresses be taken from the dynamic cache.
To force the system to obtain IP addresses from the dynamic cache even when
static base addresses are
Hi all
I need some support here please!
I deploy two Dell Server, with Ubuntu 9.04, with KVM and I can not get
migration between this two machines
I try with virsh, using
migrate --live domain qemu +ssh://destdomain/system
but this not work properly...
I try migrate via qemu console too,
This doesn't speak directly to your live migration issue -- but
copy-and-pasting a libvirt-generated command line (as you're doing here)
and using it by hand is perilous.
As I mentioned when you asked in the IRC channel, you shouldn't be using
fd= here when starting kvm by hand -- it expects
On Thu, Aug 06, 2009 at 10:29:08AM -0600, Gregory Haskins wrote:
On 8/6/2009 at 11:40 AM, in message 200908061740.04276.a...@arndb.de,
Arnd
Bergmann a...@arndb.de wrote:
On Thursday 06 August 2009, Gregory Haskins wrote:
[ big snip ]
3. The ioq method seems to be the real core of
41 matches
Mail list logo
