On Tue, 21 May 2024, Jan Beulich wrote:
> On 17.05.2024 22:28, Stefano Stabellini wrote:
> > On Fri, 17 May 2024, Jan Beulich wrote:
> >> On 17.05.2024 03:21, Stefano Stabellini wrote:
> >>> On Thu, 16 May 2024, Jan Beulich wrote:
> 1) In the discussion George claimed that exposing status
On 17.05.2024 22:28, Stefano Stabellini wrote:
> On Fri, 17 May 2024, Jan Beulich wrote:
>> On 17.05.2024 03:21, Stefano Stabellini wrote:
>>> On Thu, 16 May 2024, Jan Beulich wrote:
1) In the discussion George claimed that exposing status information in
an uncontrolled manner is okay.
On Fri, 17 May 2024, Jan Beulich wrote:
> On 17.05.2024 03:21, Stefano Stabellini wrote:
> > On Thu, 16 May 2024, Jan Beulich wrote:
> >> 1) In the discussion George claimed that exposing status information in
> >> an uncontrolled manner is okay. I'm afraid I have to disagree, seeing
> >> how a
On 17.05.2024 03:22, Daniel P. Smith wrote:
> On 5/16/24 02:41, Jan Beulich wrote:
>> On 14.05.2024 11:25, Jan Beulich wrote:
>>> On 03.04.2024 08:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
> The commit makes a claim without any kind of justification.
Well,
On 17.05.2024 03:21, Stefano Stabellini wrote:
> On Thu, 16 May 2024, Jan Beulich wrote:
>> 1) In the discussion George claimed that exposing status information in
>> an uncontrolled manner is okay. I'm afraid I have to disagree, seeing
>> how a similar assumption by CPU designers has led to a
On 16.05.2024 21:15, Oleksii K. wrote:
> I am not deeply familiar with the technical details surrounding XSM,
> but if I understand Daniel's point correctly, the original change
> violates the access control framework. This suggests to me that the
> revert should be merged.
>
> However, I have a
On 5/16/24 02:41, Jan Beulich wrote:
On 14.05.2024 11:25, Jan Beulich wrote:
On 03.04.2024 08:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
The commit makes a claim without any kind of justification.
Well, what does "have no business" leave open?
The claim is false, and
On Thu, 16 May 2024, Jan Beulich wrote:
> 1) In the discussion George claimed that exposing status information in
> an uncontrolled manner is okay. I'm afraid I have to disagree, seeing
> how a similar assumption by CPU designers has led to a flood of
> vulnerabilities over the last 6+ years.
On Tue, 2024-05-14 at 12:13 +0100, Julien Grall wrote:
> Hi,
>
> (+ Oleksii as the release manager)
>
> Chiming into the discussion as there seems there is disagreement.
>
> On 14/05/2024 11:03, Jan Beulich wrote:
> > On 14.05.2024 11:51, Andrew Cooper wrote:
> > > On 14/05/2024 10:25 am, Jan
On 14.05.2024 11:25, Jan Beulich wrote:
> On 03.04.2024 08:16, Jan Beulich wrote:
>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>> The commit makes a claim without any kind of justification.
>>
>> Well, what does "have no business" leave open?
>>
>>> The claim is false, and the commit broke
On Tue, May 14, 2024 at 10:51 AM Andrew Cooper
wrote:
>
> On 14/05/2024 10:25 am, Jan Beulich wrote:
> > On 03.04.2024 08:16, Jan Beulich wrote:
> >> On 02.04.2024 19:06, Andrew Cooper wrote:
> >>> The commit makes a claim without any kind of justification.
> >> Well, what does "have no business"
Hi all,
As Stefano has mentioned, we have the maintainers and committers call later
today.
Let's use this time to better collaborate and discuss any differences in
opinions we have. It will also give everyone a chance to explain their
viewpoints.
Andy, please can I remind you to keep the
On 14.05.2024 23:35, Stefano Stabellini wrote:
> On Tue, 14 May 2024, Julien Grall wrote:
>> On 14/05/2024 11:03, Jan Beulich wrote:
>>> On 14.05.2024 11:51, Andrew Cooper wrote:
You tried defending breaking a utility with "well it shouldn't exist
then".
You don't have a leg to
On Tue, 14 May 2024, Julien Grall wrote:
> Hi,
>
> (+ Oleksii as the release manager)
>
> Chiming into the discussion as there seems there is disagreement.
>
> On 14/05/2024 11:03, Jan Beulich wrote:
> > On 14.05.2024 11:51, Andrew Cooper wrote:
> > > On 14/05/2024 10:25 am, Jan Beulich wrote:
Hi,
(+ Oleksii as the release manager)
Chiming into the discussion as there seems there is disagreement.
On 14/05/2024 11:03, Jan Beulich wrote:
On 14.05.2024 11:51, Andrew Cooper wrote:
On 14/05/2024 10:25 am, Jan Beulich wrote:
On 03.04.2024 08:16, Jan Beulich wrote:
On 02.04.2024 19:06,
On 14.05.2024 11:51, Andrew Cooper wrote:
> On 14/05/2024 10:25 am, Jan Beulich wrote:
>> On 03.04.2024 08:16, Jan Beulich wrote:
>>> On 02.04.2024 19:06, Andrew Cooper wrote:
The commit makes a claim without any kind of justification.
>>> Well, what does "have no business" leave open?
>>>
On 14/05/2024 10:25 am, Jan Beulich wrote:
> On 03.04.2024 08:16, Jan Beulich wrote:
>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>> The commit makes a claim without any kind of justification.
>> Well, what does "have no business" leave open?
>>
>>> The claim is false, and the commit broke
On 03.04.2024 08:16, Jan Beulich wrote:
> On 02.04.2024 19:06, Andrew Cooper wrote:
>> The commit makes a claim without any kind of justification.
>
> Well, what does "have no business" leave open?
>
>> The claim is false, and the commit broke lsevtchn in dom0.
>
> Or alternatively lsevtchn was
On 03.04.2024 15:27, Daniel P. Smith wrote:
> On 4/3/24 08:05, Jan Beulich wrote:
>> On 03.04.2024 13:10, Daniel P. Smith wrote:
>>> On 4/3/24 02:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
>It is also quite
> obvious from XSM_TARGET that it has broken device
On 03.04.2024 15:31, Daniel P. Smith wrote:
> On 4/3/24 07:54, Jan Beulich wrote:
>> On 03.04.2024 13:50, Daniel P. Smith wrote:
>>> On 4/3/24 02:52, Jan Beulich wrote:
On 03.04.2024 08:16, Jan Beulich wrote:
> On 02.04.2024 19:06, Andrew Cooper wrote:
>> Whether to return information
On 03.04.2024 15:27, Daniel P. Smith wrote:
> On 4/3/24 08:05, Jan Beulich wrote:
>> On 03.04.2024 13:10, Daniel P. Smith wrote:
>>> On 4/3/24 02:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
> The commit makes a claim without any kind of justification.
Well,
On 4/2/24 13:06, Andrew Cooper wrote:
The commit makes a claim without any kind of justification.
The claim is false, and the commit broke lsevtchn in dom0. It is also quite
obvious from XSM_TARGET that it has broken device model stubdoms too.
Whether to return information about a xen-owned
On 4/3/24 07:54, Jan Beulich wrote:
On 03.04.2024 13:50, Daniel P. Smith wrote:
On 4/3/24 02:52, Jan Beulich wrote:
On 03.04.2024 08:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
Whether to return information about a xen-owned evtchn is a matter of policy,
and it's not
On 4/3/24 08:05, Jan Beulich wrote:
On 03.04.2024 13:10, Daniel P. Smith wrote:
On 4/3/24 02:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
The commit makes a claim without any kind of justification.
Well, what does "have no business" leave open?
Why does it not have any
On 03.04.2024 13:10, Daniel P. Smith wrote:
> On 4/3/24 02:16, Jan Beulich wrote:
>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>> The commit makes a claim without any kind of justification.
>>
>> Well, what does "have no business" leave open?
>
> Why does it not have any business? Why should a
On 03.04.2024 13:50, Daniel P. Smith wrote:
> On 4/3/24 02:52, Jan Beulich wrote:
>> On 03.04.2024 08:16, Jan Beulich wrote:
>>> On 02.04.2024 19:06, Andrew Cooper wrote:
Whether to return information about a xen-owned evtchn is a matter of
policy,
and it's not acceptable to short
On 4/3/24 02:52, Jan Beulich wrote:
On 03.04.2024 08:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
Whether to return information about a xen-owned evtchn is a matter of policy,
and it's not acceptable to short circuit the XSM on the matter.
I can certainly accept this as
On 4/3/24 02:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
The commit makes a claim without any kind of justification.
Well, what does "have no business" leave open?
Why does it not have any business? Why should a domain that creates an
event channel not be able to
On 03.04.2024 08:16, Jan Beulich wrote:
> On 02.04.2024 19:06, Andrew Cooper wrote:
>> Whether to return information about a xen-owned evtchn is a matter of policy,
>> and it's not acceptable to short circuit the XSM on the matter.
>
> I can certainly accept this as one possible view point. As in
On 02.04.2024 19:06, Andrew Cooper wrote:
> The commit makes a claim without any kind of justification.
Well, what does "have no business" leave open?
> The claim is false, and the commit broke lsevtchn in dom0.
Or alternatively lsevtchn was doing something that was never meant to work
(from
The commit makes a claim without any kind of justification.
The claim is false, and the commit broke lsevtchn in dom0. It is also quite
obvious from XSM_TARGET that it has broken device model stubdoms too.
Whether to return information about a xen-owned evtchn is a matter of policy,
and it's
31 matches
Mail list logo
