On 16/02/17 14:30, Jan Beulich wrote:
On 16.02.17 at 14:42, wrote:
>> I'm really sorry, but I did not get your point here:
>>
>>> This concern makes me assume there might be quite many of them,
>>> which then makes this a no-go for unprivileged domains.
>>
>> Could you please provide wider ex
>>> On 16.02.17 at 14:42, wrote:
> I'm really sorry, but I did not get your point here:
>
>> This concern makes me assume there might be quite many of them,
>> which then makes this a no-go for unprivileged domains.
>
> Could you please provide wider explanation.
Well, as it had been discussed
> The relevant patch is:
>
> https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg01619.html
Thank you for the link.
I would try to realize why it is left unmerged.
Sincerely,
Andrii Anisov.
2017-02-16 16:02 GMT+02:00 Paul Durrant :
>> -Original Message-
>> From: Andrii Aniso
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 13:24
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew
> Cooper ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; sstabel
Dear Jan,
I'm really sorry, but I did not get your point here:
> This concern makes me assume there might be quite many of them,
> which then makes this a no-go for unprivileged domains.
Could you please provide wider explanation.
Sincerely,
Andrii Anisov.
_
Dear Jan,
> If this is meant to be per-domain management - how many such
> ranges do you expect to be necessary for any one domain? We've
> had attempts before to (ab)use rangesets for such a purpose.
It is meant to be the per-domain management. To handle per-domain
vcoproc register access emulati
>>> On 16.02.17 at 13:45, wrote:
> Dear Paul,
>
>> The cleanup seems a good thing to do to me.
>
> So I would collect comments, rebase it to latest master and push the
> second version without RFC.
>
>> Any particular reason this series is RFC?
>
> The reason to make this series was an intenti
Paul,
> Many moons ago there were patches to use rbtree for rangesets. Perhaps it
> would be worth reviving that idea?
Do you have a link to look at those patches?
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://li
Dear Paul,
> Many moons ago there were patches to use rbtree for rangesets. Perhaps it
> would be worth reviving that idea?
rbtree is a thing I think of now for our needs.
Even more, currently I think of refactoring ARM mmio ranges managing
to use rbtree one day. Currently there is a static array
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 12:46
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew
> Cooper ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; sstabel
Dear Paul,
> The cleanup seems a good thing to do to me.
So I would collect comments, rebase it to latest master and push the
second version without RFC.
> Any particular reason this series is RFC?
The reason to make this series was an intention to use rangesets to
manage mmio ranges in our sha
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 12:03
> To: xen-de...@lists.xenproject.org
> Cc: andrii_ani...@epam.com; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; Paul Durrant
> ; sstab
From: Andrii Anisov
Rangesets in XEN seems to be a pretty generic thing slightly poisoned with.
domain specific funtionality in initialization and deinitialization code.
So make the rangeset code generic with moving domain specific code to
common/domain.c
Andrii Anisov (6):
rangeset_new() ref
13 matches
Mail list logo
