similar to: blkfront failure on migrate

The self_nmi() code cause''s an NMI to be triggered by sending an APIC message to the local processor. However, NMIs are blocked by the VMEXIT, until the next iret or VMENTER. Volume 3 Chapter 27 Section 1 of the Intel SDM states: An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes. As a result, as soon as the VMENTER happens, an immediate VMEXIT happens

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 +-----

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 @@

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 @@

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 @@

Use PM_FREEZE, PM_THAW and PM_RESTORE power events for suspend/resume/checkpoint functionality, instead of PM_SUSPEND and PM_RESUME. Use of these pm events fixes the Xen Guest hangup when taking checkpoints. When a suspend event is cancelled (while taking checkpoints once/continuously), we use PM_THAW instead of PM_RESUME. PM_RESTORE is used when suspend is not cancelled. See

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

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

We just reported to xenbus that we can't close yet, because blkfront is still in use. So we shouldn't then immediately state that we are closing. Signed-off-by: Andrew Jones <drjones at redhat.com> --- drivers/block/xen-blkfront.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index

We just reported to xenbus that we can't close yet, because blkfront is still in use. So we shouldn't then immediately state that we are closing. Signed-off-by: Andrew Jones <drjones at redhat.com> --- drivers/block/xen-blkfront.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index

We just reported to xenbus that we can't close yet, because blkfront is still in use. So we shouldn't then immediately state that we are closing. Signed-off-by: Andrew Jones <drjones at redhat.com> --- drivers/block/xen-blkfront.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index

This patch makes the needlessly global blkif_getgeo() static. Signed-off-by: Adrian Bunk <bunk@kernel.org> --- 6f34bfdbb8c24e06d982ccaccd24c25dba5b1956 diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 9c6f3f9..ae7ee16 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -136,7 +136,7 @@ static void blkif_restart_queue_callback(void

Frontends are expected to write their protocol ABI to xenstore. Since the protocol ABI defaults to the backend's native ABI, things work fine without that as long as the frontend's native ABI is identical to the backend's native ABI. This is not the case for xen-blkfront running 32-on-64, because its ABI differs between 32 and 64 bit, and thus needs this fix. Based on

Frontends are expected to write their protocol ABI to xenstore. Since the protocol ABI defaults to the backend's native ABI, things work fine without that as long as the frontend's native ABI is identical to the backend's native ABI. This is not the case for xen-blkfront running 32-on-64, because its ABI differs between 32 and 64 bit, and thus needs this fix. Based on

Use bitmap_set and bitmap_clear rather than modifying individual bits in a memory region. Signed-off-by: Akinobu Mita <akinobu.mita at gmail.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge at citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.linux-foundation.org --- drivers/block/xen-blkfront.c |

Use bitmap_set and bitmap_clear rather than modifying individual bits in a memory region. Signed-off-by: Akinobu Mita <akinobu.mita at gmail.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge at citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.linux-foundation.org --- drivers/block/xen-blkfront.c |

Hi all, I want to use ionice command change the priority of threads of blkback(in domain0) for each corresponding blkfront . However, I do not know how to recognize which is the thread for the corresponding blkfront using ps aux. Anybody can give me some advice? Thanks in advance! -- View this message in context:

hi all, I have just ported pvonhvm drivers to ubuntu 10.10(2.6.35), for ubuntu 10.10 was comply to the pvops, so it has it''s own blkfront, so I just add platform-pci to ubuntu 10.10 source, and then compile, that''s ok, then I start the ubuntu 10.10 with pvonhvm, the domU can boot successfully, but after running a moment, it give the such warnings: INFO: task

hi all, I have just ported pvonhvm drivers to ubuntu 10.10(2.6.35), for ubuntu 10.10 was comply to the pvops, so it has it''s own blkfront, so I just add platform-pci to ubuntu 10.10 source, and then compile, that''s ok, then I start the ubuntu 10.10 with pvonhvm, the domU can boot successfully, but after running a moment, it give the such warnings: INFO: task

Hi, Here is the refreshed version of the multi-page ring patch for blkfront and blkback. I currently don''t have time to refresh the blktap part of the patch. The patch should apply cleanly to the following changeset in the linux 2.6.18 tree: changeset: 752:0b859c9516ba tag: qparent parent: 751:6591b4869889 parent: 748:5012c470f875 user: Keir Fraser