On 27/11/2018 10:24, Jan Beulich wrote:
On 27.11.18 at 08:37, wrote:
>> On 26/11/2018 17:50, Jan Beulich wrote:
>> On 26.11.18 at 17:17, wrote:
I really fail to see why it is so bad to not clobber data in a case
which normally should never occur.
>>>
>>> See Andrew's original r
On 27/11/2018 10:16, Julien Grall wrote:
> Hi,
>
> On 11/27/18 7:34 AM, Juergen Gross wrote:
>> On 26/11/2018 17:51, Julien Grall wrote:
>>>
>>>
>>> On 26/11/2018 16:17, Juergen Gross wrote:
On 26/11/2018 17:01, Julien Grall wrote:
>
>
> On 26/11/2018 15:29, Juergen Gross wrote:
>
>>> On 27.11.18 at 08:37, wrote:
> On 26/11/2018 17:50, Jan Beulich wrote:
> On 26.11.18 at 17:17, wrote:
>>> I really fail to see why it is so bad to not clobber data in a case
>>> which normally should never occur.
>>
>> See Andrew's original reply. You're also clobbering on potential
>> s
Hi,
On 11/27/18 7:34 AM, Juergen Gross wrote:
On 26/11/2018 17:51, Julien Grall wrote:
On 26/11/2018 16:17, Juergen Gross wrote:
On 26/11/2018 17:01, Julien Grall wrote:
On 26/11/2018 15:29, Juergen Gross wrote:
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
On 2
On 26/11/2018 17:50, Jan Beulich wrote:
On 26.11.18 at 17:17, wrote:
>> I really fail to see why it is so bad to not clobber data in a case
>> which normally should never occur.
>
> See Andrew's original reply. You're also clobbering on potential
> success paths.
I think you are missing a "
On 26/11/2018 17:51, Julien Grall wrote:
>
>
> On 26/11/2018 16:17, Juergen Gross wrote:
>> On 26/11/2018 17:01, Julien Grall wrote:
>>>
>>>
>>> On 26/11/2018 15:29, Juergen Gross wrote:
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
>> On 26/11/2018 15:01
On 26/11/2018 16:17, Juergen Gross wrote:
On 26/11/2018 17:01, Julien Grall wrote:
On 26/11/2018 15:29, Juergen Gross wrote:
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
I don't think the hype
>>> On 26.11.18 at 17:17, wrote:
> I really fail to see why it is so bad to not clobber data in a case
> which normally should never occur.
See Andrew's original reply. You're also clobbering on potential
success paths.
Jan
___
Xen-devel mailing lis
On 26/11/2018 17:01, Julien Grall wrote:
>
>
> On 26/11/2018 15:29, Juergen Gross wrote:
>> On 26/11/2018 15:58, Jan Beulich wrote:
>> On 26.11.18 at 15:23, wrote:
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
>> I don't think the hypervisor should e
On 26/11/2018 15:29, Juergen Gross wrote:
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
I don't think the hypervisor should explicitly try to make it as hard as
possible for the guest to find probl
Juergen Gross writes ("Re: [PATCH] xen: only clobber multicall elements without
error"):
> On 26/11/2018 15:54, Ian Jackson wrote:
> > Maybe they could be clobbered losslessly ? Eg, by xoring with 0xaa or
> > something.
>
> This would be rather hacky: I'd need to find out if clobbering was
> per
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
>> On 26/11/2018 15:01, Jan Beulich wrote:
>> On 26.11.18 at 14:52, wrote:
I don't think the hypervisor should explicitly try to make it as hard as
possible for the guest to find problems in the code.
>>>
>>>
On 26/11/2018 15:54, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] xen: only clobber multicall elements without
> error"):
>> On 23.11.18 at 14:25, wrote:
>>> In debug builds the hypervisor will deliberately clobber processed
>>> elements of the multicall structure. In order to ease diagn
>>> On 26.11.18 at 15:23, wrote:
> On 26/11/2018 15:01, Jan Beulich wrote:
> On 26.11.18 at 14:52, wrote:
>>> I don't think the hypervisor should explicitly try to make it as hard as
>>> possible for the guest to find problems in the code.
>>
>> That's indeed not the hypervisor's goal. Inste
Jan Beulich writes ("Re: [PATCH] xen: only clobber multicall elements without
error"):
> On 23.11.18 at 14:25, wrote:
> > In debug builds the hypervisor will deliberately clobber processed
> > elements of the multicall structure. In order to ease diagnostic data
> > printout in the affected guest
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
>> I don't think the hypervisor should explicitly try to make it as hard as
>> possible for the guest to find problems in the code.
>
> That's indeed not the hypervisor's goal. Instead it tries to make
> it as hard as possi
>>> On 26.11.18 at 14:52, wrote:
> I don't think the hypervisor should explicitly try to make it as hard as
> possible for the guest to find problems in the code.
That's indeed not the hypervisor's goal. Instead it tries to make
it as hard as possible for the guest (developer) to make wrong
assum
On 26/11/2018 11:58, Jan Beulich wrote:
On 23.11.18 at 14:25, wrote:
>> In debug builds the hypervisor will deliberately clobber processed
>> elements of the multicall structure. In order to ease diagnostic data
>> printout in the affected guest only clobber elements which didn't
>> return an
>>> On 23.11.18 at 14:25, wrote:
> In debug builds the hypervisor will deliberately clobber processed
> elements of the multicall structure. In order to ease diagnostic data
> printout in the affected guest only clobber elements which didn't
> return an error.
Besides what Andrew has said such a
On 23/11/2018 14:28, Andrew Cooper wrote:
> On 23/11/2018 13:25, Juergen Gross wrote:
>> In debug builds the hypervisor will deliberately clobber processed
>> elements of the multicall structure. In order to ease diagnostic data
>> printout in the affected guest only clobber elements which didn't
>
On 23/11/2018 13:25, Juergen Gross wrote:
> In debug builds the hypervisor will deliberately clobber processed
> elements of the multicall structure. In order to ease diagnostic data
> printout in the affected guest only clobber elements which didn't
> return an error.
>
> Signed-off-by: Juergen Gr
21 matches
Mail list logo
