Hi,
i sent the following to Paolo Bonzini and Stefan Hajnoczi.
Stefan advised
> In the future I think it's appropriate to CC qemu-devel since others
> in the community may be interested in virtio-scsi discussions too.
So i forward my mail to this list.
I am subscribed now.
A first test report o
Hi,
Stefan Hajnoczi wrote:
> In the future I think it's appropriate to CC qemu-devel since others
> in the community may be interested in virtio-scsi discussions too.
Ok. I'll forward my original mail and this reply to qemu-devel.
> The current state is that CD-ROM passthrough with virtio-scsi
Hi,
Stefan Hajnoczi wrote:
> I actually suggest focussing just
> on qemu.git/master because that is where developers mostly invest
> their time.
I did now
git clone git://git.qemu.org/qemu.git
cd qemu && ./configure && make
I assume this binary is the right one for my "AMD Athlon(tm) II X4 6
Hi,
Paolo Bonzini wrote:
> I suggest trying with 1.0-rc (origin/master).
Am i on the right track with git clone git://git.qemu.org/qemu.git ?
> scsi-block uses
> read+write for READ/WRITE CDBs and SG_IO for everything else.
That sounds scary to me. On real Linux systems it is not advisable t
Hi,
i wrote:
> > The sense code is listed in MMC as:
> >B 00 06 I/O PROCESS TERMINATED
Paolo Bonzini wrote:
> Is it good or bad? :) I see it even in the very first command.
It does not indicate success. MMC only has the meager info above.
SPC-3 says in table 27 about sense key B:
"Bh : AB
Hi,
i wrote:
> > So how is this altered to 0x12 in the further course of processing ?
Paolo Bonzini wrote:
> Because you're using an *IDE* (ATAPI) CD-ROM, not SCSI. See hw/ide/atapi.c.
You convinced me.
But this does not explain yet the difference in behavior of
both groups of IDE DVD-ROMs. Why
Hi,
i forgot to address this concern:
Paolo Bonzini wrote:
> The page length is indeed 18 for IDE and 20 for SCSI. I made some changes
> to that page recently, but left the 18 because I feared causing regression.
> But if that is a bug, we can probably fix it in 1.0.
The SCSI client is supposed
Hi,
first i want to thank Paolo for his patience.
> So if you specified "-drive if=scsi" *and* "-cdrom", you'd get two non-empty
> drives.
Indeed. With
-drive file=/dev/sr0,if=scsi,media=cdrom -cdrom /dvdbuffer/pseudo_drive
i get two drives with media:
0 -dev '/dev/sr0' rwrw-- : 'QEMU
Hi,
i repeated my tests with -drive and -cdrom in the same qemu run:
...absolute.path.../x86_64-softmmu/qemu-system-x86_64 \
-enable-kvm \
-L ...absolute.path.../pc-bios \
-nographic \
-m 512 \
-net nic,model=ne2k_pci \
-net user,hostfwd=tcp::5557-:22 \
-hda /
Hi,
i could track down the reason for sense code B 00 06 to an ioctl(SG_IO)
which returns -1. errno is 1.
The host system has in /usr/include/asm-generic/errno-base.h
#define EPERM1 /* Operation not permitted */
The user who runs qemu is able to perform e.g.
PREVENT/ALLOW M
Hi
i can prevent the EPERM failures of ioctl(SG_IO) by opening the
device file /dev/sg1 with O_RDWR rather than O_RDONLY.
In block/raw-posix.c:raw_open_common i implemented this hack:
printf("block/raw-posix.c: raw_open_common(\"%s\", %x)\n",
filename, s->open_flags);
if
Hi,
i wrote:
> > Paolo:
> > May i ask for the favor that you try to add O_RDWR to the qemu_open()
> > call of passthrough devices ?
Paolo Bonzini wrote:
> I think the problem is that you're passing media=cdrom:
> Just do not do that when using scsi-generic.
The result looks promising, indeed. I
Hi,
i wrote:
> > CD SAO gets stuck at SEND CUE SHEET.
Paolo Bonzini wrote:
> I wouldn't be surprised if they are bugs in either scsi-generic or the LSI
> emulation code. They seem to occur when commands return less data than the
> guest driver has asked; with master I get a guest oops in the LSI
Hi,
> We're about to release QEMU 1.0(-rc1) and you've just spotted a
> compilation issue...
Maybe one should consider to obtain the missing information
rather than crippling the debug message, like i did.
> You've solved this issue 50%! What's missing now is for you to put this
> fix into a se
Hi,
another showstopper appeared for DVD+RW.
After i disabled SET STREAMING, i was able to write a thoroughly formatted
DVD+RW. But when i inserted one that was never written up to its end, the
attempt failed to (re-)start background formatting (Format Type = 26h):
FORMAT UNIT
04 11 00 00 00
Hi,
Paolo Bonzini wrote:
> Can you retry this running qemu as root or with CAP_SYS_RAWIO?
No improvement to see.
On a new DVD+RW i do
$ xorriso -for_backup -scsi_log on -dev /dev/sr1 -add /usr/include --
and still get
FORMAT UNIT
04 11 00 00 00 00
To drive: 12b
00 02 00 08 ff ff ff
Hi,
i completed my tests on DVD-RW (next will be DVD+R).
Sequential DVD-RW can be written with write type Incremental (aka Packet)
and be blanked.
The write run commands of this DVD-RW profile 0x14 are the same as the
ones for profile 0x11 DVD-R. So i boldly declare write success for both.
Thor
Hi,
> > [REQUEST SENSE while blanking]
> > MMC-3 5.2 and MMC-5 6.2.3
> Is this git master or 0.15?
It is a git clone obtained on November 2 by
git clone git://git.qemu.org/qemu.git
I see a file VERSION with date Nov 2 13:41 (+0100)
$ cat VERSION
0.15.90
$ git describe
fatal: No ann
Hi,
now for DVD+R burning.
It works well if i avoid command RESERVE TRACK.
RESERVE TRACK shows similar effects as the failed DVD-RW DAO run,
resp. the failed CD SAO run: qemu gets stuck at 100 % CPU.
No failed ioctl is indicated by my printfs.
Details:
Hi,
i wanted to test Blu-ray burning and attached a BD recorder via USB
to the host. Its power was switched on, before i booted the host.
The host can operate this drive.
But the qemu guest obviously has severe problems with it.
There is a 'QEMU DVD-ROM' at /dev/sr0.
There is also a /dev/sr1, wh
Hi,
Paolo Bonzini wrote:
> It would be more interesting if you tried again the failure cases with a
> virtio drive (if=virtio). It would appear as /dev/vda but you can issue
> SG_IO to it. This would isolate the failure to the kernels vs. the SCSI
> subsystem.
Will do. I am currently fighting w
Hi,
since i had to give up the plan to test BD burning, i now post the
first summary of passthrough testing on base of if=scsi .
Next i will try to follow Paolo Bonzini's proposal to use if=virtio.
-
List of successes and
Hi,
i have finished CD and DVD tests with
drive file=/dev/sg2,if=virtio -cdrom /dvdbuffer/pseudo_drive
There is substantial improvement towards if=scsi.
Actually everything works like a charm now. :))
It did not work for libburn out of the box, but i could work around
most of the obstacles.
O
Hi,
> >drive file=/dev/sg2,if=virtio -cdrom /dvdbuffer/pseudo_drive
> > Actually everything works like a charm now. :))
> Cool. So you might have unveiled some kernel bugs too (host crashes are
> never desirable!)
The USB drive is back at the test machine.
I'm running the planned BD-RE tes
Hi,
Markus Armbruster wrote:
> Has anyone thought of keeping your tests around for regression testing
> purposes?
The full tour lasts a whole workday and needs human attention.
I still did not come to test the newest proposals of Paolo Bonzini
and Zhi Yong Wu, because the last BD-R test was fini
Hi,
Paolo Bonzini wrote:
> Yes, docs/qdev-device-use.txt helps. "qemu -device virtio-blk,?" too.
I read it and ran '-device ?'. But both left me clueless.
The text i understood mainly as refering to "old ways" and "new way"
of defining devices. I stalled when i found no flesh for "HOST-OPTS"
and
Hi,
here are test results from the USB attached BD recorder.
It is a SATA drive 'Optiarc' 'BD RW BD-5300S' rev '1.04' at
a 'JMicron' 'JM20336 SATA, USB Combo' controller.
--
qemu start command is the same as with the interna
Hi,
the test results on CD-RW, DVD-RW, DVD+RW, BD-RE are flawless with
Paolo Bonzini's most recent proposal
-drive file=/dev/sr2,if=none,id=scsicd
-device
virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048
libburn works fine via SG_IO. dd and other unaware readers work fi
Hi,
i am now testing a hack that adds O_EXCL to the call of qemu_open()
in block/raw-posix.c. Just as proof-of-concept.
This is Linux-host-specific, of course.
---
As first i learned to distinguish between octal and hex. :))
So
Hi,
i reported nastily bahaving SCSI commands SEND CUE SHEET, SET STREAMING,
FORMAT UNIT, READ DISC STRUCTURE, REQUEST SENSE , RESERVE TRACK.
This was with
-drive file=/dev/sg2,if=scsi
Paolo Bonzini wrote:
> I fixed all of these; [...]
> The bugs were simply that QEMU did not compute the length
Hi,
> I only tested CD-RW DAO burning of an ISO image, plus invoking a bunch
> of commands from Thomas's logs). The burning succeeded but reading
> the resulting medium failed consistently at 26 MB. However, the same
> happened even when doing CD passthrough via virtio, so it may be due to
> a d
Hi,
> The READ TOC/PMA/ATIP at the end of burning gives (reformatted):
> 43 02 02 00 00 00 00 00 51 00
> From drive: 81b
> 00 4f 01 01
> 01 14 00 a0 00 00 00 00 01 00 00
> 01 14 00 a1 00 00 00 00 01 00 00
> 01 14 00 a2 00 00 00 00 18 39 32 <<<
> 01 14 00 01 00 00 00 00 00 02 00
I was not aware yo
Hi,
Paolo Bonzini wrote:
> > > case MODE_PAGE_R_W_ERROR: /* error recovery */
> > > [...]
> > > -buf[15] = 0x00;
Kevin Wolf wrote:
> > Why did you drop this? It still seems to be part of the buffer.
Paolo Bonzini wrote:
> Actually, I think it's best if these patches wait unt
33 matches
Mail list logo
