[Qemu-devel] [PATCH 0/5]

[Qemu-devel] [PATCH 0/5]

[Nicholas A. Bellinger]

From: Nicholas Bellinger <nab@linux-iscsi.org>

Greetings QEMU SCSI / BLOCK folks,

This series adds rebased support for the hw/scsi-bsg.c backstore for scsi-bus
compatible HBA emulation in QEMU-KVM on Linux hosts supporting the BSG driver
against current mainline qemu-kvm.git/master code.

This patch is available from the scsi-bsg branch in the megasas/scsi friendly QEMU-KVM tree at:

http://git.kernel.org/?p=virt/kvm/nab/qemu-kvm.git;a=shortlog;h=refs/heads/megasas-upstream-v1

which includes Hannes's recent patch series posted recently against mainline v0.13.0 here:

Re: [Qemu-devel] [PATCH] Megasas HBA emulation and SCSI update v.2
http://lists.gnu.org/archive/html/qemu-devel/2010-11/msg02018.html

Note that in order for BSG I/O to function using vectored AIO a kernel patch to
linux/block/bsg.c:bsg_map_hdr() is currently required running on a bit paired
user/kernel enviroment.  The kernel patch in question is here:

http://marc.info/?l=linux-scsi&m=127649585524598&w=2

The first three patches involve updating block code to support the BSG backstore for scsi-bsg.

The forth patch adds the minor changes to hw/scsi-bus.c and hw/scsi-disk.c in order to
function with scsi-bsg.

And the fifth patch adds the main hw/scsi-bsg.c logic necessary to run the new struct
SCSIDeviceInfo and for BSG AIO using struct iovec and paio_submit_len() to function.
The scsi-bsg.c code has been refactored to follow the modern SCSIDeviceInfo->alloc_req_iov()
and incoming struct iovec * memory for underlying SCSIRequest SGLs

So far this has been tested with v2 8708EM2 HBA Emulation on 0.13.0 on a .37-rc2
KVM host with TCM_Loop FILEIO backstores into a Debian Lenny v2.6.26 x86_64
KVM guest with XFS filesystem mounts.

Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org>

Nicholas Bellinger (5):
  block: Add top level BSG support
  block: Add BSG qemu_open() in block/raw.c:raw_open()
  block: Add paio_submit_len() non sector sized AIO
  scsi: Add BSG checks into scsi-bus and scsi-disk
  scsi-bsg: Add initial support for BSG based SCSIDeviceInfo

 Makefile.objs         |    2 +-
 block.c               |    7 +-
 block.h               |    1 +
 block/raw-posix-aio.h |    3 +
 block/raw-posix.c     |   65 +++++-
 block/raw.c           |   21 ++
 block_int.h           |    6 +
 hw/scsi-bsg.c         |  720 +++++++++++++++++++++++++++++++++++++++++++++++++
 hw/scsi-bus.c         |    3 +-
 hw/scsi-disk.c        |    5 +
 posix-aio-compat.c    |   29 ++
 11 files changed, 855 insertions(+), 7 deletions(-)
 create mode 100644 hw/scsi-bsg.c

[Qemu-devel] Re: [PATCH 0/5]

[Stefan Hajnoczi]

On Wed, Nov 24, 2010 at 8:39 AM, Nicholas A. Bellinger
<nab@linux-iscsi.org> wrote:
> From: Nicholas Bellinger <nab@linux-iscsi.org>
>
> Greetings QEMU SCSI / BLOCK folks,
>
> This series adds rebased support for the hw/scsi-bsg.c backstore for scsi-bus
> compatible HBA emulation in QEMU-KVM on Linux hosts supporting the BSG driver
> against current mainline qemu-kvm.git/master code.

I don't know the Linux SCSI stack, so some basic questions for you :).

With scsi-generic I can send SCSI commands to a device.  How is bsg
different?  The bsg code looks cleaner than sg but they both boil down
to issuing SCSI requests using the Linux block layer AFAICT.

Can you explain what advantages this patch series brings over scsi-generic?

Thanks,
Stefan

Re: [Qemu-devel] Re: [PATCH 0/5]

[Christoph Hellwig]

On Wed, Nov 24, 2010 at 01:38:59PM +0000, Stefan Hajnoczi wrote:
> I don't know the Linux SCSI stack, so some basic questions for you :).
> 
> With scsi-generic I can send SCSI commands to a device.  How is bsg
> different?  The bsg code looks cleaner than sg but they both boil down
> to issuing SCSI requests using the Linux block layer AFAICT.

It's basically a new version of the sg driver with additional features,
and also dropping some old legacy features.

Re: [Qemu-devel] Re: [PATCH 0/5]

[FUJITA Tomonori]

On Wed, 24 Nov 2010 13:38:59 +0000
Stefan Hajnoczi <stefanha@gmail.com> wrote:

> > This series adds rebased support for the hw/scsi-bsg.c backstore for scsi-bus
> > compatible HBA emulation in QEMU-KVM on Linux hosts supporting the BSG driver
> > against current mainline qemu-kvm.git/master code.
> 
> I don't know the Linux SCSI stack, so some basic questions for you :).
> 
> With scsi-generic I can send SCSI commands to a device.  How is bsg
> different?  The bsg code looks cleaner than sg but they both boil down
> to issuing SCSI requests using the Linux block layer AFAICT.
> 
> Can you explain what advantages this patch series brings over scsi-generic?

The main reason why we invented bsg is that we need the common
interface to send non SCSI commands. For example, we already use bsg
for FC stuff:

http://lwn.net/Articles/326338/

We can use the common interface rather than each HW specific interface.

>From the perspective of SCSI, the major advantage of bsg is supporting
bidi commands. I'm not sure qemu will ever need bidi pass through
support though.

Re: [Qemu-devel] Re: [PATCH 0/5]

[Stefan Hajnoczi]

On Thu, Nov 25, 2010 at 2:30 AM, FUJITA Tomonori
<fujita.tomonori@lab.ntt.co.jp> wrote:
> On Wed, 24 Nov 2010 13:38:59 +0000
> Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
>> > This series adds rebased support for the hw/scsi-bsg.c backstore for scsi-bus
>> > compatible HBA emulation in QEMU-KVM on Linux hosts supporting the BSG driver
>> > against current mainline qemu-kvm.git/master code.
>>
>> I don't know the Linux SCSI stack, so some basic questions for you :).
>>
>> With scsi-generic I can send SCSI commands to a device.  How is bsg
>> different?  The bsg code looks cleaner than sg but they both boil down
>> to issuing SCSI requests using the Linux block layer AFAICT.
>>
>> Can you explain what advantages this patch series brings over scsi-generic?
>
> The main reason why we invented bsg is that we need the common
> interface to send non SCSI commands. For example, we already use bsg
> for FC stuff:
>
> http://lwn.net/Articles/326338/
>
> We can use the common interface rather than each HW specific interface.
>
> From the perspective of SCSI, the major advantage of bsg is supporting
> bidi commands. I'm not sure qemu will ever need bidi pass through
> support though.

Thanks for the explanations Christoph and Tomonori.

Stefan

[Qemu-devel] [PATCH 0/5]

[Liu Yu]

The whole patchset includes:
patch 1: fix kvmppc build error
patch 2: fix kvmppc init error
patch 3~5: add kvmppc guest debug support

The guest debug still have some problems I haven't solved.

1. gdb 'next' command uses software breakpoint
software breakpoint is implemented via modify guest's code.
In most case it works well,
but when used by 'next' it's easy to make trouble on powerpc booke.

For example booke has a code template for
jumping to and returning from interrupt handlers:

	bl transfer
	.long handler_addr
	.long ret_addr

when call transfer, it never return but
in transfer assembly code it will read the handler_addr
and ultimately call the handler.
Gdb doesn't know that and treat it as a normal function call.
so gdb put a software breakpoint instruction at handler_addr,
in order to get trap there when return from transfer.

Then guest will read software breakpoint as handler_addr and jump to there..

I'm not sure if x86 suffer this kind of issue.
Is there any way to avoid this?


2. gdb 'watch' command
Jan told me gdb>6.8 can issue hardware watchpoint request via command 'watch',
my gdb is 6.8.50.20080821-cvs and our toolchain provider confirm that it supports hardware watch
However when I use 'watch', I can only see single step from gdbstub side.
Did I miss anything?

[Qemu-devel] Re: [PATCH 0/5]

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

Liu Yu wrote:
> The whole patchset includes:
> patch 1: fix kvmppc build error
> patch 2: fix kvmppc init error
> patch 3~5: add kvmppc guest debug support
> 
> The guest debug still have some problems I haven't solved.
> 
> 1. gdb 'next' command uses software breakpoint
> software breakpoint is implemented via modify guest's code.
> In most case it works well,
> but when used by 'next' it's easy to make trouble on powerpc booke.
> 
> For example booke has a code template for
> jumping to and returning from interrupt handlers:
> 
> 	bl transfer
> 	.long handler_addr
> 	.long ret_addr
> 
> when call transfer, it never return but
> in transfer assembly code it will read the handler_addr
> and ultimately call the handler.
> Gdb doesn't know that and treat it as a normal function call.
> so gdb put a software breakpoint instruction at handler_addr,
> in order to get trap there when return from transfer.
> 
> Then guest will read software breakpoint as handler_addr and jump to there..
> 
> I'm not sure if x86 suffer this kind of issue.

