Han, Weidong
2008-Jul-24 09:22 UTC
[Xen-devel] domain destory path is not correct on c/s 18117
When poweroff a domain, even arch_domain_destroy() is not called. I located this is introduced by c/s 18117. This bug results in a device cannot be assigned twice. Randy (Weidong) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jul-24 09:55 UTC
Re: [Xen-devel] domain destory path is not correct on c/s 18117
I''ll see if it''s an obvious bug to fix, or I''ll revert the changeset. Thanks, Keir On 24/7/08 10:22, "Han, Weidong" <weidong.han@intel.com> wrote:> When poweroff a domain, even arch_domain_destroy() is not called. I > located this is introduced by c/s 18117. This bug results in a device > cannot be assigned twice. > > Randy (Weidong) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2008-Jul-24 09:56 UTC
Re: [Xen-devel] domain destory path is not correct on c/s 18117
On Thursday 24 July 2008 11:22:43 Han, Weidong wrote:> When poweroff a domain, even arch_domain_destroy() is not called. I > located this is introduced by c/s 18117. This bug results in a device > cannot be assigned twice.That works for PV domains. I think, "pages" in tools/libxc/xc_hvm_build.c is not calculated correctly. Using an unsigned type for "pages" is the only functional change for Linux and Solaris in c/s 18117. Christoph -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2008-Jul-24 10:13 UTC
Re: [Xen-devel] domain destory path is not correct on c/s 18117
On Thursday 24 July 2008 11:56:44 Christoph Egger wrote:> On Thursday 24 July 2008 11:22:43 Han, Weidong wrote: > > When poweroff a domain, even arch_domain_destroy() is not called. I > > located this is introduced by c/s 18117. This bug results in a device > > cannot be assigned twice. > > That works for PV domains. > > I think, "pages" in tools/libxc/xc_hvm_build.c is not calculated > correctly. Using an unsigned type for "pages" is the only functional > change for Linux and Solaris in c/s 18117.I just figured out, the call to arch_domain_destroy() is delayed until Dom0 shutdown/reboot. Changing "pages" back to int doesn''t fix this. Keir: I suppose, c/s 18117 exposes a long standing hidden bug. Reverting c/s 18117 just hides it again. Christoph -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jul-24 10:20 UTC
Re: [Xen-devel] domain destory path is not correct on c/s 18117
On 24/7/08 11:13, "Christoph Egger" <Christoph.Egger@amd.com> wrote:> I just figured out, the call to arch_domain_destroy() is delayed until Dom0 > shutdown/reboot. > Changing "pages" back to int doesn''t fix this. > > Keir: I suppose, c/s 18117 exposes a long standing hidden bug. > Reverting c/s 18117 just hides it again.Or you removed the munmap() from the tail of loadelfimage(). Putting it back fixes the bug. Changeset 18118. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2008-Jul-24 11:23 UTC
Re: [Xen-devel] domain destory path is not correct on c/s 18117
On Thursday 24 July 2008 12:20:50 Keir Fraser wrote:> On 24/7/08 11:13, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > > I just figured out, the call to arch_domain_destroy() is delayed until > > Dom0 shutdown/reboot. > > Changing "pages" back to int doesn''t fix this. > > > > Keir: I suppose, c/s 18117 exposes a long standing hidden bug. > > Reverting c/s 18117 just hides it again. > > Or you removed the munmap() from the tail of loadelfimage(). Putting it > back fixes the bug. Changeset 18118.Ah, right. I didn''t notice that munmap() was called in both failure and _succuss_ case of xc_map_foreign_ranges(). Thanks for fixing this. Christoph -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jul-24 12:06 UTC
Re: [Xen-devel] domain destory path is not correct on c/s 18117
On 24/7/08 12:23, "Christoph Egger" <Christoph.Egger@amd.com> wrote:>> Or you removed the munmap() from the tail of loadelfimage(). Putting it >> back fixes the bug. Changeset 18118. > > Ah, right. I didn''t notice that munmap() was called in both failure and > _succuss_ case of xc_map_foreign_ranges(). > Thanks for fixing this.''out'' would have been a more appropriate label than ''err''. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel