WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [RFC][PATCH 0/6] HVM PCI Passthrough (non-IOMMU)

To: "John Byrne" <john.l.byrne@xxxxxx>
Subject: RE: [Xen-devel] [RFC][PATCH 0/6] HVM PCI Passthrough (non-IOMMU)
From: "Guy Zana" <guy@xxxxxxxxxxxx>
Date: Sat, 9 Jun 2007 01:55:41 -0400
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
Delivery-date: Fri, 08 Jun 2007 22:56:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <466A0FA2.2020804@xxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceqPXsg+iffOFT8RuGDSBMrmR8AewAGfzGQ
Thread-topic: [Xen-devel] [RFC][PATCH 0/6] HVM PCI Passthrough (non-IOMMU)
 

> -----Original Message-----
> From: John Byrne [mailto:john.l.byrne@xxxxxx] 
> Sent: Saturday, June 09, 2007 5:26 AM
> To: Guy Zana
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Kay, Allen M; Tian, Kevin
> Subject: Re: [Xen-devel] [RFC][PATCH 0/6] HVM PCI Passthrough 
> (non-IOMMU)
> 

> 
> I'd missed the line in your patch zero e-mail about 
> pass-through.c. Once I'd fixed that and with your hint about 
> MSI-interrupts, I passed the disable_msi option to the bnx2 
> driver and things worked, at least for a while. I could get a 
> ssh connection going through the interface, but the machine 
> locked up. My 32-bit machine doesn't have a lot of memory, so 
> things are sluggish and it is hard to tell lock-ups from 
> thrashing. I will reinstall one of my 64-bit machines that 
> has more memory as 32-bits and try it there.

That trashing could be caused by the 1:1 mapping. The only downside of using 
the 1-to-1 mapping right now is that the region 0-12MB is remapped to 16-28MB, 
so all guest's DMA operations with buffers allocated from the 0-12MB region 
would fail. That region is remapped because Xen (code & data) lives there, and 
this is the main reason for moving to x86_64, there Xen is relocated to higher 
memory and the 0-12MB region can be mapped in a 1:1 fashion.

If you can enforce your linux guest to allocate dma buffers from above the 12MB 
address you can avoid that problem, you can also log the dma descriptors and 
see if the problem is because of that.

> 
> Just let me know what you need tested and I'll see what I can do.
> 

Thanks, I appreciate it.

> > 
> > Cool idea! Our CTO thought about it as well :) It's kind of 
> hard not 
> > to use the VT page-fault handler at all, there are some issues with 
> > memory protection (security), and memory-remapping that we 
> would want 
> > to do in the future (In order to support bios & expansion ROM 
> > duplication). I agree that you can make it faster though! it may 
> > require some drastic changes in the hypervisor.
> 
> Without an IOMMU, you forfeit memory protection, anyway, so I 

That's not completely true!
We have found ways to restrict memory access to a specific region on specific 
chipsets.

> am willing to handwave security for the moment. For VT, at 
> the moment, it looks like I might be able to just hack 
> something to set the VMCS to disable page faults after the 
> domain is running. Setting CR3 will still generate a fault, 
> but all you need to do is set the real CR3, as far as I can 
> tell. It may not really work out, but I'm going to try.
> 

It's interesting to see the result of that. 
Keep in mind that you'll have to provide memory remapping (you don't want to 
run over the real bios or expansion ROMs!) by updating the page-tables, I'm not 
sure how would you track updates without the page-fault exit.

Thanks,
Guy.

> Thanks,
> 
> John
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>