Am Freitag, 9. November 2007 20:42 schrieb Izik Eidus:
> i hope i am not asking too much, but can you please try to completely
> install and run the installtion with -no-kvm?
> (another thing i want you to check is what the effect of -no-kvm-irqchip
> when runing with kvm enabled (it might fix som
Werner Opriel wrote:
> Am Freitag, 9. November 2007 20:42 schrieb Izik Eidus:
>
>
>> i hope i am not asking too much, but can you please try to completely
>> install and run the installtion with -no-kvm?
>> (another thing i want you to check is what the effect of -no-kvm-irqchip
>> when runing w
Am Samstag, 10. November 2007 15:05 schrieb Izik Eidus:
> ok, please try out -no-kvm-irqchip, and if this isnt helping
> you might checkout kvm-36 and report what happen there
> (in this days we are doing some serioes work to improved greatly the amd
> support)
With kvm-51 and pressing F7 to use
Am Samstag, 10. November 2007 15:05 schrieb Izik Eidus:
>
> ok, please try out -no-kvm-irqchip, and if this isnt helping
> you might checkout kvm-36 and report what happen there
> (in this days we are doing some serioes work to improved greatly the amd
> support)
With kvm-36 and pressing F7 to use
Werner Opriel wrote:
> Am Samstag, 10. November 2007 15:05 schrieb Izik Eidus:
>
>> ok, please try out -no-kvm-irqchip, and if this isnt helping
>> you might checkout kvm-36 and report what happen there
>> (in this days we are doing some serioes work to improved greatly the amd
>> support)
>>
It appears the qemu in KVM-51 has a weird glitch where it will ignore
the '-m' memory parameter if it's the first parameter on the command
line (the case 'QEMU_OPTION_m' stanza never gets called in
qemu/hw/vl.c:main()). A quick look at the code doesn't reveal anything
obvious to me as to why. Put
Bugs item #1829614, was opened at 2007-11-10 21:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1829614&group_id=180599
Please note that this message will contain a full copy
Take 5 min out this will make you feel better. http://200.86.203.137/
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files us
Carlo Marcelo Arenas Belon wrote:
On Sat, Nov 10, 2007 at 12:35:34AM +0200, Dor Laor wrote:
Carlo Marcelo Arenas Belon wrote:
wrong patch, this was meant to go to the slave PIC, so it will use s->pics[1]
instead of s->pics[0].
Why to the slave pic? Isn't the pit connected to line 0
On Sat, Nov 10, 2007 at 01:22:06PM -0500, John Clemens wrote:
> It appears the qemu in KVM-51 has a weird glitch where it will ignore
> the '-m' memory parameter if it's the first parameter on the command
> line (the case 'QEMU_OPTION_m' stanza never gets called in
> qemu/hw/vl.c:main()). A quick
Aww..crap.
Please disregard.. I was running under 'vdeq', and it looks like vdeq is
eating the '-m' argument for itself iff it's the first argument on the
qemu command line.
As you can see, when running under vdeq (and some extra debugging
printf's added):
$ sudo vdeq ./qemu-system-x86_64 -m 5
This patch series implements QEMU support for PCI based virtio devices. The
series also updates the kvm-userspace tree to have the ability to build virtio
devices as modules from an external tree (just as we do with the kvm modules).
There's still some notable TODO's left so it's not mergable in
This patch implements a very simple virtio transport for 9p in QEMU. The
kernel side of this is going to change dramatically in the very near future so
this is just a demonstration for the moment. It requires an external 9p file
server and communicates with it over a TCP port. In future versions
This patch implements a very naive virtio network device backend in QEMU.
Even with this simple implementation, it get's about 3x the throughput of
rtl8139. Of course, there's a whole lot of room for optimization to eliminate
the unnecessary copying and support more advanced features.
To use a vi
This patch implements a very naive virtio block device backend in QEMU.
There's a lot of room for future optimization. We need to merge a -disk patch
before we can provide a mechanism to expose this to users.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/Makefile.target b/
I don't think there's any plans for this driver to every be used seriously as
virtio seems like the agreed upon layer. So let's remove the code from the
tree so I can use the drivers/ directory for something else.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/Kbuild b/d
This provides a make sync within the drivers/ directory to allow virtio drivers
to be built as third-party modules much as we do with the KVM driver.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/.gitignore b/.gitignore
index 600508a..f9b95f8 100644
--- a/.gitignore
+++ b/.gitig
This implements the basic virtio and virtio_ring infrastructure for QEMU. It's
designed at the moment with intimate knowledge of the virtio_pci device. In
the future, we may want to abstract that a little further so that the virtio
backend device doesn't have any knowledge of the virtio transport
The following patch applies to kvm-51 and correct all compilation warnings
because of mismatching types for ram related variables and that were left
behind after the changes to add support for more than 2GB of memory for 32bit
guests.
a more complete patchset will be needed for doing the same chan
This fix was cherry picked from the qemu CVS via
cvs diff -r1.21 -r1.22 qemu-img.c
Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]>
---
qemu/qemu-img.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/qemu/qemu-img.c b/qemu/qemu-img.c
index d021082..b84b75b 10
20 matches
Mail list logo
