Re: [patch 27/32] xen: Add the Xen virtual network device driver.

2007-04-29 Thread Christoph Hellwig
On Sun, Apr 29, 2007 at 10:29:02AM -0700, Jeremy Fitzhardinge wrote: +#include linux/version.h not needed. +#include xen/xenbus.h +#include xen/interface/io/netif.h +#include xen/interface/memory.h +#ifdef CONFIG_XEN_BALLOON +#include xen/balloon.h +#endif +#include

Re: [patch 26/32] xen: Add Xen virtual block device driver.

2007-04-29 Thread Christoph Hellwig
source drivers/s390/block/Kconfig +source drivers/block/xen/Kconfig Please don't add a new subdirectory for a tiny new driver that really should be only a single .c file. +config XEN_BLKDEV_FRONTEND + tristate Block device frontend driver + depends on XEN + default y Please

Re: [patch 25/29] xen: Add the Xen virtual network device driver.

2007-05-05 Thread Christoph Hellwig
On Fri, May 04, 2007 at 04:21:16PM -0700, Jeremy Fitzhardinge wrote: +/* + * Mutually-exclusive module options to select receive data path: + * rx_copy : Packets are copied by network backend into local memory + * rx_flip : Page containing packet data is transferred to our ownership + * For

Re: [patch 7/9] lguest: the net driver

2007-05-09 Thread Christoph Hellwig
On Thu, May 10, 2007 at 01:14:55AM +1000, Rusty Russell wrote: + info-peer = (void *)ioremap(info-peer_phys, info-mapsize); check for NULL Erk, good catch! Also the cast is bogus. ioremap already returns void already. Even more importantly the lack of the __iomem annotations shows

Re: [PATCH 0/5] lguest feedback tidyups

2007-05-11 Thread Christoph Hellwig
On Fri, May 11, 2007 at 11:17:26AM +1000, Rusty Russell wrote: - But the cost was high: lots of __force casts 8( That sounds like something is very fishy. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

Re: [PATCH 2/5] lguest guest feedback tidyups

2007-05-11 Thread Christoph Hellwig
On Fri, May 11, 2007 at 05:31:06PM +1000, Rusty Russell wrote: Well, without ioremap, the memory wouldn't normally be mapped. Is there something better to use? Either use accessors or use your own lguest-specific remapping function that doesn't return __iomem function So instead of

Re: [kvm-devel] [RFC/PATCH 14/15] guest: detect when running on kvm

2008-03-20 Thread Christoph Hellwig
On Thu, Mar 20, 2008 at 05:25:26PM +0100, Carsten Otte wrote: @@ -143,6 +143,10 @@ static noinline __init void detect_machi /* Running on a P/390 ? */ if (cpuinfo-cpu_id.machine == 0x7490) machine_flags |= 4; + + /* Running under KVM ? */ + if

Re: [kvm-devel] [RFC/PATCH 14/15] guest: detect when running on kvm

