On 10/27/2009 11:44 PM, Anthony Liguori wrote:
It's actually not okay. You're creating a bridge with two tap devices
on the bridge that happen to be connected in qemu by a vlan. If one
tap device receives a packet, qemu is going to forward that packet to
the other tap device, which will in
On 2009/10/21 14:13, MORITA Kazutaka wrote:
Hi everyone,
Sheepdog is a distributed storage system for KVM/QEMU. It provides
highly available block level storage volumes to VMs like Amazon EBS.
Sheepdog supports advanced volume management features such as snapshot,
cloning, and thin provisioning.
> Scott, Sven, if you could test the tap-drain-queue branch from
> my tree, that would be great:
> http://repo.or.cz/w/qemu/markmc.git
>
> Thanks,
> Mark.
Mark,
I've tested http://repo.or.cz/w/qemu/markmc.git and it indeed works for my test
case
(NFS through emulated smc91c111 NIC on
Hi， I am trying to construct a debug enviroment with qemu-sh4 and came
across a problem that looks like a qemu bug.
My step is:
1. compile a "hello" program for sh4
2. try to run "hello" with qemu-sh4, it’s ok
3. use cmd "qemu-sh4 -L /usr/sh4-unknown-linux-gnu -g 1234 ./hello" to
start qmeu . T
> Date: Tue, 27 Oct 2009 11:28:15 +0200
> From: Avi Kivity
> Subject: Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to
> start and stop VM
> On 10/27/2009 11:11 AM, Gerd Hoffmann wrote:
> > A qemu gui can easily hide that it actually uses vnc. The only thing
> > needed is a co
Beth Kon wrote:
Beth Kon wrote:
I accidentally entered a command line as follows:
/usr/bin/qemu-kvm -drive
file=/scratch/images/beth/windows/win2k3_32_R2.dat.10G.img,if=ide -m
2048 -boot cd -net nic,model=rtl8139 -net tap,script=/etc/qemu-ifup
-vnc :12 -usbdevice tablet -monitor stdio -net n
Beth Kon wrote:
I accidentally entered a command line as follows:
/usr/bin/qemu-kvm -drive
file=/scratch/images/beth/windows/win2k3_32_R2.dat.10G.img,if=ide -m
2048 -boot cd -net nic,model=rtl8139 -net tap,script=/etc/qemu-ifup
-vnc :12 -usbdevice tablet -monitor stdio -net nic,model=e1000 -n
> > The attached patch makes this configurable at compile-time.
>
> fwiw in scratchbox we have a wrapper in between binfmt and qemu (called
> misc_runner) that sets any
> necessary command line parameters for qemu. You might want to consider a
> similar approach so we
> don't need to add a confi
I accidentally entered a command line as follows:
/usr/bin/qemu-kvm -drive
file=/scratch/images/beth/windows/win2k3_32_R2.dat.10G.img,if=ide -m
2048 -boot cd -net nic,model=rtl8139 -net tap,script=/etc/qemu-ifup -vnc
:12 -usbdevice tablet -monitor stdio -net nic,model=e1000 -net
tap,script=/e
If qemu_send_packet_async() returns zero, it means the packet has been
queued and the sent callback will be invoked once it has been flushed.
This is only possible where the NIC's receive() handler returns zero
and promises to notify the networking core that room is available in its
queue again.
We should only return zero from receive() for a condition which we'll
get notification of when it changes. Currently, we're returning zero
if the guest driver is not ready, but we won't ever flush our queue
when that status changes.
Also, don't check buffer space in can_receive(), but instead just
Okay, let's try re-enabling the drain-entire-queue behaviour, with a
difference - before each subsequent packet, use qemu_can_send_packet()
to check that we can send it. This is similar to how we check before
polling the tap fd and avoids having to drop a packet if the receiver
cannot handle it.
T
If a receiver returns zero, that means its queue is full and it will
notify us when room is available using qemu_flush_queued_packets().
Take note of that and disable that receiver until it flushes its queue.
This is a first step towards allowing can_receive() handlers to return
true even if no b
Hey,
Scott points out that the current behaviour of draining the
entire queue in tap_send() doesn't work with non-virtio NICs because
we drop a packet when the NIC queue fills up.
This series of patches first disables this behaviour, fixes
various aspects of the queueing logic and
If qemu_send_packet_async() returns zero, it means the packet has been
queued and the sent callback will be invoked once it has been flushed.
This is only possible where the NIC's receive() handler returns zero
and promises to notify the networking core that room is available in its
queue again.
Now that we disable any receiver whose queue is full, we do not require
senders to handle a zero return by supplying a sent callback.
This is a second step towards allowing can_receive() handlers to return
true even if no buffer space is available.
Signed-off-by: Mark McLoughlin
---
net/queue.c
2009/10/27 Anthony Liguori :
> Artyom Tarasenko wrote:
>>
>> According to SCSI-2 specification,
>> http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2-08.html#8.2.5 ,
>> "if the allocation length of the command descriptor block (CDB) is too
>> small to transfer
>> all of the parameters, the additional leng
On Tue, 27 Oct 2009, Markus Armbruster wrote:
> We have code for a quite a few block formats. While I trust that all
> of these formats are useful at least for some people in some
> circumstances, some of them are of a kind that friends don't let
> friends use in production.
>
> This patch provi
Artyom Tarasenko wrote:
According to SCSI-2 specification,
http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2-08.html#8.2.5 ,
"if the allocation length of the command descriptor block (CDB) is too
small to transfer
all of the parameters, the additional length shall not be adjusted to
reflect the truncat
We have code for a quite a few block formats. While I trust that all
of these formats are useful at least for some people in some
circumstances, some of them are of a kind that friends don't let
friends use in production.
This patch provides an optional block format whitelist, default off.
If a w
On Tue, 27 Oct 2009, Markus Armbruster wrote:
> Mark McLoughlin writes:
>
> > On Thu, 2009-10-01 at 09:42 -0500, Justin M. Forbes wrote:
> >> Author: Justin M. Forbes
> >> Date: Thu Oct 1 09:34:56 2009 -0500
> >>
> >> Improve error reporting on file access
> >>
> >> By making th
Kevin Wolf schrieb:
> Am 27.10.2009 15:11, schrieb Anthony Liguori:
>
>> Stefan Weil wrote:
>>
>>> Images with disk size 0 may be used for
>>> VM snapshots, but not to save normal block data.
>>>
>>> It is possible to create such images using
>>> qemu-img, but opening them later fails.
>>>
Hi,
+/* The current Qemu infrastructure allows only for LUN 0 */
+if (lun == 0&& target< MAX_RAID_DEVS)
+ cmd->lun =&s->luns[target];
One more thing which should be fixed in qemu instead of worked around in
your driver. After all even good old parallel scsi knows multiple l
Mark McLoughlin writes:
> On Thu, 2009-10-01 at 09:42 -0500, Justin M. Forbes wrote:
>> Author: Justin M. Forbes
>> Date: Thu Oct 1 09:34:56 2009 -0500
>>
>> Improve error reporting on file access
>>
>> By making the error reporting include strerror(errno), it gives the user
>>
Hi,
The device can be accessed by
-drive if=raid,file=XXX
Don't extend that qemu automagic please. The new way to handle this is:
-drive if=none,id=mydisk,file=/path/to/some/disk.img
-device megasas,id=raid
-device scsi-disk,bus=raid.0,scsi-id=1,drive=mydisk
In order to support SC
Am 27.10.2009 15:11, schrieb Anthony Liguori:
> Stefan Weil wrote:
>> Images with disk size 0 may be used for
>> VM snapshots, but not to save normal block data.
>>
>> It is possible to create such images using
>> qemu-img, but opening them later fails.
>>
>> So even "qemu-img info image.qcow2" is
On 10/27/09 13:52, Markus Armbruster wrote:
These devices are created automatically, and attempting to create
another one with -device fails with "qemu: hardware error:
register_ioport_write: invalid opaque".
Signed-off-by: Markus Armbruster
Acked-by: Gerd Hoffmann
cheers,
Gerd
On Fri, Oct 23, 2009 at 12:50:03PM +0200, Boyapati, Anitha wrote:
> We have a proposal to add support for AVR32 target emulation in Qemu.
I've been working on and off on AVR32 target support for a little while
now. It's still far from being complete or mergeable, but enough of the
architecture ha
Other drives might want to use SCSI command emulation without
going through the SCSI disk abstraction, as this imposes too
many limits on the emulation.
Signed-off-by: Hannes Reinecke
---
block.c| 15 ++
block.h|3 +
block_int.h|1 +
hw/scsi-disk.c | 610 +
Now that we can use SCSI command emulation without using the SCSI
disk abstraction we can easily add it to the megasas HBA.
Signed-off-by: Hannes Reinecke
---
hw/megasas.c | 88 +++---
1 files changed, 53 insertions(+), 35 deletions(-)
diff
This patch add an emulation for the LSI MegaRAID SAS HBA. It is
using SG_IO to forward / pass through SCSI commands to the
underlying block driver, so no emulation is done currently.
Signed-off-by: Hannes Reinecke
---
Makefile.hw |2 +-
hw/megasas.c | 1134 +
This patch adds a 'raid' interface class. It is basically a clone
of the existing 'scsi' interface, only allowing up to 128 disks.
Signed-off-by: Hannes Reinecke
---
hw/pc.c |5 +
hw/pci-hotplug.c |1 +
hw/scsi-disk.c | 17 +
hw/scsi-disk.h | 20
Hi all,
this patchset implements an emulation for the megaraid_sas HBA.
It provides emulates an LSI MegaRAID SAS 8708EM2 HBA, ie
presenting to the guest a virtual SCSI adapter.
Internally it is using aio for read/write requests and
either SG_IO or SCSI command emulation for everything else.
The r
On Tue, Oct 27, 2009 at 04:05:25PM +0100, Màrius Montón wrote:
> Màrius Montón wrote:
> > Hello,
> >
> > For my PCI device to QEMU, I need the real address the PCI bus is using
> > to access my device. For a IO BAR (PCI_ADDRESS_SPACE_IO), I receive the
> > real address (like 0xc200 or similar), but
Màrius Montón wrote:
> Hello,
>
> For my PCI device to QEMU, I need the real address the PCI bus is using
> to access my device. For a IO BAR (PCI_ADDRESS_SPACE_IO), I receive the
> real address (like 0xc200 or similar), but when registering a
> PCI_ADDRESS_SPACE_MEM I only receive the offset to th
Am 27.10.2009 15:04, schrieb Anthony Liguori:
> Amit Shah wrote:
>> On (Tue) Oct 27 2009 [09:40:27], Kevin Wolf wrote:
>>
All that said, I'm ok with reverting that patch now till I find some
kind of a solution to this.
>>> Which patch do you want to revert? You're aware tha
On (Tue) Oct 27 2009 [09:04:50], Anthony Liguori wrote:
> Amit Shah wrote:
>> On (Tue) Oct 27 2009 [09:40:27], Kevin Wolf wrote:
>>
All that said, I'm ok with reverting that patch now till I find some
kind of a solution to this.
>>> Which patch do you want to revert? You're
Stefan Weil wrote:
Images with disk size 0 may be used for
VM snapshots, but not to save normal block data.
It is possible to create such images using
qemu-img, but opening them later fails.
So even "qemu-img info image.qcow2" is not
possible for an image created with
"qemu-img create -f qcow2
Amit Shah wrote:
On (Tue) Oct 27 2009 [09:40:27], Kevin Wolf wrote:
All that said, I'm ok with reverting that patch now till I find some
kind of a solution to this.
Which patch do you want to revert? You're aware that the qcow2 patch is
a data corruption fix?
Ah, no. Reverting
These devices are created automatically, and attempting to create
another one with -device fails with "qemu: hardware error:
register_ioport_write: invalid opaque".
Signed-off-by: Markus Armbruster
---
hw/fdc.c |1 +
hw/ide/piix.c |2 ++
2 files changed, 3 insertions(+), 0 deletions
On Tue, Oct 27, 2009 at 12:25:41PM +0200, Avi Kivity wrote:
> On 10/27/2009 12:19 PM, Glauber Costa wrote:
>> On Tue, Oct 27, 2009 at 12:01:59PM +0200, Avi Kivity wrote:
>>
>>> On 10/26/2009 08:26 PM, Glauber Costa wrote:
>>>
+
+kvm_msr_list = kvm_get_msr_list(env);
+
On 10/27/2009 12:19 PM, Glauber Costa wrote:
On Tue, Oct 27, 2009 at 12:01:59PM +0200, Avi Kivity wrote:
On 10/26/2009 08:26 PM, Glauber Costa wrote:
+
+kvm_msr_list = kvm_get_msr_list(env);
+if (!kvm_msr_list) {
+printf("FAILED\n");
+return -1;
+}
+
+m
On Tue, Oct 27, 2009 at 12:01:59PM +0200, Avi Kivity wrote:
> On 10/26/2009 08:26 PM, Glauber Costa wrote:
>> +
>> +kvm_msr_list = kvm_get_msr_list(env);
>> +if (!kvm_msr_list) {
>> +printf("FAILED\n");
>> +return -1;
>> +}
>> +
>> +msr_data.info.nmsrs = kvm_msr_list
On 10/26/2009 08:26 PM, Glauber Costa wrote:
+
+kvm_msr_list = kvm_get_msr_list(env);
+if (!kvm_msr_list) {
+printf("FAILED\n");
+return -1;
+}
+
+msr_data.info.nmsrs = kvm_msr_list->nmsrs;
+
+for (i = 0; i< kvm_msr_list->nmsrs; i++) {
+uint64_t *data
On 10/27/2009 11:11 AM, Gerd Hoffmann wrote:
On 10/26/09 17:08, Avi Kivity wrote:
A user starts a VM at a physical box. Everythings fine but he wants to
return to his workstation so he closes the window. He goes back to his
workstation and connects to a VNC server (on a different X server). He
w
On (Tue) Oct 27 2009 [09:40:27], Kevin Wolf wrote:
> >
> > All that said, I'm ok with reverting that patch now till I find some
> > kind of a solution to this.
>
> Which patch do you want to revert? You're aware that the qcow2 patch is
> a data corruption fix?
Ah, no. Reverting my patch that cau
On 10/26/09 17:08, Avi Kivity wrote:
A user starts a VM at a physical box. Everythings fine but he wants to
return to his workstation so he closes the window. He goes back to his
workstation and connects to a VNC server (on a different X server). He
wants to now bring up the guest's display.
Us
On Oct 27, 2009, at 11:00, ext Aurelien Jarno wrote:
> juha.riihim...@nokia.com a écrit :
>> On Oct 27, 2009, at 10:39, ext Aurelien Jarno wrote:
>>
>>> On Sat, Oct 24, 2009 at 03:19:04PM +0300, juha.riihim...@nokia.com
>>> wrote:
From: Juha Riihimäki
RM load/store multiple instruc
juha.riihim...@nokia.com a écrit :
> On Oct 27, 2009, at 10:39, ext Aurelien Jarno wrote:
>
>> On Sat, Oct 24, 2009 at 03:19:04PM +0300, juha.riihim...@nokia.com
>> wrote:
>>> From: Juha Riihimäki
>>>
>>> RM load/store multiple instructions can be slightly optimized by
>>> loading the register
On Oct 27, 2009, at 10:39, ext Aurelien Jarno wrote:
> On Sat, Oct 24, 2009 at 03:19:04PM +0300, juha.riihim...@nokia.com
> wrote:
>> From: Juha Riihimäki
>>
>> RM load/store multiple instructions can be slightly optimized by
>> loading the register offset constant into a variable outside the
>
From: Juha Riihimäki
ARM load/store multiple instructions can be slightly optimized by
loading the register offset constant into a variable outside the
register loop and using the preloaded variable inside the loop instead
of reloading the offset value to a temporary variable on each loop
iterati
On Sat, Oct 24, 2009 at 03:19:03PM +0300, juha.riihim...@nokia.com wrote:
> From: Juha Riihimäki
>
> VFP load/store multiple instructions can be slightly optimized by
> loading the register offset constant into a variable outside the
> register loop and using the preloaded variable inside the loo
Am 27.10.2009 08:46, schrieb Amit Shah:
> On (Mon) Oct 26 2009 [21:15:57], Jan Kiszka wrote:
> However, with the qcow2 synchronous patch, the monitor prompt doesn't
> come up again -- which shows there is a problem with the way the bhs
> work and also the initial resets.
Then the q
On Sat, Oct 24, 2009 at 03:19:04PM +0300, juha.riihim...@nokia.com wrote:
> From: Juha Riihimäki
>
> RM load/store multiple instructions can be slightly optimized by
> loading the register offset constant into a variable outside the
> register loop and using the preloaded variable inside the loop
On (Mon) Oct 26 2009 [21:15:57], Jan Kiszka wrote:
> >>> However, with the qcow2 synchronous patch, the monitor prompt doesn't
> >>> come up again -- which shows there is a problem with the way the bhs
> >>> work and also the initial resets.
> >> Then the qcow2 patch is already in? At least applyin
On Mon, Oct 26, 2009 at 8:01 AM, wrote:
> From: Juha Riihimäki
>
> Current code is broken at least on recent compilers, comparison
> between signed and unsigned types yield incorrect code and render
> the neon shift helper functions defunct. This is the third revision
> of this patch, casting al
56 matches
Mail list logo
