Merging PCI pass-through code

Merging PCI pass-through code

[Guy Zana]

[-- Attachment #1.1: Type: text/plain, Size: 1148 bytes --]

Hi,
 
Since both Neocleus' solution & Intel's solution have overlapping
implementations, we should determine what should stays and what goes.
There is a question on how should we do the merge?
 
Here are a number of issues that we should address:
 
1. We should really create a separate tree and have the merging done
outside of the main unstable tree.
2. Neocleus will use your configuration interface to assign pci devices.
3.1 The lpci library - I think it is best to merge Intel's code with
what we have in our implementation of libpci, and you can add your
functions to our library.
3.2 Your implementation doesn't read/write to the real PCI config space,
I'm not sure that all devices would like that :)
4. Pass-through initialization should be done regardless of an iommu
present.
5. What type of interrupt handling is the way to go? I can't compare the
polarity-change with your method since I don't have an IOMMU machine...
6. Does the PIO/MMIO access functions in qemu-dm (Neocleus') are needed?
(It's good for debugging)
7. The 1:1 mapping and specific-iommu code can be merged separately.
 
 
Thanks,
Guy.
 

[-- Attachment #1.2: Type: text/html, Size: 3488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Merging PCI pass-through code

[Keir Fraser]

[-- Attachment #1.1: Type: text/plain, Size: 1611 bytes --]

On 3/6/07 17:52, "Guy Zana" <guy@neocleus.com> wrote:

> Since both Neocleus' solution & Intel's solution have overlapping
> implementations, we should determine what should stays and what goes.
> There is a question on how should we do the merge?
>  
I like the idea of a separate tree, just for the short term, as a shared
workspace for merging and development and bug fixing. I can arrange to
create a new repo called xen-hvm-directio.hg (or a better name if you can
think of one)? From the list of points below it sounds like both sets of
patches need some work, quite apart from the required merging. Would this
method of development suit everyone?

 -- Keir
> 
> Here are a number of issues that we should address:
>  
> 1. We should really create a separate tree and have the merging done outside
> of the main unstable tree.
> 2. Neocleus will use your configuration interface to assign pci devices.
> 3.1 The lpci library - I think it is best to merge Intel's code with what we
> have in our implementation of libpci, and you can add your functions to our
> library.
> 3.2 Your implementation doesn't read/write to the real PCI config space, I'm
> not sure that all devices would like that :)
> 4. Pass-through initialization should be done regardless of an iommu present.
> 5. What type of interrupt handling is the way to go? I can't compare the
> polarity-change with your method since I don't have an IOMMU machine...
> 6. Does the PIO/MMIO access functions in qemu-dm (Neocleus') are needed? (It's
> good for debugging)
> 7. The 1:1 mapping and specific-iommu code can be merged separately.
>  



[-- Attachment #1.2: Type: text/html, Size: 2392 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Merging PCI pass-through code

[Muli Ben-Yehuda]

On Mon, Jun 04, 2007 at 10:44:37AM +0100, Keir Fraser wrote:
> On 3/6/07 17:52, "Guy Zana" <guy@neocleus.com> wrote:
> 
> > Since both Neocleus' solution & Intel's solution have overlapping
> > implementations, we should determine what should stays and what goes.
> > There is a question on how should we do the merge?
>
> I like the idea of a separate tree, just for the short term, as a
> shared workspace for merging and development and bug fixing. I can
> arrange to create a new repo called xen-hvm-directio.hg (or a better
> name if you can think of one)? From the list of points below it
> sounds like both sets of patches need some work, quite apart from
> the required merging. Would this method of development suit
> everyone?

Fine by me, provided the end result still shows up on the list for
review before it gets pulled. I do think however that a shared tree
will only be useful if there will be a gate-keeper who will decide
what goes in and what doesn't (based on consensus ). And once there
are bits of the patches that everyone agrees should go in, they could
just go to xen-unstable directly and skip the merge tree...

Cheers,
Muli