Re: [Xen-devel] [PATCH] Refactor ioreq server for better performance

["Yu, Zhang" <yu.c.zhang@xxxxxxxxxxxxxxx>]

[snip]

> > Thanks, Paul.
> > Well, I agree the former approach would be simpler. But I still doubt
> > if this is more reasonable. :)
> > IIUC, one of the reasons for struct domain to have a rangeset list(and
> > a spinlock - rangesets_lock), is because there are iomem_caps and
> > irq_caps for each domain. These 2 rangeset members of struct domain are
> > platform independent.
> > However, struct rb_rangeset is only supposed to be used in ioreq
> > server, which is only for x86 hvm cases. Adding a rb_rangeset list
> > member(similarly, if so, a rb_rangesets_lock is also required) in
> > struct domain maybe useless for hardware domain and for platforms other
> > than x86.
> Fair enough.
>
> > So, I'd like to register a new debug key, to dump the ioreq server
> > informations, just like the keys to dump iommu p2m table or the irq
> > mappings. With a new debug key, we do not need to add a spinlock for
> > rb_rangeset in struct domain, the one in ioreq server would be enough.
> > Does this sound reasonable?
> That would be ok with me, but I'm not sure about claiming a whole debug key for 
> this. Is there any other one that you could piggy-back on? If not, then maybe 
> just make it part of the 'q' output.
Thanks, my new implementation uses the 'q' debug key. Will send out the
new version later. :)

Yu
>    Paul
[snip]

> > > > > _______________________________________________
> > > > > Xen-devel mailing list
> > > > > Xen-devel@xxxxxxxxxxxxx
> > > > > http://lists.xen.org/xen-devel
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxx
> > > http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel