[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] size of ctxt.gdt_frames?


  • To: xendevel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tim Wood" <twwood@xxxxxxxxx>
  • Date: Tue, 19 Dec 2006 10:29:45 -0500
  • Delivery-date: Tue, 19 Dec 2006 07:29:37 -0800
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=BjmncaQUyrpZuLYyQlowkkkghD5R59bFGbqI0TGhxVw9k8bZAdLNQX4Gqgi8bklaEs4Mo0yu/y4Tm/Z2I72HmpdrDwIKXT7YtewYHAPP/3V8Ge8u43jRmfR9U/RZm9o/ZZEMk8cEQf+Wvsx3L54wy+l+cofzC/yVlxnl+xAH0t4=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

I think I'm either confused about the gdt_frames variable, or there is
a bug here:

In xen/public/arch-x86_32.h the gdt_frames array is allocated with 16 entries:

189 struct vcpu_guest_context {
...
204     unsigned long gdt_frames[16], gdt_ents; /* GDT (machine
frames, # ents) */
...

however, in the save/restore code, it is referenced as being much larger:

712     for (i = 0; i < ctxt.gdt_ents; i += 512) {
713         pfn = ctxt.gdt_frames[i];
714         if ((pfn >= max_pfn) || (pfn_type[pfn] !=
XEN_DOMCTL_PFINFO_NOTAB)) {
715             ERROR("GDT frame number is bad");
716             goto out;
717         }
718         ctxt.gdt_frames[i] = p2m[pfn];
719     }

(and there is a similar loop in xc_linux_save)

Should lines 713/718 use ctxt.gdt_frames[i/512] ??

-Tim

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.