All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yosuke Iwamatsu <y-iwamatsu-zZGIbrA41Td8UrSeD/g0lQ@public.gmane.org>
To: Jun Kamada <kama-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Cc: t.horikoshi-+CUm20s59erQFUHtdCDX3A@public.gmane.org,
	xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org,
	xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
Subject: Re: [Xen-devel] [RFC][PATCH] Enhance XenAPI for pvSCSI
Date: Mon, 08 Sep 2008 14:00:47 +0900	[thread overview]
Message-ID: <48C4B17F.2040104@ab.jp.nec.com> (raw)
In-Reply-To: <20080908112241.8179.EB2C8575-+CUm20s59erQFUHtdCDX3A@public.gmane.org>

Jun Kamada wrote:
> Hi Iwamatsu-san,
> 
> The pvSCSI driver provides virtualized SCSI tree to guest domains. 
> (You can specify arbitrary IDs (Host:Channel:Target:Lun) mapping 
> between Dom0 and the guests.)
> 
> In addition to that, some SCSI commands, for example REPORT_LUN, may 
> be emulated on backend driver but simply passthroughed to physical
> device.
> 
> So, class name 'VSCSI' is appropriate, in my personal opinion.

The guest sees a virtualized scsi host, a virtualized scsi tree but
endpoint devices (luns) themselves are not virtualized, right?
I'm under an impression that pvscsi is similer to pass-through pci
and 'V' prefix is not appropriate for these half-virtualized,
half-physical devices.

Below is my idea of naming xen-api classes:
a. If the device is trully virtualized, give 'V' prefix (VIF, VBD etc).
    For example, a VIF has virtual mac address, virtual vendor name
    and virtual device name and the guest see nothing about physical nic
    devices. Actually, it is possible to create VIF devices even if the
    host doesn't have physical network devices.
b. If the device is half-virtualized, give 'D' prefix.
    When using pass-through pci, host controllers, device trees, config
    spaces might be virtualized but the guest see physical device
    information like device id and vendor id, and directly access to
    registers. The host, of course, has to have physical devices and
    the device will be occupied while it is used by a guest.

I don't know details about pvscsi, but perphaps we had better
categorize it as b.

Thanks,
-- Yosuke