It would if it had such a pattern.

> Is there any way to avoid this?

Unless there is a mechanism via the debug infos of a binary to tell gdb
about this, I think one can only avoid it by not using next here.

> 
> 
> 2. gdb 'watch' command
> Jan told me gdb>6.8 can issue hardware watchpoint request via command 'watch',
> my gdb is 6.8.50.20080821-cvs and our toolchain provider confirm that it supports hardware watch
> However when I use 'watch', I can only see single step from gdbstub side.
> Did I miss anything?

Did you install a watchpoint on a symbol? If yes, try if placing one on
an absolute address changes the picture.

Frankly, I didn't understand gdb's logic for selecting soft or hard
watchpoints so far. Soft watchpoints are those you saw: single step to
the program, checking after each step if the watched variable has
changed. In theory it should be clear when to use which. But practice
appears to be non-deterministic, at least with the versions we recently
tried on x86.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] RE: [PATCH 0/5]

[Liu Yu-B13201]

 

> -----Original Message-----
> From: jan.kiszka@web.de [mailto:jan.kiszka@web.de] 
> Sent: Saturday, July 25, 2009 6:44 PM
> To: Liu Yu-B13201
> Cc: qemu-devel; Hollis Blanchard; kvm-ppc; Nathan Froyd
> Subject: Re: [PATCH 0/5]
> 
> Liu Yu wrote:
> > 2. gdb 'watch' command
> > Jan told me gdb>6.8 can issue hardware watchpoint request 
> via command 'watch',
> > my gdb is 6.8.50.20080821-cvs and our toolchain provider 
> confirm that it supports hardware watch
> > However when I use 'watch', I can only see single step from 
> gdbstub side.
> > Did I miss anything?
> 
> Did you install a watchpoint on a symbol? If yes, try if 
> placing one on
> an absolute address changes the picture.

Cool, it did use hardware watch when I used absolute address.
Seems I need to test more. :)

[Qemu-devel] Re: [PATCH 0/5]

[Nathan Froyd]

On Sat, Jul 25, 2009 at 04:40:12PM +0800, Liu Yu wrote:
> For example booke has a code template for
> jumping to and returning from interrupt handlers:
>
> 	bl transfer
> 	.long handler_addr
> 	.long ret_addr
>
> when call transfer, it never return but
> in transfer assembly code it will read the handler_addr
> and ultimately call the handler.
> Gdb doesn't know that and treat it as a normal function call.
> so gdb put a software breakpoint instruction at handler_addr,
> in order to get trap there when return from transfer.
>
> Then guest will read software breakpoint as handler_addr and jump to there..
>
> I'm not sure if x86 suffer this kind of issue.
> Is there any way to avoid this?

You would need to modify GDB to recognize this sort of case with the
skip_trampoline_code gdbarch method.

-Nathan

[Qemu-devel] RE: [PATCH 0/5]

[Liu Yu-B13201]

 

> -----Original Message-----
> From: Nathan Froyd [mailto:froydnj@codesourcery.com] 
> Sent: Monday, July 27, 2009 9:14 PM
> To: Liu Yu-B13201
> Cc: qemu-devel@nongnu.org; hollisb@us.ibm.com; 
> kvm-ppc@vger.kernel.org; jan.kiszka@siemens.com
> Subject: Re: [PATCH 0/5]
> 
> On Sat, Jul 25, 2009 at 04:40:12PM +0800, Liu Yu wrote:
> > For example booke has a code template for
> > jumping to and returning from interrupt handlers:
> >
> > 	bl transfer
> > 	.long handler_addr
> > 	.long ret_addr
> >
> > when call transfer, it never return but
> > in transfer assembly code it will read the handler_addr
> > and ultimately call the handler.
> > Gdb doesn't know that and treat it as a normal function call.
> > so gdb put a software breakpoint instruction at handler_addr,
> > in order to get trap there when return from transfer.
> >
> > Then guest will read software breakpoint as handler_addr 
> and jump to there..
> >
> > I'm not sure if x86 suffer this kind of issue.
> > Is there any way to avoid this?
> 
> You would need to modify GDB to recognize this sort of case with the
> skip_trampoline_code gdbarch method.
> 

Hmm.. I am not a gdb expert.
But even gdb can recognize this pattern, is it safe to skip it?