2008-03-20 Thread Christoph Hellwig
On Thu, Mar 20, 2008 at 09:37:19PM +0100, Carsten Otte wrote: Christoph Hellwig wrote: On Thu, Mar 20, 2008 at 05:25:26PM +0100, Carsten Otte wrote: @@ -143,6 +143,10 @@ static noinline __init void detect_machi /* Running on a P/390 ? */ if (cpuinfo-cpu_id.machine == 0x7490

Re: [dm-devel] [PATCH] block: silently error unsupported empty barriers too

2009-08-06 Thread Christoph Hellwig
On Thu, Aug 06, 2009 at 12:45:50PM +0100, Alasdair G Kergon wrote: On Thu, Aug 06, 2009 at 12:14:17PM +0100, Mark McLoughlin wrote: We should error all barriers, even empty barriers, on devices like virtio_blk which don't support them. Have you considered whether or not virtio_blk

Re: [PATCH] SCSI driver for VMware's virtual HBA - V4.

2009-09-09 Thread Christoph Hellwig
On Wed, Sep 09, 2009 at 05:12:26PM -0500, Anthony Liguori wrote: Alok Kataria wrote: I see your point, but the ring logic or the ABI that we use to communicate between the hypervisor and guest is not shared between our storage and network drivers. As a result, I don't see any benefit of

Re: [Qemu-devel] [PATCH 3/4] scsi-disk: Factor out SCSI command emulation

2009-10-28 Thread Christoph Hellwig
On Tue, Oct 27, 2009 at 04:28:59PM +0100, Hannes Reinecke wrote: 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. Might be a good idea to move something like this first into the series and

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

2009-10-28 Thread Christoph Hellwig
On Wed, Oct 28, 2009 at 09:11:29AM +0100, Hannes Reinecke wrote: The problem is I don't have any documentation for the LSI parallel SCSI controller. So I don't know if and in what shape I/O is passed down, nor anything else. And as the SCSI disk emulation is really tied into the LSI parallel

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

2009-10-29 Thread Christoph Hellwig
On Thu, Oct 29, 2009 at 10:14:19AM -0500, Anthony Liguori wrote: Which patches are those? http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=1ee5ee08e4427c3db7e1322d30cc0e58e5ca48b9 and http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=a6e6178185786c582141f993272e00521d3f125a

Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size

2010-01-04 Thread Christoph Hellwig
On Mon, Jan 04, 2010 at 01:38:51PM +1030, Rusty Russell wrote: I thought this was what I was doing, but I have shown over and over that I have no idea about block devices. Our current driver treats BLK_SIZE as the logical and physical size (see blk_queue_logical_block_size). I have no

Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size

2010-01-08 Thread Christoph Hellwig
On Tue, Jan 05, 2010 at 08:16:15PM +, Jamie Lokier wrote: It would be good if virtio relayed the backing device's basic topology hints, so: - If the backing dev is a real disk with 512-byte sectors, virtio should indicate 512-byte blocks to the guest. - If the backing

Re: [PATCH] virtio-spec: document block CMD and FLUSH

2010-05-04 Thread Christoph Hellwig
On Tue, May 04, 2010 at 02:08:24PM +0930, Rusty Russell wrote: On Fri, 19 Feb 2010 08:52:20 am Michael S. Tsirkin wrote: I took a stub at documenting CMD and FLUSH request types in virtio block. Christoph, could you look over this please? I note that the interface seems full of warts to

Re: RFC: Network Plugin Architecture (NPA) for vmxnet3

2010-05-05 Thread Christoph Hellwig
On Tue, May 04, 2010 at 04:02:25PM -0700, Pankaj Thakkar wrote: The plugin image is provided by the IHVs along with the PF driver and is packaged in the hypervisor. The plugin image is OS agnostic and can be loaded either into a Linux VM or a Windows VM. The plugin is written against the

Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3

2010-05-05 Thread Christoph Hellwig
On Wed, May 05, 2010 at 10:35:28AM -0700, Dmitry Torokhov wrote: Yes, with the exception that the only body of code that will be accepted by the shell should be GPL-licensed and thus open and available for examining. This is not different from having a standard kernel module that is loaded

Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3

2010-05-06 Thread Christoph Hellwig
On Wed, May 05, 2010 at 10:47:10AM -0700, Pankaj Thakkar wrote: Forget about the licensing. Loading binary blobs written to a shim layer is a complete pain in the ass and totally unsupportable, and also uninteresting because of the overhead. [PT] Why do you think it is unsupportable? How

Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3

2010-05-06 Thread Christoph Hellwig
On Wed, May 05, 2010 at 10:52:53AM -0700, Stephen Hemminger wrote: Let me put it bluntly. Any design that allows external code to run in the kernel is not going to be accepted. Out of tree kernel modules are enough of a pain already, why do you expect the developers to add another

Re: [PATCH] virtio_blk: allow re-reading config space at runtime

2011-02-01 Thread Christoph Hellwig
On Thu, Jan 27, 2011 at 05:32:21PM +0200, Michael S. Tsirkin wrote: This needs to be flushed on device removal, I think, otherwise the vdev pointer will go stale. Indeed. +} + + Two empty lines :) I'll fix it up. ___ Virtualization

Re: [PATCH 20/25] Staging: hv: Use the probe function in struct hv_driver

