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 info
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. I'
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 sim
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 floo
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 q
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. Infor
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 Be
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 lsevtch
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 language
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 lsevtch
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 m
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, w
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 ev
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 acce
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 do
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 c
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
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 inquir
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 Xen
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 not
31 matches
Mail list logo
