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

[MaoXiaoyun <tinnycloud@xxxxxxxxxxx>]

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)

log.txt
Description: Text document

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