[PATCH Master]

[PATCH Master]

[Konrad Rzeszutek Wilk]

Jeremy,

Please apply the bug fix to the origin/xen/master branch.

Originally I was thinking it should go to to origin/xen/dom0/swiotlb-new,
but that has a different logic that in which this patch would not
work properly (the drivers/pci/xen-iommu.c initializes itself irregardless
if the Xen-SWIOTLB had been initialized before). I would have
posted a couple of patches for that branch (swiotlb-new) but alas,
I am going to be on vacation for the next couple of days.

[PATCH] [xen/swiotlb] Enable Xen-SWIOTLB only if running in privileged domain or if in non-privileged with iommu=soft.

[Konrad Rzeszutek Wilk]

Previous to this patch we would unconditionally enable Xen-SWIOTLB
if running in PV context. That does not work with Xen 3.4.2 as it has a
security check to disable exchanging of MFNs if no PCI devices have been
passed through. In 4.0 there is an additional check to allow 2MB super-pages
- we accidentally circumvented that by exchanging pages under the 2MB chunk size
even without any PCI devices passed through.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb.c |    6 ++++--
 drivers/pci/xen-pcifront.c |    2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb.c b/arch/x86/xen/pci-swiotlb.c
index ecdbfe2..6195eb9 100644
--- a/arch/x86/xen/pci-swiotlb.c
+++ b/arch/x86/xen/pci-swiotlb.c
@@ -960,7 +960,8 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 				dma_bits);
 		} while (rc && dma_bits++ < max_dma_bits);
 		if (rc)
-			panic(KERN_ERR "xen_create_contiguous_region failed\n");
+			panic(KERN_ERR "xen_create_contiguous_region failed: "
+				"rc: %d\n", rc);
 
 		i += slabs;
 	} while(i < nslabs);
@@ -984,7 +985,8 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 
 void __init xen_swiotlb_init(void)
 {
-	if (xen_domain()) {
+	/* For PV guest, only if iommu=soft is passed in. */
+	if (xen_pv_domain() && (xen_initial_domain() || swiotlb)) {
 		printk(KERN_INFO "PCI-DMA: Using Xen software bounce buffering for IO (Xen-SWIOTLB)\n");
 		xen_swiotlb_init_with_default_size(64 * (1<<20));	/* default to 64MB */
 		dma_ops = &xen_swiotlb_dma_ops;
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index cc3b51b..3436202 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -1052,6 +1052,8 @@ static void __init_refok pcifront_backend_changed(struct xenbus_device *xdev,
 	case XenbusStateInitWait:
 	case XenbusStateInitialised:
 	case XenbusStateClosed:
+		dev_warn(&xdev->dev, "Device is in %d state. Need to change "
+			"state on the privileged domain.\n", be_state);
 		break;
 
 	case XenbusStateConnected:
-- 
1.6.2.5

Re: [PATCH Master]

[Jeremy Fitzhardinge]

On 12/22/2009 11:04 AM, Konrad Rzeszutek Wilk wrote:
> Originally I was thinking it should go to to origin/xen/dom0/swiotlb-new,
> but that has a different logic that in which this patch would not
> work properly (the drivers/pci/xen-iommu.c initializes itself irregardless
> if the Xen-SWIOTLB had been initialized before).

Are you saying that the logic of xen/master is different from its 
constituent branches?

>   I would have
> posted a couple of patches for that branch (swiotlb-new) but alas,
> I am going to be on vacation for the next couple of days.
>    

No problem.  I'm taking a long break over Christmas/NY (visit family in 
Australia) and will be back on Jan 18th.  I expect I'll be tracking 
email, but I won't be doing anything major.

     J

Re: [PATCH Master]

[Konrad Rzeszutek Wilk]

On Tue, Dec 22, 2009 at 12:17:54PM -0800, Jeremy Fitzhardinge wrote:
> On 12/22/2009 11:04 AM, Konrad Rzeszutek Wilk wrote:
>> Originally I was thinking it should go to to origin/xen/dom0/swiotlb-new,
>> but that has a different logic that in which this patch would not
>> work properly (the drivers/pci/xen-iommu.c initializes itself irregardless
>> if the Xen-SWIOTLB had been initialized before).
>
> Are you saying that the logic of xen/master is different from its  
> constituent branches?

Yes for the SWIOTLB. You added the 'xen_swiotlb' flag which is not yet
in the xen/master tree.
>
>>   I would have
>> posted a couple of patches for that branch (swiotlb-new) but alas,
>> I am going to be on vacation for the next couple of days.
>>    
>
> No problem.  I'm taking a long break over Christmas/NY (visit family in  
> Australia) and will be back on Jan 18th.  I expect I'll be tracking  
> email, but I won't be doing anything major.

Enjoy your holidays!

(the posting to the other branches are not that important - they can
wait after New Year).