2011-04-26 Thread Christoph Hellwig
@@ -882,7 +882,7 @@ static int blkvsc_drv_init(void) drv-driver.name = storvsc_drv_obj-base.name; - drv-driver.probe = blkvsc_probe; + drv-probe = blkvsc_probe; drv-driver.remove = blkvsc_remove; drv-driver.shutdown = blkvsc_shutdown; Not new in this patch,

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-04-26 Thread Christoph Hellwig
Do you have a repository containing the current state of your patche somewhere? There's been so much cleanup that it's hard to review these patches against the current mainline codebase. ___ Virtualization mailing list

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-04-27 Thread Christoph Hellwig
On Wed, Apr 27, 2011 at 01:54:02AM +, KY Srinivasan wrote: I would prefer that we go through the review process. What is the process for this review? Is there a time window for people to respond. I am hoping I will be able to address all the review comments well in advance of the next

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-04-27 Thread Christoph Hellwig
On Wed, Apr 27, 2011 at 11:47:03AM +, KY Srinivasan wrote: On the host side, Windows emulates the standard PC hardware to permit hosting of fully virtualized operating systems. To enhance disk I/O performance, we support a virtual block driver. This block driver currently handles disks

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-05-01 Thread Christoph Hellwig
On Fri, Apr 29, 2011 at 04:32:35PM +, KY Srinivasan wrote: On the host-side, as part of configuring a guest you can specify block devices as being under an IDE controller or under a SCSI controller. Those are the only options you have. Devices configured under the IDE controller cannot

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-05-01 Thread Christoph Hellwig
On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote: Are you sure the libata core can't see this ide controller and connect to it? That way you would use the scsi system if you do that and you would need a much smaller ide driver, perhaps being able to merge it with your scsi driver.

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-05-01 Thread Christoph Hellwig
On Sun, May 01, 2011 at 03:46:23PM +, KY Srinivasan wrote: What is the issue here? This is no different than what is done in other Virtualization platforms. For instance, the Xen blkfront driver is no different - if you specify the block device to be presented to the guest as an ide

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-05-01 Thread Christoph Hellwig
On Sun, May 01, 2011 at 06:56:58PM +, KY Srinivasan wrote: Yeah, it seems to me that no matter how the user specifies the disk type for the guest configuration, we should use the same Linux driver, with the same naming scheme for both ways. As Christoph points out, it's just a

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-05-01 Thread Christoph Hellwig
On Sun, May 01, 2011 at 06:08:37PM +, KY Srinivasan wrote: Could you elaborate on the problems/issues when the block driver registers for the IDE majors. On the Qemu side, we have a mechanism to disable the emulation when PV drivers load. I don't think there is an equivalent mechanism

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-05-02 Thread Christoph Hellwig
On Mon, May 02, 2011 at 07:48:38PM +, KY Srinivasan wrote: By setting up appropriate modprobe rules, this can be addressed. That assumes libata is a module, which it is not for many popular distributions. ___ Virtualization mailing list

Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

2011-05-02 Thread Christoph Hellwig
On Mon, May 02, 2011 at 09:16:36PM +, KY Srinivasan wrote: That assumes libata is a module, which it is not for many popular distributions. As long as you can prevent ata_piix from loading, it should be fine. Again, this might very well be built in, e.g. take a look at:

Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig

2011-05-04 Thread Christoph Hellwig
On Wed, May 04, 2011 at 11:51:45AM -0700, K. Y. Srinivasan wrote: config HYPERV tristate Microsoft Hyper-V client drivers - depends on X86 m + depends on X86 ACPI PCI m I can't see anything preventing this driver from beeing built-in, so the depends on m should probably go

Re: various vmbus review comments

2011-05-09 Thread Christoph Hellwig
On Fri, May 06, 2011 at 01:10:38PM +, KY Srinivasan wrote: I audited the block and the net drivers. As part of their exit routine, they invoke vmbus_child_driver_unregister() after properly cleaning up all the devices they are managing. Do you still see an issue with regards to module

Re: various vmbus review comments

2011-05-09 Thread Christoph Hellwig
On Mon, May 09, 2011 at 02:56:52PM +, KY Srinivasan wrote: I will address this. Greg had a concern about module reference counting and looking at the current code, it did not appear to be an issue. The change you are suggesting will not affect the vmbus core which is what I want to focus

Re: [PATCH 017/206] Staging: hv: Get rid of the indirection for invoking io request

