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