Well, i can't compile the last xen-unstable, due to the following error:
multi.c: In function גsh_page_fault__guest_2ג:
multi.c:3114: error: גSHUTDOWN_crashג undeclared (first use in this function)
multi.c:3114: error: (Each undeclared identifier is reported only once
multi.c:3114: error: for each function it appears in.)
make[6]: *** [guest_2.o] Error 1
So, i'm trying to revert back, to see if i can compile it...
On Wed, Oct 7, 2009 at 2:02 PM, Simon Horman <horms@xxxxxxxxxxxx> wrote:
> On Wed, Oct 07, 2009 at 11:56:39AM +0200, Tom Rotenberg wrote:
>> Hi,
>>
>> How can i check it?
>>
>> (BTW - I'm using the Xen 3.4 testing tree, with your multi-function
>> support patches.)
>
> Hi Tom,
>
> The thing is that there is a fairly tight coupling between
> xm, xend, qemu-xen and hvmloader for PCI pass-through. Several
> of the changes to pass-through, including the expansion of
> the available slot range from 2 (slots 6 & 7) to any available slot,
> required these components to be updated in lock-step.
>
> If you checked out one of my xen-testing trees and let its build check-out
> qemu-xen, and you are using the xm, xend, qemu-xen and hvmloader that
> result from that build then the versions should be ok. Unfortunately there
> aren't ABI versions or anything convenient like that which you can check to
> make sure :-(
>
> Could you try a fresh checkout and build and verify that the
> problem persists? And if it does, could you let me know which
> changesets of which xen and xen-qemu trees you end up with so
> I can try and reproduce the problem.
>
> An out of step hvmloader could explain the problem you are seeing
> (I think I experienced the same thing while adding support for slots
> other than 6 & 7). But of course, there could be other causes too.
>
> Lastly, I'm more than happy for this discussion to take place on xen-devel.
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|