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
Hi,
I have finally worked out why XenServer is having issues with its legacy
windows drivers and Xen-4.5.
XenServer needs to support hvm ops with an indicies of 0x102 and 0x103
to prevent our legacy windows drivers from BSODing on boot. (These
problems will disappear when we can drop Windows XP/
14 matches
Mail list logo