2011-05-10 Thread Christoph Hellwig
- ret = storvsc_drv-on_io_request(blkdev-device_ctx, + ret = storvsc_do_io(blkdev-device_ctx, blkvsc_req-request); ret = storvsc_do_io(blkdev-device_ctx, blkvsc_req-request); ___

Re: [PATCH 115/206] Staging: hv: Use completion abstraction in struct netvsc_device

2011-05-10 Thread Christoph Hellwig
- net_device-wait_condition = 0; ret = vmbus_sendpacket(device-channel, init_packet, sizeof(struct nvsp_message), (unsigned long)init_packet, @@ -272,10 +272,8 @@ static int netvsc_init_recv_buf(struct hv_device *device)

Re: [PATCH 129/206] Staging: hv: Move the sector size check into blkvsc_drv_init

2011-05-10 Thread Christoph Hellwig
On Mon, May 09, 2011 at 02:56:51PM -0700, K. Y. Srinivasan wrote: The subject line says it all. Is there any good reason to not support a 32-bit sector_t? ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

Re: various vmbus review comments

2011-05-10 Thread Christoph Hellwig
I must be missing something here. As I look at the block driver (and this is indicative of other drivers as well); the exit routine - blkvsc_drv_exit, first iterates through all the devices it manages and invokes device_unregister() on each of the devices and then invokes

Re: vmbus driver

2011-05-20 Thread Christoph Hellwig
On Thu, May 19, 2011 at 03:06:25PM -0700, K. Y. Srinivasan wrote: A few days ago you applied all the outstanding patches for the Hyper-V drivers. With these patches, I have addressed all of the known review comments for the vmbus driver (and a lot of comments/issues in other drivers as

Re: vmbus driver

2011-05-20 Thread Christoph Hellwig
On Fri, May 20, 2011 at 01:12:32PM +, KY Srinivasan wrote: Well, the util driver that implements a range of other services such as KVP, time synch, heartbeat etc. is also a client of the vmbus driver (perhaps not in the The KVP driver is a different module as far as I can see. But it

Re: vmbus driver

2011-05-22 Thread Christoph Hellwig
I see maintainers for each of the clocksource drivers and I see John Stultz and Thomas Gleixner listed as the maintainers for Timekeeping. Who should sign-off on the Hyper-V clocksource. just send it to both of the with linux-kernel in Cc, and either of them will probably put it in.

Re: [PATCH 12/49] Staging: hv: storvsc: Add a DMI signature to support auto-loading

2011-06-06 Thread Christoph Hellwig
On Mon, Jun 06, 2011 at 03:49:36PM -0700, K. Y. Srinivasan wrote: To support auto-loading the storvsc driver, add a DMI signature. The storvsc driver is not a DMI driver, but a vmbus driver. As such it should have a vmbus table that is used for autoloading, not a dmi one.

Re: [PATCH 24/49] Staging: hv: vmbus: Get rid of the unused wrapper - vmbus_onchannel_event()

2011-06-06 Thread Christoph Hellwig
On Mon, Jun 06, 2011 at 03:49:48PM -0700, K. Y. Srinivasan wrote: Now, get rid of the unused wrapper - vmbus_onchannel_event(). I'd merge this into the previous patch. In general your patch split seem a little too fine grained to me in general. When you remove a wrapper you can inline it into

Re: [PATCH 26/49] Staging: hv: vmbus: Get rid of the poll timer in the channel state

2011-06-06 Thread Christoph Hellwig
On Mon, Jun 06, 2011 at 03:49:50PM -0700, K. Y. Srinivasan wrote: Since tis is not used anymore, get rid of the poll timer in the channel state. This would be more useful together with the patch that removes the use of the timer. ___ Virtualization

Re: [RFC] virtio: Support releasing lock during kick

2011-06-19 Thread Christoph Hellwig
On Sun, Jun 19, 2011 at 10:48:41AM +0300, Michael S. Tsirkin wrote: diff --git a/block/blk-core.c b/block/blk-core.c index 4ce953f..a8672ec 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -433,6 +433,8 @@ void blk_run_queue(struct request_queue *q)

Re: virtio scsi host draft specification, v3

2011-06-29 Thread Christoph Hellwig
On Tue, Jun 14, 2011 at 05:30:24PM +0200, Hannes Reinecke wrote: Which is exactly the problem I was referring to. When using more than one channel the request ordering _as seen by the initiator_ has to be preserved. This is quite hard to do from a device's perspective; it might be able to

Re: virtio scsi host draft specification, v3

2011-06-29 Thread Christoph Hellwig
On Sun, Jun 12, 2011 at 10:51:41AM +0300, Michael S. Tsirkin wrote: For example, if the driver is crazy enough to put all write requests on one queue and all barriers on another one, how is the device supposed to ensure ordering? There is no such things as barriers in SCSI. The thing that

Re: virtio scsi host draft specification, v3

2011-06-29 Thread Christoph Hellwig
On Wed, Jun 29, 2011 at 10:23:26AM +0200, Paolo Bonzini wrote: I agree here, in fact I misread Hannes's comment as if a driver uses more than one queue it is responsibility of the driver to ensure strict request ordering. If you send requests to different queues, you know that those requests

Re: virtio scsi host draft specification, v3

2011-06-29 Thread Christoph Hellwig
On Wed, Jun 29, 2011 at 10:39:42AM +0100, Stefan Hajnoczi wrote: I think we're missing a level of addressing. We need the ability to talk to multiple target ports in order for list target ports to make sense. Right now there is one implicit target that handles all commands. That means there

Re: [PATCH 00/40] Staging: hv: Driver cleanup

2011-06-30 Thread Christoph Hellwig
On Wed, Jun 29, 2011 at 07:38:21AM -0700, K. Y. Srinivasan wrote: Further cleanup of the hv drivers: 1) Cleanup the reference counting mess for both stor and net devices. I really don't understand the need for reference counting on the storage side, especially now that you only have a

Re: [PATCH 23/40] Staging: hv: storvsc: Introduce code to manage IDE devices using storvsc HBA

2011-06-30 Thread Christoph Hellwig
+/* + * We want to manage the IDE devices using standard Linux SCSI drivers + * using the storvsc driver. + * Define special channels to support this. + */ + +#define HV_MAX_IDE_DEVICES 4 +#define HV_IDE_BASE_CHANNEL 10 +#define HV_IDE0_DEV1 HV_IDE_BASE_CHANNEL +#define

Re: [PATCH 24/40] Staging: hv: storvsc: On I/O get the correct IDE device

2011-06-30 Thread Christoph Hellwig
On Wed, Jun 29, 2011 at 07:39:21AM -0700, K. Y. Srinivasan wrote: We use the channel number to distinguish an IDE device managed by the storvsc driver from scsi devices. Add code to get the correct device pointer based on the channel number. Signed-off-by: K. Y. Srinivasan k...@microsoft.com

Re: [PATCH 25/40] Staging: hv: storvsc: Add state to manage the lifecycle of emulated HBA

2011-06-30 Thread Christoph Hellwig
I think all this would be a lot simpler if you simply used one scsi host per ide device as mentioned before. Also it would be nice if you could sent patches 23 to 28 as one patch in the next round, as that allows reviewing the whole IDE related code in one go, which is useful given that it's all

Re: [PATCH 35/40] Staging: hv: storvsc: Make storvsc_dev_add() a static function

2011-06-30 Thread Christoph Hellwig
On Wed, Jun 29, 2011 at 07:39:32AM -0700, K. Y. Srinivasan wrote: Make storvsc_dev_add() a static function. Making all pending functions static should be fine in a single patch. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

Re: [PATCH 34/40] Staging: hv: storvsc: Add the contents of hyperv_storage.h to storvsc_drv.c

2011-06-30 Thread Christoph Hellwig
On Wed, Jun 29, 2011 at 07:39:31AM -0700, K. Y. Srinivasan wrote: Add the contents of hyperv_storage.h to storvsc_drv.c and cleanup storvsc_drv.c.n I'd at least leave the first half of the header that defines the protocol around. ___ Virtualization

Re: [PATCH 38/40] Staging: hv: storvsc: Fixup srb_status for INQUIRY and MODE_SENSE

2011-06-30 Thread Christoph Hellwig
On Wed, Jun 29, 2011 at 07:39:35AM -0700, K. Y. Srinivasan wrote: The current handler on the Windows Host does not correctly handle INQUIRY and MODE_SENSE commands with some options. Fixup srb_status in these cases since the failure is not fatal. + /* + * The current SCSI handling

Re: [PATCH 38/40] Staging: hv: storvsc: Fixup srb_status for INQUIRY and MODE_SENSE

2011-07-01 Thread Christoph Hellwig
On Thu, Jun 30, 2011 at 07:59:28PM +, KY Srinivasan wrote: The reason I did this was so that I could key off on real failures indicated by srb_status == 0x4 to off-line the device. Ok. Please document what your doing in detail in the code, though.

Re: [PATCH 34/40] Staging: hv: storvsc: Add the contents of hyperv_storage.h to storvsc_drv.c

2011-07-01 Thread Christoph Hellwig
On Thu, Jun 30, 2011 at 08:13:51PM +, KY Srinivasan wrote: Add the contents of hyperv_storage.h to storvsc_drv.c and cleanup storvsc_drv.c.n I'd at least leave the first half of the header that defines the protocol around. I only got rid of the block comment at the start of

Re: [PATCH 24/40] Staging: hv: storvsc: On I/O get the correct IDE device

2011-07-01 Thread Christoph Hellwig
On Thu, Jun 30, 2011 at 09:15:54PM +, KY Srinivasan wrote: That is what I did initially. Then looking at the way we were handling scsi devices where each scsi controller configured for the guest results in an emulated HBA (scsi host) in the guest and all the block devices under a given

Re: [PATCH 23/40] Staging: hv: storvsc: Introduce code to manage IDE devices using storvsc HBA

2011-07-01 Thread Christoph Hellwig
On Thu, Jun 30, 2011 at 09:38:34PM +, KY Srinivasan wrote: +#define HV_MAX_IDE_DEVICES 4 +#define HV_IDE_BASE_CHANNEL 10 +#define HV_IDE0_DEV1 HV_IDE_BASE_CHANNEL +#define HV_IDE0_DEV2 (HV_IDE_BASE_CHANNEL + 1) +#define HV_IDE1_DEV1

Re: [PATCH 00/40] Staging: hv: Driver cleanup

2011-07-01 Thread Christoph Hellwig
On Thu, Jun 30, 2011 at 11:28:27PM +, KY Srinivasan wrote: On Wed, Jun 29, 2011 at 07:38:21AM -0700, K. Y. Srinivasan wrote: Further cleanup of the hv drivers: 1) Cleanup the reference counting mess for both stor and net devices. I really don't understand the need for

Re: [PATCH 24/40] Staging: hv: storvsc: On I/O get the correct IDE device

2011-07-01 Thread Christoph Hellwig
On Fri, Jul 01, 2011 at 01:01:43PM +, KY Srinivasan wrote: Nothing I could see from whatever testing I did. However, the guest will have Scsi hosts that the user did not configure. This is certainly the case in both approaches - just the numbers are different! If the IDE drivers were

Re: [PATCH 020/117] Staging: hv: vmbus: Support the notion of id tables in vmbus_match()

2011-07-15 Thread Christoph Hellwig
On Fri, Jul 15, 2011 at 10:46:08AM -0700, K. Y. Srinivasan wrote: +static bool is_not_null_guid(const __u8 *guid) +{ + int i; + + for (i = 0; i (sizeof(struct hv_vmbus_device_id)); i++) + if (guid[i] != 0) + return true; + return false; +}

Re: [PATCH 097/117] Staging: hv: storvsc: Add code to handle IDE devices using the storvsc driver

2011-07-15 Thread Christoph Hellwig
Thanks, this looks much cleaner than the initial variant. + if (dev_is_ide) { + storvsc_get_ide_info(device, target, path); + host_dev-path = device_info.path_id; + host_dev-target = device_info.target_id; + } else { + host_dev-path =

Re: [PATCH 098/117] Staging: hv: storvsc: Handle IDE devices using the storvsc driver

2011-07-15 Thread Christoph Hellwig
On Fri, Jul 15, 2011 at 10:47:26AM -0700, K. Y. Srinivasan wrote: Now, enable handling of all IDE devices by extending the storvsc device id table to handle IDE guid. As part of this cleanup Kconfig and Hyper-V Makefile to not build the IDE driver (blkvsc). I think this should be part of the

Re: [PATCH 020/117] Staging: hv: vmbus: Support the notion of id tables in vmbus_match()

2011-07-16 Thread Christoph Hellwig
On Sat, Jul 16, 2011 at 12:54:46PM +, KY Srinivasan wrote: would be nice to add uuid_{le,be}_is_nil helpers to uuid.h. I also think simply using a memcpy might be more efficient than the hand-rolled loop. Having a helper function would be great. With regards to the efficiency of this

Re: [PATCH 097/117] Staging: hv: storvsc: Add code to handle IDE devices using the storvsc driver

2011-07-16 Thread Christoph Hellwig
On Sat, Jul 16, 2011 at 04:01:39PM +0300, Sasha Levin wrote: Is think that what Christoph meant was simplifying it to: if (dev_is_ide) storvsc_get_ide_info(device, target, path); host_dev-path = device_info.path_id; host_dev-target =

Re: [RFC] virtio: Support releasing lock during kick

2011-08-10 Thread Christoph Hellwig
Any progress on these patches? ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [PATCH 1 of 5] virtio: document functions better

2011-11-03 Thread Christoph Hellwig
On Thu, Nov 03, 2011 at 06:12:49PM +1030, Rusty Russell wrote: The old documentation is left over from when we used a structure with strategy pointers. Looks good, Reviewed-by: Christoph Hellwig h...@lst.de ___ Virtualization mailing list

Re: [PATCH 2 of 5] virtio: rename virtqueue_add_buf_gfp to virtqueue_add_buf

2011-11-03 Thread Christoph Hellwig
On Thu, Nov 03, 2011 at 06:12:50PM +1030, Rusty Russell wrote: Remove wrapper functions. This makes the allocation type explicit in all callers; I used GPF_KERNEL where it seemed obvious, left it at GFP_ATOMIC otherwise. Looks good, Reviewed-by: Christoph Hellwig h...@lst.de

Re: [PATCH 3 of 5] virtio: support unlocked queue kick

2011-11-03 Thread Christoph Hellwig
On Thu, Nov 03, 2011 at 06:12:51PM +1030, Rusty Russell wrote: Based on patch by Christoph for virtio_blk speedup: Please credit it to Stefan - he also sent a pointer to his original version in reply to the previous thread. Also shouldn't virtqueue_kick have kerneldoc comments? I also notices

Re: [PATCH RESEND 0/5] Add vhost-blk support

2012-07-14 Thread Christoph Hellwig
Please send a version that does direct block I/O similar to xen-blkback for now. If we get proper in-kernel aio support one day you can add back file backend support. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

Re: [RFC-v2 0/4] tcm_vhost+cmwq fabric driver code for-3.6

2012-07-18 Thread Christoph Hellwig
On Wed, Jul 18, 2012 at 08:42:21AM -0500, Anthony Liguori wrote: If you add support for a new command, you need to provide userspace a way to disable this command. If you change what gets reported for VPD, you need to provide userspace a way to make VPD look like what it did in a previous

Re: [PATCH V3 3/3] virtio-blk: Add bio-based IO path for virtio-blk

2012-07-30 Thread Christoph Hellwig
On Mon, Jul 30, 2012 at 09:31:06AM +0200, Paolo Bonzini wrote: You only need to add REQ_FLUSH support. The virtio-blk protocol does not support REQ_FUA, because there's no easy way to do it in userspace. A bio-based driver needs to handle both REQ_FLUSH and REQ_FUA as it does not get the

Re: [PATCH V3 3/3] virtio-blk: Add bio-based IO path for virtio-blk

2012-07-30 Thread Christoph Hellwig
On Mon, Jul 30, 2012 at 12:43:12PM +0800, Asias He wrote: I think we can add REQ_FLUSH REQ_FUA support to bio path and that deserves another patch. Adding it is a requirement for merging the code. ___ Virtualization mailing list

Re: [PATCH V5 4/4] virtio-blk: Add REQ_FLUSH and REQ_FUA support to bio path

2012-08-02 Thread Christoph Hellwig
On Thu, Aug 02, 2012 at 02:25:56PM +0800, Asias He wrote: We need to support both REQ_FLUSH and REQ_FUA for bio based path since it does not get the sequencing of REQ_FUA into REQ_FLUSH that request based drivers can request. REQ_FLUSH is emulated by: 1. Send VIRTIO_BLK_T_FLUSH to device

Re: [PATCH V5 4/4] virtio-blk: Add REQ_FLUSH and REQ_FUA support to bio path

2012-08-06 Thread Christoph Hellwig
On Thu, Aug 02, 2012 at 02:43:04PM +0800, Asias He wrote: Even if it has a payload waiting is highly suboptimal and it should use a non-blocking sequencing like it is done in the request layer. So, for REQ_FLUSH, what we need is that send out the VIRTIO_BLK_T_FLUSH and not to wait. If it's

Re: [PATCH V6 2/2] virtio-blk: Add REQ_FLUSH and REQ_FUA support to bio path

2012-08-07 Thread Christoph Hellwig
At least after review is done I really think this patch sopuld be folded into the previous one. Some more comments below: @@ -58,6 +58,12 @@ struct virtblk_req struct bio *bio; struct virtio_blk_outhdr out_hdr; struct virtio_scsi_inhdr in_hdr; + struct work_struct

Re: [PATCH V6 0/2] Improve virtio-blk performance

2012-08-07 Thread Christoph Hellwig
On Tue, Aug 07, 2012 at 04:47:13PM +0800, Asias He wrote: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%, 17%, 21%, 16% 2) Fusion IO device With bio-based IO path,

Re: [PATCH] vhost-blk: Add vhost-blk support v2

2012-10-09 Thread Christoph Hellwig
+static int vhost_blk_req_submit(struct vhost_blk_req *req, struct file *file) +{ + + struct inode *inode = file-f_mapping-host; + struct block_device *bdev = inode-i_bdev; + int ret; Please just pass the block_device directly instead of a file struct. + + ret =

Re: [PATCH] virtio-blk: make the queue depth the max supportable by the hypervisor

2014-03-15 Thread Christoph Hellwig
On Fri, Mar 14, 2014 at 11:34:31PM -0400, Theodore Ts'o wrote: The current virtio block sets a queue depth of 64, which is insufficient for very fast devices. It has been demonstrated that with a high IOPS device, using a queue depth of 256 can double the IOPS which can be sustained. As

Re: virt_blk BUG: sleeping function called from invalid context

2014-06-29 Thread Christoph Hellwig
On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote: On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote: Hi All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is

Re: [PATCH v3 0/2] block: virtio-blk: support multi vq per virtio-blk

2014-07-01 Thread Christoph Hellwig
On Mon, Jun 30, 2014 at 09:01:07PM -0600, Jens Axboe wrote: I appreciate very much that one of you may queue these two patches into your tree so that userspace work can be kicked off, since Michael has acked both patches and all comments have been addressed already. Given that Michael also

[PATCH] virtio_blk: merge S/G list entries by default

2014-09-06 Thread Christoph Hellwig
the behavior optional, but didn't update the existing drivers to keep their previous behavior. Signed-off-by: Christoph Hellwig h...@lst.de --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index

Re: [PATCH] virtio_blk: merge S/G list entries by default

2014-09-07 Thread Christoph Hellwig
On Sun, Sep 07, 2014 at 02:41:53PM +0300, Michael S. Tsirkin wrote: Signed-off-by: Christoph Hellwig h...@lst.de OK so this is an optimization patch right? What kind of performance gain is observed with it? None. I actually wrote it when the block layer had a bug when dm was used on top

Re: [PATCH] virtio_blk: merge S/G list entries by default

2014-09-08 Thread Christoph Hellwig
On Mon, Sep 08, 2014 at 11:18:30AM +0300, Michael S. Tsirkin wrote: Could you respond to Ming Lei's mail, who benchmarked the patch, please? I don't really have any additional data or disagreement, not sure what I should respond there. ___

Re: [RFC PATCH 4/9] nvmet: add a controller "start" hook

2015-11-19 Thread Christoph Hellwig
On Thu, Nov 19, 2015 at 04:21:03PM -0800, Ming Lin wrote: > #define NVMET_SUBSYS_NAME_LEN256 > charsubsys_name[NVMET_SUBSYS_NAME_LEN]; > + > + void*opaque; > + void(*start)(void *); > }; Why can't vhost

Re: [RFC PATCH 0/9] vhost-nvme: new qemu nvme backend using nvme target

2015-11-19 Thread Christoph Hellwig
Thanks Ming, from a first quick view this looks great. I'll look over it in a bit more detail once I get a bit more time. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

Re: [PATCH] virtio-blk: Generate uevent after attribute available

2016-06-28 Thread Christoph Hellwig
On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that > point we haven't created the serial attribute file, therefore depending > on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get > created. > >

Re: [PATCH v5 00/10] virtio DMA API, yet again

2016-01-31 Thread Christoph Hellwig
On Fri, Jan 29, 2016 at 11:01:00AM +, David Woodhouse wrote: > Also, wasn't Christoph looking at making per-device DMA ops more > generic instead of an 'archdata' thing on basically every platform? Or > did I just imagine that part? What I've done for 4.5 is to switch all architectures to use

Re: [PATCH v3] virtio: new feature to detect IOMMU device quirk

2016-07-25 Thread Christoph Hellwig
On Tue, Jul 19, 2016 at 05:38:23AM +0300, Michael S. Tsirkin wrote: > > On other systems, including SPARC and PPC64, virtio-pci devices are > enumerated as though they are behind an IOMMU, but the virtio host > ignores the IOMMU, so we must either pretend that the IOMMU isn't > there or somehow

Re: [PATCH v4] virtio: new feature to detect IOMMU device quirk

2016-07-28 Thread Christoph Hellwig
Again, this is still the wrong way around. A "noiommu" feature is a quirk and should not be the default. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 00/12] gendisk: Generate uevent after attribute available

2016-06-30 Thread Christoph Hellwig
On Thu, Jun 30, 2016 at 02:35:54PM +0800, Fam Zheng wrote: > also more code and less flexible IMO. For example, we need at least two > variants, for attribute_group and device_attribute separately, right? Yes, or maybe just a calling convention that just passes both.

Re: [PATCH 1/9] virtio_pci: remove struct virtio_pci_vq_info

2017-02-03 Thread Christoph Hellwig
On Fri, Feb 03, 2017 at 03:54:36PM +0800, Jason Wang wrote: >> +list_for_each_entry(vq, _dev->vdev.vqs, list) { >> +if (vq->callback && vring_interrupt(irq, vq) == IRQ_HANDLED) > > The check of vq->callback seems redundant, we will check it soon in > vring_interrupt(). Good point

Re: [PATCH 2/9] virtio_pci: use shared interrupts for virtqueues

2017-02-03 Thread Christoph Hellwig
On Fri, Feb 03, 2017 at 03:54:54PM +0800, Jason Wang wrote: > On 2017年01月27日 16:16, Christoph Hellwig wrote: >> +snprintf(vp_dev->msix_names[i + 1], >> + sizeof(*vp_dev->msix_names), "%s-%s", >>

Re: [PATCH 1/9] virtio_pci: remove struct virtio_pci_vq_info

2017-02-07 Thread Christoph Hellwig
On Tue, Feb 07, 2017 at 03:17:02PM +0800, Jason Wang wrote: > The check is still there. Meh, I could swear I fixed it up. Here is an updated version: --- >From bf5e3b7fd272aea32388570503f00d0ab592fc2a Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <h...@lst.de> Date: Wed, 25 Jan 2

[PATCH 6/9] virtio: provide a method to get the IRQ affinity mask for a virtqueue

2017-02-05 Thread Christoph Hellwig
This basically passed up the pci_irq_get_affinity information through virtio through an optional get_vq_affinity method. It is only implemented by the PCI backend for now, and only when we use per-virtqueue IRQs. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Jason Wang

[PATCH 3/9] virtio_pci: don't duplicate the msix_enable flag in struct pci_dev

2017-02-05 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Jason Wang <jasow...@redhat.com> --- drivers/virtio/virtio_pci_common.c | 5 ++--- drivers/virtio/virtio_pci_common.h | 2 -- drivers/virtio/virtio_pci_legacy.c | 2 +- drivers/virtio/virtio_pci_modern.c | 2 +- includ

[PATCH 1/9] virtio_pci: remove struct virtio_pci_vq_info

2017-02-05 Thread Christoph Hellwig
semantics - we can use a simple array to look up the MSI-X vec if needed. - That simple array now also duoble serves to replace the per_vq_vectors flag Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/virtio/virtio_pci_common.c | 117 +++-- d

  1   2   3   >