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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel