>>> On 17.01.17 at 16:06, wrote:
> On 17/01/17 12:29, George Dunlap wrote:
>> On Tue, Jan 17, 2017 at 11:22 AM, Andrew Cooper
>> wrote:
>>> On 16/01/17 16:16, Jan Beulich wrote:
>>> On 16.01.17 at 17:05, wrote:
> On 13/01/17 12:47, Jan Beulich wrote:
>> The kernel already has to
>>> On 17.01.17 at 16:13, wrote:
> On 17/01/17 12:42, Jan Beulich wrote:
>>
And I'm not sure we really need to bother considering hypothetical
128-bit architectures at this point in time.
>>> Because considering this case will avoid us painting ourselves into a
>>> corner
On 17/01/17 12:42, Jan Beulich wrote:
>
>>> And I'm not sure we really need to bother considering hypothetical
>>> 128-bit architectures at this point in time.
>> Because considering this case will avoid us painting ourselves into a
>> corner.
> Why would we consider this case h
On 17/01/17 12:29, George Dunlap wrote:
> On Tue, Jan 17, 2017 at 11:22 AM, Andrew Cooper
> wrote:
>> On 16/01/17 16:16, Jan Beulich wrote:
>> On 16.01.17 at 17:05, wrote:
On 13/01/17 12:47, Jan Beulich wrote:
> The kernel already has to parse this structure anyway, and will know
>>> On 17.01.17 at 12:22, wrote:
> On 16/01/17 16:16, Jan Beulich wrote:
> On 16.01.17 at 17:05, wrote:
>>> On 13/01/17 12:47, Jan Beulich wrote:
The kernel already has to parse this structure anyway, and will know
the
bitness of its userspace process. We could ea
On Tue, Jan 17, 2017 at 11:22 AM, Andrew Cooper
wrote:
> On 16/01/17 16:16, Jan Beulich wrote:
> On 16.01.17 at 17:05, wrote:
>>> On 13/01/17 12:47, Jan Beulich wrote:
The kernel already has to parse this structure anyway, and will know
the
bitness of its userspace
On 16/01/17 16:16, Jan Beulich wrote:
On 16.01.17 at 17:05, wrote:
>> On 13/01/17 12:47, Jan Beulich wrote:
>>> The kernel already has to parse this structure anyway, and will know the
>>> bitness of its userspace process. We could easily (at this point)
>>> require the kernel to
>>> On 16.01.17 at 18:07, wrote:
> If we don't want to bake 64-bit pointers into the ABI then I guess a
> compat layer is the only way. Guess I'll go and stare at macros until my
> brain explodes...
Well, before you do I'd really hope for Andrew to provide us (or at
least me, if everyone else
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 January 2017 16:17
> To: Andrew Cooper
> Cc: Ian Jackson ; Jennifer Herbert
> ; Paul Durrant ; Wei
> Liu ; xen-de...@lists.xenproject.org; Daniel DeGraaf
>
> Subject: Re: [PATCH v3 1/8] public / x86: Introduce
>>> On 16.01.17 at 17:05, wrote:
> On 13/01/17 12:47, Jan Beulich wrote:
>> The kernel already has to parse this structure anyway, and will know the
>> bitness of its userspace process. We could easily (at this point)
>> require the kernel to turn it into the kernels bitness for forwa
On 13/01/17 12:47, Jan Beulich wrote:
> The kernel already has to parse this structure anyway, and will know the
> bitness of its userspace process. We could easily (at this point)
> require the kernel to turn it into the kernels bitness for forwarding on
> to Xen, which covers the
>>> On 13.01.17 at 13:03, wrote:
> On 12/01/17 16:29, Jan Beulich wrote:
> On 12.01.17 at 17:10, wrote:
> +
> +struct xen_dm_op_buf {
> +XEN_GUEST_HANDLE_64(void) h;
> +uint32_t size;
> +};
Sorry to quibble, but there is a problem here which has only just
On 12/01/17 16:29, Jan Beulich wrote:
On 12.01.17 at 17:10, wrote:
+
+struct xen_dm_op_buf {
+XEN_GUEST_HANDLE_64(void) h;
+uint32_t size;
+};
>>> Sorry to quibble, but there is a problem here which has only just
>>> occurred to me. This ABI isn't futureproof
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 January 2017 10:31
> To: Andrew Cooper ; Paul Durrant
>
> Cc: Ian Jackson ; Jennifer Herbert
> ; Wei Liu ; xen-
> de...@lists.xenproject.org; Daniel DeGraaf
> Subject: RE: [PATCH v3 1/8] public / x86: Introduce
On Fri, Jan 13, 2017 at 09:05:19AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 12 January 2017 16:29
> > To: Andrew Cooper ; Paul Durrant
> >
> > Cc: Ian Jackson ; Jennifer Herbert
> > ; Wei Liu ; xen-
> > de...@lists.xenproj
>>> On 13.01.17 at 10:05, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 12 January 2017 16:29
>> >>> On 12.01.17 at 17:10, wrote:
>> >> The userspace side should be
>> >>
>> >> struct xen_dm_op_buf {
>> >> void *h;
>> >> size_t size;
>> >> }
>> >>
>> >> which will work s
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 12 January 2017 16:29
> To: Andrew Cooper ; Paul Durrant
>
> Cc: Ian Jackson ; Jennifer Herbert
> ; Wei Liu ; xen-
> de...@lists.xenproject.org; Daniel De Graaf
> Subject: RE: [PATCH v3 1/8] public / x86: Introduc
>>> On 12.01.17 at 17:10, wrote:
>> > +
>> > +struct xen_dm_op_buf {
>> > +XEN_GUEST_HANDLE_64(void) h;
>> > +uint32_t size;
>> > +};
>>
>> Sorry to quibble, but there is a problem here which has only just
>> occurred to me. This ABI isn't futureproof, and has padding at the end
>> which
> -Original Message-
[snip]
> > +
> > +struct xen_dm_op_buf {
> > +XEN_GUEST_HANDLE_64(void) h;
> > +uint32_t size;
> > +};
>
> Sorry to quibble, but there is a problem here which has only just
> occurred to me. This ABI isn't futureproof, and has padding at the end
> which affect
On 12/01/17 14:58, Paul Durrant wrote:
> ...as a set of hypercalls to be used by a device model.
>
> As stated in the new docs/designs/dm_op.markdown:
>
> "The aim of DMOP is to prevent a compromised device model from
> compromising domains other then the one it is associated with. (And is
> theref
...as a set of hypercalls to be used by a device model.
As stated in the new docs/designs/dm_op.markdown:
"The aim of DMOP is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)."
See that file fo
21 matches
Mail list logo
