WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: [PATCH] mem_sharing: fix race condition of nominate and

Hi Tim:
 
      Sorry for the inconvenience, I think it's better now when I reply directly from hotmail.
      
      It looks like when unshare(), page_set_owner is forgetten, right?
      Since after I add this code the Error log is disappeared.
 
 
     But unfortunately, I meet HVM blue screen(windows) with serial output below.
     Full log attached.
 
(XEN) ==>3Debug for domain=1, gfn=7de15, Debug page: MFN=171c15 is ci=8000000000000001, ti=0, owner_id=1
(XEN) ===hvm_hap_nested_page_fault mfn 171fd6 p2mt d gfn 515542 did 1
(XEN) ===mem_sharing_unshare_page cpu 12 mfn 171fd6 p2mt d gfn 515542 did 1
(XEN) ==>3Debug for domain=1, gfn=7ddd6, Debug page: MFN=171fd6 is ci=8000000000000001, ti=0, owner_id=1
(XEN) ===hvm_hap_nested_page_fault mfn 171c57 p2mt d gfn 515671 did 1
(XEN) ===mem_sharing_unshare_page cpu 12 mfn 171c57 p2mt d gfn 515671 did 1
(XEN) ==>3Debug for domain=1, gfn=7de57, Debug page: MFN=171c57 is ci=8000000000000001, ti=0, owner_id=1
(XEN) printk: 32 messages suppressed.
(XEN) grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff (domain 1)
(XEN) grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff (domain 1)
(XEN) grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff (domain 1)
(XEN) grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff (domain 1)
(XEN) grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff (domain 1)
(XEN) grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff (domain 1)
(XEN) grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff (domain 1)
(XEN) grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff (domain 1)
(XEN) grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff (domain 1)
(XEN) grant_table.c:555:d0 Iomem mapping not permitted ffffffffffffffff (domain 1)

 
> Date: Mon, 10 Jan 2011 10:30:41 +0000
> From: Tim.Deegan@xxxxxxxxxx
> To: juihaochiang@xxxxxxxxx
> CC: tinnycloud@xxxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH] mem_sharing: fix race condition of nominate and unshare
>
> Hi,
>
> Can you please (both of you) sort out yout mail clients to do proper
> indenting of quoted text? The plain-text versions don't have any
> quote prefix, which makes them confusing to read.
>
> At 04:57 +0000 on 10 Jan (1294635461), Jui-Hao Chiang wrote:
> > Hi, Tim:
> >
> > On Sat, Jan 8, 2011 at 12:09 AM, Tim Deegan <Tim.Deegan@xxxxxxxxxx<mailto:Tim.Deegan@xxxxxxxxxx>> wrote:
> > At 06:02 +0000 on 07 Jan (1294380120), Jui-Hao Chiang wrote:
> > > One of the solution is to
> > > (a) Simply replace shr_lock with p2m_lock.
> >
> > I think this is the best choice. If we find that the p2m lock is a
> > bottleneck we can address it later.
> >
> >
> > Just to be skeptic.
> > Why doesn't mfn_to_gfn() take p2m lock when querying the p2m type?
>
> Because gfn->mfn lookups happen very frequently and requiring the lock
> would be a performance bottleneck on multi-vcpu guests.
>
> > Is there any quarantee that the resulting type is correct and trustful?
>
> Yes. It's not perfect (and as I said I need to overhaul the locking
> here) but if the p2m lookup only reads each level once and the p2m
> updates are careful about the order they change things in, the worst
> that can happen is another CPU sees a slightly out-of-date value.
>
> There is at least one issue there (now that some p2m code frees old p2m
> pages there's a potential race against other readers that needs a
> tlbflush-timestamp-style interlock), b ut TBH there are other things that
> need fixing first.
>
> Tim.
>
> > For example:
> > (1) User1 query the p2m type:
> > mfn_to_gfn(...&p2mt);
> > if (p2mt == p2m_ram_rw) /* do something based on the p2m type result? */
> >
> > (2) User2 modify the p2m type
> > p2m_lock(p2m);
> > set_p2m_entry(..... p2m_ram_rw);
> > p2m_unlock(p2m);
> >
> > Thanks,
> > Jui-Hao
>
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, Xen Platform Team
> Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)

Attachment: log.txt
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>