similar to: [PATCH] blkfront: don't change to closing if we're busy

Displaying 20 results from an estimated 700 matches similar to: "[PATCH] blkfront: don't change to closing if we're busy"

2012 Feb 16
2
[PATCH] blkfront: don't put bdev right after getting it
We should hang onto bdev until we're done with it. Signed-off-by: Andrew Jones <drjones at redhat.com> --- drivers/block/xen-blkfront.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 2f22874..5d45688 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1410,7 +1410,6
2012 Feb 16
2
[PATCH] blkfront: don't put bdev right after getting it
We should hang onto bdev until we're done with it. Signed-off-by: Andrew Jones <drjones at redhat.com> --- drivers/block/xen-blkfront.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 2f22874..5d45688 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1410,7 +1410,6
2011 Sep 01
9
[PATCH V4 0/3] xen-blkfront/blkback discard support
Dear list, This is the V4 of the trim support for xen-blkfront/blkback, Now we move BLKIF_OP_TRIM to BLKIF_OP_DISCARD, and dropped all "trim" stuffs in the patches, and use "discard" instead. Also we updated the helpers of blkif_x86_{32|64}_request or we will meet problems using a non-native protocol. And this patch has been tested with both SSD and raw file, with SSD we will
2013 May 13
22
[PATCH] xen-blk(front|back): Handle large physical sector disks
I accidentally realized today that any domU''s using the paravirt disk driver potentially suffer from poor performance when they get handed in a physical volume and partitioning is done inside the guest. The physical volume passed in has to be one that has the compat 512 logical sector size but hints its real sector size (eg. 4096) as physical sector size. In dom0 handling is correct and
2013 Feb 28
0
[PATCH RFC 05/12] xen-blkfront: remove frame list from blk_shadow
We already have the frame (pfn of the grant page) stored inside struct grant, so there's no need to keep an aditional list of mapped frames for a specific request. This reduces memory usage in blkfront. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: xen-devel@lists.xen.org --- drivers/block/xen-blkfront.c | 6 +-----
2009 May 11
1
[PATCH] xen/blkfront: remove driver_data direct access of struct device
To avoid direct access to the driver_data pointer in struct device, the functions dev_get_drvdata() and dev_set_drvdata() should be used. Signed-off-by: Roel Kluin <roel.kluin at gmail.com> --- diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8f90508..ff09809 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -755,12 +755,12 @@
2009 May 11
1
[PATCH] xen/blkfront: remove driver_data direct access of struct device
To avoid direct access to the driver_data pointer in struct device, the functions dev_get_drvdata() and dev_set_drvdata() should be used. Signed-off-by: Roel Kluin <roel.kluin at gmail.com> --- diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8f90508..ff09809 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -755,12 +755,12 @@
2009 May 11
1
[PATCH] xen/blkfront: remove driver_data direct access of struct device
To avoid direct access to the driver_data pointer in struct device, the functions dev_get_drvdata() and dev_set_drvdata() should be used. Signed-off-by: Roel Kluin <roel.kluin at gmail.com> --- diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8f90508..ff09809 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -755,12 +755,12 @@
2011 Mar 31
3
[PATCH RESEND] net: convert xen-netfront to hw_features
Not tested in any way. The original code for offload setting seems broken as it resets the features on every netback reconnect. This will set GSO_ROBUST at device creation time (earlier than connect time). RX checksum offload is forced on - so advertise as it is. Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> --- [I don't know Xen code enough to say this is correct. There
2011 Mar 31
3
[PATCH RESEND] net: convert xen-netfront to hw_features
Not tested in any way. The original code for offload setting seems broken as it resets the features on every netback reconnect. This will set GSO_ROBUST at device creation time (earlier than connect time). RX checksum offload is forced on - so advertise as it is. Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> --- [I don't know Xen code enough to say this is correct. There
2011 Mar 31
3
[PATCH RESEND] net: convert xen-netfront to hw_features
Not tested in any way. The original code for offload setting seems broken as it resets the features on every netback reconnect. This will set GSO_ROBUST at device creation time (earlier than connect time). RX checksum offload is forced on - so advertise as it is. Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> --- [I don't know Xen code enough to say this is correct. There
2011 Sep 09
7
[PATCH] xen-blk[front|back] FUA additions.
I am proposing these two patches for 3.2. They allow the backend to process the REQ_FUA request as well. Previous to these patches it only did REQ_FLUSH. There is also a bug-fix for the logic of how barrier/flushes were handled. The patches are based on a branch which also has ''feature-discard'' patches, so they won''t apply nativly on top of 3.1-rc5. Please review and
2012 Sep 19
27
[PATCH] Persistent grant maps for xen blk drivers
This patch implements persistent grants for the xen-blk{front,back} mechanism. The effect of this change is to reduce the number of unmap operations performed, since they cause a (costly) TLB shootdown. This allows the I/O performance to scale better when a large number of VMs are performing I/O. Previously, the blkfront driver was supplied a bvec[] from the request queue. This was granted to
2013 May 21
1
[PATCH net-next V2 2/2] xen-netfront: split event channels support for Xen frontend driver
This patch adds a new feature called feature-split-event-channels for netfront, enabling it to handle TX and RX events separately. If netback does not support this feature, it falls back to use single event channel. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> --- drivers/net/xen-netfront.c | 173
2007 Apr 18
24
[patch 00/24] Xen-paravirt_ops: Xen guest implementation for paravirt_ops interface
Hi Andi, This patch series implements the Linux Xen guest as a paravirt_ops backend. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen hvc console (console=hvc0) *
2007 Apr 18
24
[patch 00/24] Xen-paravirt_ops: Xen guest implementation for paravirt_ops interface
Hi Andi, This patch series implements the Linux Xen guest as a paravirt_ops backend. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen hvc console (console=hvc0) *
2007 Apr 18
24
[patch 00/24] Xen-paravirt_ops: Xen guest implementation for paravirt_ops interface
Hi Andi, This patch series implements the Linux Xen guest as a paravirt_ops backend. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen hvc console (console=hvc0) *
2008 Feb 21
4
[PATCH 0/2] xen pvfb: Para-virtual framebuffer, keyboard and pointer
This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. I started with the Xen version at http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/ca05cf1a9bdc Differences to that Xen version, for those who care: * Rewritten on top of fb deferred
2008 Feb 21
4
[PATCH 0/2] xen pvfb: Para-virtual framebuffer, keyboard and pointer
This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. I started with the Xen version at http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/ca05cf1a9bdc Differences to that Xen version, for those who care: * Rewritten on top of fb deferred
2008 Feb 21
4
[PATCH 0/2] xen pvfb: Para-virtual framebuffer, keyboard and pointer
This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. I started with the Xen version at http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/ca05cf1a9bdc Differences to that Xen version, for those who care: * Rewritten on top of fb deferred