> 
> Best regards,
> 
> 
> On Fri, 05 Sep 2008 17:52:42 +0900
> Yosuke Iwamatsu <y-iwamatsu-zZGIbrA41Td8UrSeD/g0lQ@public.gmane.org> wrote:
> 
>> Hi,
>>
>> Masaki Kanno wrote:
>>> Hi,
>>>
>>> I would like to enhance XenAPI for pvSCSI. 
>>> At the beginning, I updated only the document of XenAPI.  I'm going 
>>> to implement XenAPI of pvSCSI along the document.  Could you comment?
>>>
>>> The following classes and RPCs are added by the enhancement. 
>>>  Classes:
>>>   - VSCSI class
>>>      This is a class for virtual SCSI devices.
>> It's nice to keep xen-api updated with new features :-)
>> One thing I want to point out is about the class name.
>> I think 'DSCSI' (direct scsi) is appropriate rather than 'VSCSI',
>> because pvSCSI driver doesn't really provide virtual scsi luns but
>> passes through scsi commands to real scsi luns, as far as I understand.
>>
>> Regards,
>> -- Yosuke Iwamatsu
>>
>>>   - PSCSI class
>>>      This is a class for physical SCSI devices.
>>>
>>>  RPCs:
>>>   - VSCSI class
>>>    -- get_all
>>>        A list of all VSCSIs known to the system is gotten.
>>>    -- get_uuid
>>>        An UUID of the VSCSI is gotten.
>>>    -- get_VM
>>>        A VM ref of the VSCSI is gotten.
>>>    -- get_PSCSI
>>>        A PSCSI ref of the VSCSI is gotten.
>>>    -- get_virtual_host
>>>        A virtual host number of the VSCSI is gotten.
>>>    -- get_virtual_channel
>>>        A virtual channel number of the VSCSI is gotten.
>>>    -- get_virtual_target
>>>        A virtual target number of the VSCSI is gotten.
>>>    -- get_virtual_lun
>>>        A virtual logical unit number of the VSCSI is gotten.
>>>    -- get_virtual_HCTL
>>>        A virtual HCTL (string of "<host>:<channel>:<target>:<lun>") 
>>>        of the VSCSI is gotten.
>>>    -- create
>>>        A new VSCSI instance is created.
>>>    -- destroy
>>>        The VSCSI instance is destroyed.
>>>    -- get_by_uuid
>>>        A VSCSI ref of the UUID is gotten.
>>>    -- get_record
>>>        A VSCSI record of the VSCSI is gotten.
>>>
>>>   - PSCSI class
>>>    -- get_all
>>>        A list of all PSCSIs known to the system is gotten.
>>>    -- get_uuid
>>>        An UUID of the PSCSI is gotten.
>>>    -- get_host
>>>        A host ref of the PSCSI is gotten.
>>>    -- get_physical_host
>>>        A physical host number of the PSCSI is gotten.
>>>    -- get_physical_channel
>>>        A physical channel number of the PSCSI is gotten.
>>>    -- get_physical_target
>>>        A physical target number of the PSCSI is gotten.
>>>    -- get_physical_lun
>>>        A physical logical unit number of the PSCSI is gotten.
>>>    -- get_physical_HCTL
>>>        A physical HCTL (string of "<host>:<channel>:<target>:<lun>") 
>>>        of the PSCSI is gotten.
>>>    -- get_vendor_name
>>>        A vendor name of the PSCSI is gotten.
>>>    -- get_model
>>>        A model name of the PSCSI is gotten.
>>>    -- get_type_id
>>>        An ID of device types of the PSCSI is gotten. (If disk, the ID 
>>>        is 0.  If tape, the ID is 1.)
>>>    -- get_type
>>>        A device type string of the PSCSI is gotten.
>>>    -- get_sg_name
>>>        A SCSI generic (sg) device name of the PSCSI is gotten.
>>>    -- get_revision
>>>        A revision string of the PSCSI is gotten.
>>>    -- get_scsi_id
>>>        A SCSI ID string of the PSCSI is gotten. The string is a result 
>>>        of 'scsi_id -gu -s'.
>>>    -- get_scsi_level
>>>        A SCSI level of the PSCSI is gotten.
>>>    -- get_by_uuid
>>>        A PSCSI ref of the UUID is gotten.
>>>    -- get_record
>>>        A PSCSI record of the PSCSI is gotten.
>>>
>>>   - VM class
>>>    -- get_VSCSIs
>>>        VSCSI refs of the VM are gotten.
>>>
>>>   - host class
>>>    -- get_PSCSIs
>>>        PSCSI refs of the host are gotten.
>>>
>>>
>>> Signed-off-by: Masaki Kanno <kanno.masaki-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>>>
>>> Best regards,
>>>  Kan
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
>>> http://lists.xensource.com/xen-devel
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
>> http://lists.xensource.com/xen-devel
> 
> 
> -----
> Jun Kamada
> Linux Software Development Div.
> Server Systems Unit
> Fujitsu Ltd.
> kama-+CUm20s59erQFUHtdCDX3A@public.gmane.org
> 
> 

  parent reply	other threads:[~2008-09-08  5:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-03  6:57 [RFC][PATCH] Enhance XenAPI for pvSCSI Masaki Kanno
2008-09-05  8:52 ` Yosuke Iwamatsu
2008-09-08  2:31   ` Jun Kamada
     [not found]     ` <20080908112241.8179.EB2C8575-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2008-09-08  5:00       ` Yosuke Iwamatsu [this message]
2008-09-08 11:47         ` Masaki Kanno
2008-09-08  5:03   ` Masaki Kanno
2008-09-08  7:47     ` Masaki Kanno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48C4B17F.2040104@ab.jp.nec.com \
    --to=y-iwamatsu-zzgibra41td8ursed/g0lq@public.gmane.org \
    --cc=kama-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
    --cc=t.horikoshi-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
    --cc=xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org \
    --cc=xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.