On 11.12.2023 20:40, Oleksii wrote:
> On Mon, 2023-12-11 at 18:49 +0100, Jan Beulich wrote:
>> On 11.12.2023 18:37, Oleksii wrote:
>>> On Mon, 2023-12-11 at 17:02 +0100, Jan Beulich wrote:
In which case the approach taken here may be fine, but
it still wouldn't be what I suggested. It ma
On Mon, 2023-12-11 at 18:49 +0100, Jan Beulich wrote:
> On 11.12.2023 18:37, Oleksii wrote:
> > On Mon, 2023-12-11 at 17:02 +0100, Jan Beulich wrote:
> > > In which case the approach taken here may be fine, but
> > > it still wouldn't be what I suggested. It may then be Stefano or
> > > Andrew
> >
On 11.12.2023 18:37, Oleksii wrote:
> On Mon, 2023-12-11 at 17:02 +0100, Jan Beulich wrote:
>> In which case the approach taken here may be fine, but
>> it still wouldn't be what I suggested. It may then be Stefano or
>> Andrew
>> who you could consider for such a tag.
> I'm a bit confused again.
On Mon, 2023-12-11 at 17:02 +0100, Jan Beulich wrote:
> On 11.12.2023 15:43, Oleksii wrote:
> > On Mon, 2023-12-04 at 11:39 +0100, Jan Beulich wrote:
> > > On 04.12.2023 11:34, Oleksii wrote:
> > > > If you ( or anyone else ) don't mind, I'll update the patch
> > > > with an
> > > > introduction of
On 11.12.2023 15:43, Oleksii wrote:
> On Mon, 2023-12-04 at 11:39 +0100, Jan Beulich wrote:
>> On 04.12.2023 11:34, Oleksii wrote:
>>> If you ( or anyone else ) don't mind, I'll update the patch with an
>>> introduction of HAS_GRANT_TABLE.
>>
>> I won't NAK such a patch, but unless convincing argum
On Mon, 2023-12-04 at 11:39 +0100, Jan Beulich wrote:
> On 04.12.2023 11:34, Oleksii wrote:
> > If you ( or anyone else ) don't mind, I'll update the patch with an
> > introduction of HAS_GRANT_TABLE.
>
> I won't NAK such a patch, but unless convincing arguments appear I
> also
> won't ACK it.
I a
On 04.12.2023 11:34, Oleksii wrote:
> If you ( or anyone else ) don't mind, I'll update the patch with an
> introduction of HAS_GRANT_TABLE.
I won't NAK such a patch, but unless convincing arguments appear I also
won't ACK it.
Jan
On Mon, 2023-12-04 at 10:46 +0100, Jan Beulich wrote:
> On 04.12.2023 10:39, Oleksii wrote:
> > On Mon, 2023-12-04 at 09:41 +0100, Jan Beulich wrote:
> > > On 01.12.2023 21:48, Oleksii Kurochko wrote:
> > > > Ifdef-ing inclusion of allows to avoid
> > > > generation of empty for cases when
> > >
On 04.12.2023 10:39, Oleksii wrote:
> On Mon, 2023-12-04 at 09:41 +0100, Jan Beulich wrote:
>> On 01.12.2023 21:48, Oleksii Kurochko wrote:
>>> Ifdef-ing inclusion of allows to avoid
>>> generation of empty for cases when
>>> CONFIG_GRANT_TABLE is not enabled.
>>>
>>> The following changes were d
On Mon, 2023-12-04 at 09:41 +0100, Jan Beulich wrote:
> On 01.12.2023 21:48, Oleksii Kurochko wrote:
> > Ifdef-ing inclusion of allows to avoid
> > generation of empty for cases when
> > CONFIG_GRANT_TABLE is not enabled.
> >
> > The following changes were done for Arm:
> > should be included d
On 01.12.2023 21:48, Oleksii Kurochko wrote:
> Ifdef-ing inclusion of allows to avoid
> generation of empty for cases when
> CONFIG_GRANT_TABLE is not enabled.
>
> The following changes were done for Arm:
> should be included directly because it contains
> gnttab_dom0_frames() macros which is u
Ifdef-ing inclusion of allows to avoid
generation of empty for cases when
CONFIG_GRANT_TABLE is not enabled.
The following changes were done for Arm:
should be included directly because it contains
gnttab_dom0_frames() macros which is unique for Arm and is used in
arch/arm/domain_build.c.
is #
12 matches
Mail list logo
