On Thu, Dec 04, 2014 at 01:49:47PM +, Jan Beulich wrote:
> >>> On 28.11.14 at 16:46, wrote:
> > On 28/11/14 15:18, Jan Beulich wrote:
> > On 28.11.14 at 14:55, wrote:
> >>> The problem is with continuations which reuse the upper bits of the
> >>> input register, not with this HVMOP_op_mas
On 04/12/14 16:11, Jan Beulich wrote:
On 04.12.14 at 16:46, wrote:
>> On 04/12/14 14:55, Jan Beulich wrote:
>> On 04.12.14 at 15:28, wrote:
On 04/12/14 13:49, Jan Beulich wrote:
On 28.11.14 at 16:46, wrote:
>> On 28/11/14 15:18, Jan Beulich wrote:
>> On 28.11.1
>>> On 04.12.14 at 16:46, wrote:
> On 04/12/14 14:55, Jan Beulich wrote:
> On 04.12.14 at 15:28, wrote:
>>> On 04/12/14 13:49, Jan Beulich wrote:
>>> On 28.11.14 at 16:46, wrote:
> On 28/11/14 15:18, Jan Beulich wrote:
> On 28.11.14 at 14:55, wrote:
>>> The problem is wi
At 14:28 + on 04 Dec (1417699730), Andrew Cooper wrote:
> On 04/12/14 13:49, Jan Beulich wrote:
> On 28.11.14 at 16:46, wrote:
> >> On 28/11/14 15:18, Jan Beulich wrote:
> >> On 28.11.14 at 14:55, wrote:
> The problem is with continuations which reuse the upper bits of the
> >>>
On 04/12/14 14:55, Jan Beulich wrote:
On 04.12.14 at 15:28, wrote:
>> On 04/12/14 13:49, Jan Beulich wrote:
>> On 28.11.14 at 16:46, wrote:
On 28/11/14 15:18, Jan Beulich wrote:
On 28.11.14 at 14:55, wrote:
>> The problem is with continuations which reuse the upper bit
>>> On 04.12.14 at 15:28, wrote:
> On 04/12/14 13:49, Jan Beulich wrote:
> On 28.11.14 at 16:46, wrote:
>>> On 28/11/14 15:18, Jan Beulich wrote:
>>> On 28.11.14 at 14:55, wrote:
> The problem is with continuations which reuse the upper bits of the
> input register, not with this
On 04/12/14 13:49, Jan Beulich wrote:
On 28.11.14 at 16:46, wrote:
>> On 28/11/14 15:18, Jan Beulich wrote:
>> On 28.11.14 at 14:55, wrote:
The problem is with continuations which reuse the upper bits of the
input register, not with this HVMOP_op_mask specifically; the
HVM
>>> On 28.11.14 at 16:46, wrote:
> On 28/11/14 15:18, Jan Beulich wrote:
> On 28.11.14 at 14:55, wrote:
>>> The problem is with continuations which reuse the upper bits of the
>>> input register, not with this HVMOP_op_mask specifically; the
>>> HVMOP_op_mask simply adds to an existing proble
On 28/11/14 15:18, Jan Beulich wrote:
On 28.11.14 at 14:55, wrote:
>> The problem is with continuations which reuse the upper bits of the
>> input register, not with this HVMOP_op_mask specifically; the
>> HVMOP_op_mask simply adds to an existing problem. This is something
>> which needs con
>>> On 28.11.14 at 14:55, wrote:
> The problem is with continuations which reuse the upper bits of the
> input register, not with this HVMOP_op_mask specifically; the
> HVMOP_op_mask simply adds to an existing problem. This is something
> which needs considering urgently because, as you identify
On 28/11/14 13:07, Jan Beulich wrote:
On 28.11.14 at 12:36, wrote:
>> However, it occurs to me that HVMOP_op_mask absolutely must live in the
>> public header files, as it is guest visible, and forms part of the ABI.
>>
>> Consider a userspace task which falls into a continuation, is preempte
On Fri, 2014-11-28 at 13:07 +, Jan Beulich wrote:
> I suppose a stubdom gets re-created on the target host (rather
> than migrated) when its client migrates.
Correct.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen
>>> On 28.11.14 at 12:36, wrote:
> However, it occurs to me that HVMOP_op_mask absolutely must live in the
> public header files, as it is guest visible, and forms part of the ABI.
>
> Consider a userspace task which falls into a continuation, is preempted
> and paused by the guest kernel, the en
13 matches
Mail list logo
