RE: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough

["Kay, Allen M" <allen.m.kay@xxxxxxxxx>]

Attached patches splits vtd and neo changes to tools directory.  Applies
cleanly to staging tree.

Vtd_tools.patch: vt-d and generic changes
Neo_tools.patch: neocleus specific changes

Signed-off-by: Allen Kay <allen.m.kay@xxxxxxxxx>
Signed-off-by: Guy Zana <guy@xxxxxxxxxxxx>

>-----Original Message-----
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>Sent: Tuesday, September 11, 2007 6:05 AM
>To: Kay, Allen M; xen-devel@xxxxxxxxxxxxxxxxxxx
>Cc: Guy Zana
>Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel 
>VT-d/Neocleus 1:1 mreged code for PCI passthrough
>
>On 11/9/07 13:49, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:
>
>> Haven't looked any further at the Xen parts, but I'll take a 
>look at the
>> tools patch...
>
>Looking at the tools patch, I see strange interfaces like
>HVMOP_copy_nativedom_e820_map:
> 1. Why is this an hvm_op unlike other added domctls?
> 2. Why is it needed at all? Can't xc_hvm_build.c work out the 
>memory map
>for itself? It seems like more than necessary is being done in Xen.
>
>Looks like splitting solely pt and solely vtd code into 
>separate patches
>would be a good idea, so the more acdeptable chunks can slide 
>straight in
>without delay.
>
> -- Keir
>

Attachment: vtd_tools.patch
Description: vtd_tools.patch

Attachment: neo_tools.patch
Description: neo_tools.patch

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