I don't think we have anything obvious for dealing with single stepping of
real mode and 16-bit protected mode. Not to mention that sometimes these
bugs occur after execution of many thousands of instructions, which makes a
single step approach impractical.
-- Keir
On 23/04/2009 10:56, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> wrote:
> Keir,
>
> Is there any tool, which allows debugging step by step of the boot sequence
> (starting from the point which the hvmloader transfers control to the MBR)?
> If there is such tool, i will be able to debug it step by step, and compare it
> to a real machine, and thus, hopefully find the bug.
>
> Tom
>
> 2009/4/22 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
>> On 22/04/2009 15:40, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> wrote:
>>
>>> So, do u have any suggestion for me, on how to advance with this issue?
>>> should
>>> i debug the real mode emulation myself in order to track it down? will u be
>>> able top assist me in any way with this issue?
>>
>> If specific questions arise then certainly yes.
>>
>>> BTW - what is exactly the problem which causes this exception from the CPU?
>>> Tim mentioned something about segment state - can u please elaborate on this
>>> issue?
>>
>> Bit 17 in EFLAGS is set, meaning the guest is in vm86 mode. In this mode, on
>> vmentry, the processor applies specific checks to guest segment register
>> state. These are listed in SDM Vol 3B, but they include checking that
>> segment selector equals segment base address shifted right four bit
>> positions, for example. Clearly the segment state in the dump you emailed is
>> not valid for vm86 mode. Quite possibly PointSec doesn't expect to be in
>> vm86 mode at all, and something may have gone wrong to set that bit in
>> EFLAGS. But it's hard to say at arm's length.
>>
>> -- Keir
>>
>>> Tom
>>>
>>> 2009/4/22 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
>>>> Then it probably is a mis-emulation somewhere down the line. Unfortunately
>>>> that could be hard to track down, even if we had PointSec software to hand,
>>>> which we do not.
>>>>
>>>> -- Keir
>>>>
>>>> On 22/04/2009 15:20, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> wrote:
>>>>
>>>>> Well, just tried this patch, and it doesn't seem to work.
>>>>> I get the following error:
>>>>>
>>>>> (XEN) HVM1: Booting from 0000:7c00
>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest
>>>>> state
>>>>> (0).
>>>>> (XEN) ************* VMCS Area **************
>>>>> (XEN) *** Guest State ***
>>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019,
>>>>> gh_mask=ffffffffffffffff
>>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000,
>>>>> gh_mask=ffffffffffffffff
>>>>> (XEN) CR3: actual=0x000000000a22fa20, target_count=0
>>>>> (XEN) target0=0000000000000000, target1=0000000000000000
>>>>> (XEN) target2=0000000000000000, target3=0000000000000000
>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP =
>>>>> 0x000000000000002a
>>>>> (0x000000000000002a)
>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 =
>>>>> 0x0000000000000400
>>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000
>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff,
>>>>> base=0x0000000000200000
>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff,
>>>>> base=0x0000000000200000
>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff,
>>>>> base=0x000000000020ba62
>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff,
>>>>> base=0x0000000000200000
>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff,
>>>>> base=0x0000000000200000
>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff,
>>>>> base=0x0000000000200000
>>>>> (XEN) GDTR: limit=0x00001dd8,
>>>>> base=0x0000000000200000
>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff,
>>>>> base=0x0000000000000000
>>>>> (XEN) IDTR: limit=0x00000188,
>>>>> base=0x0000000000201df0
>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff,
>>>>> base=0x0000000000201ff2
>>>>> (XEN) Guest PAT = 0x0000000000000000
>>>>> (XEN) TSC Offset = ffffffe2242f086e
>>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000
>>>>> (XEN) Interruptibility=0001 ActivityState=0000
>>>>> (XEN) *** Host State ***
>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20
>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040
>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000
>>>>> TRBase=ffff828c802a8b00
>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010
>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfd8000 CR4=00000000000026f0
>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290
>>>>> (XEN) Host PAT = 0x0000000000000000
>>>>> (XEN) *** Control State ***
>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041
>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff
>>>>> (XEN) ExceptionBitmap=00044080
>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000
>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000
>>>>> (XEN) reason=80000021 qualification=00000000
>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000
>>>>> (XEN) TPR Threshold = 0x00
>>>>> (XEN) EPT pointer = 0x0000000000000000
>>>>> (XEN) Virtual processor ID = 0x0000
>>>>> (XEN) **************************************
>>>>> (XEN) domain_crash called from vmx.c:2218
>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1:
>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]----
>>>>> (XEN) CPU: 1
>>>>> (XEN) RIP: 0060:[<000000000000002a>]
>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest
>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx:
>>>>> 0000000000000000
>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi:
>>>>> 0000000000000000
>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8:
>>>>> 0000000000000000
>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11:
>>>>> 0000000000000000
>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14:
>>>>> 0000000000000000
>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4:
>>>>> 0000000000000000
>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000
>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060
>>>>>
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>> 2009/4/22 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
>>>>>> That should do it.
>>>>>>
>>>>>> K.
>>>>>>
>>>>>>
>>>>>> On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> wrote:
>>>>>>
>>>>>>> Keir,
>>>>>>> Just to make sure, i am using the following patch, in order to disable
>>>>>>> the
>>>>>>> vm86 acceleration:
>>>>>>>
>>>>>>> diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c
>>>>>>> --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100
>>>>>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300
>>>>>>> @@ -829,7 +829,7 @@
>>>>>>>
>>>>>>> if ( seg == x86_seg_tr )
>>>>>>> {
>>>>>>> - if ( v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS]
>>>>>>> )
>>>>>>> + if (0)
>>>>>>> {
>>>>>>> sel = 0;
>>>>>>> attr = vm86_tr_attr;
>>>>>>>
>>>>>>> Is this OK?
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> 2009/4/22 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
>>>>>>>> Yes, the safest way to be sure is probably to replace the if()
>>>>>>>> statement
>>>>>>>> in
>>>>>>>> vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0).
>>>>>>>> That
>>>>>>>> is
>>>>>>>> the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can
>>>>>>>> re-build/install Xen and be sure that vm86 accel must be disabled.
>>>>>>>>
>>>>>>>> -- Keir
>>>>>>>>
>>>>>>>> On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>> So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and
>>>>>>>>> re-check
>>>>>>>>> it?
>>>>>>>>>
>>>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>>>>>>>>>> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote:
>>>>>>>>>>> It could be an issue with the vm86 acceleration, possibly. I'm
>>>>>>>>>>> pretty
>>>>>>>>>>> sure
>>>>>>>>>>> the guest would have to IRET from protected mode to enter vm86 mode
>>>>>>>>>>> itself,
>>>>>>>>>>> and we don't emulate that. Tim: what would we need to do to disable
>>>>>>>>>>> the
>>>>>>>>>>> vm86
>>>>>>>>>>> acceleration for testing purposes? You suggested not setting
>>>>>>>>>>> VM86_TSS
>>>>>>>>>>> param
>>>>>>>>>>> from hvmloader, but I couldn't convince myself what effect that
>>>>>>>>>>> would
>>>>>>>>>>> actually have as the logic in Xen is non-trivial.
>>>>>>>>>>
>>>>>>>>>> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will
>>>>>>>>>> always set the tss bit in the bitmap of segments that aren't safe to
>>>>>>>>>> enter VM86 with.
>>>>>>>>>>
>>>>>>>>>> Tim.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- Keir
>>>>>>>>>>>
>>>>>>>>>>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Tim,
>>>>>>>>>>>>
>>>>>>>>>>>> so what does it mean? could it be that we have a bug in the real
>>>>>>>>>>>> mode
>>>>>>>>>>>> emulation, which causes the segment state to be invalid (maybe it's
>>>>>>>>>>>> because
>>>>>>>>>>>> of
>>>>>>>>>>>> a bug in the patch that Keir made for me, which emulated the LLDT,
>>>>>>>>>>>> and
>>>>>>>>>>>> the
>>>>>>>>>>>> LTR
>>>>>>>>>>>> instructions)?
>>>>>>>>>>>>
>>>>>>>>>>>> Keir suggested to trace back where the problem (segment state)
>>>>>>>>>>>> occured,
>>>>>>>>>>>> and
>>>>>>>>>>>> from there to try and find the bug which caused it. Do u have any
>>>>>>>>>>>> better
>>>>>>>>>>>> suggestion for solving this?
>>>>>>>>>>>>
>>>>>>>>>>>> Tom
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>>>>>>>>>>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote:
>>>>>>>>>>>>> Keir,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have tried your latest patch, and it looks like now it passes
>>>>>>>>>>>>> the
>>>>>>>>>>>>> emulation problem. However, now the domain crashes with the
>>>>>>>>>>>>> following
>>>>>>>>>>>>> error:
>>>>>>>>>>>>>
>>>>>>>>>>>>> (XEN) HVM1: Booting from 0000:7c00
>>>>>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid
>>>>>>>>>>>>> guest
>>>>>>>>>>>>> state
>>>>>>>>>>>>> (0).
>>>>>>>>>>>>> (XEN) ************* VMCS Area **************
>>>>>>>>>>>>> (XEN) *** Guest State ***
>>>>>>>>>>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019,
>>>>>>>>>>>>> gh_mask=ffffffffffffffff
>>>>>>>>>>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000,
>>>>>>>>>>>>> gh_mask=ffffffffffffffff
>>>>>>>>>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0
>>>>>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000
>>>>>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000
>>>>>>>>>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP =
>>>>>>>>>>>>> 0x000000000000002a (0x000000000000002a)
>>>>>>>>>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 =
>>>>>>>>>>>>> 0x0000000000000400
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looks like we're trying to VMENTER in virtual 8086 mode but
>>>>>>>>>>>>> without
>>>>>>>>>>>>> tidying up the segment state. That could either be the guest
>>>>>>>>>>>>> entering
>>>>>>>>>>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to
>>>>>>>>>>>>> emulate
>>>>>>>>>>>>> real mode, but Xen is always careful to make the segment state
>>>>>>>>>>>>> agree
>>>>>>>>>>>>> with Intel's rather strict requrements when it does that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tim.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000
>>>>>>>>>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff,
>>>>>>>>>>>>> base=0x0000000000200000
>>>>>>>>>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff,
>>>>>>>>>>>>> base=0x0000000000200000
>>>>>>>>>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff,
>>>>>>>>>>>>> base=0x000000000020ba62
>>>>>>>>>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff,
>>>>>>>>>>>>> base=0x0000000000200000
>>>>>>>>>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff,
>>>>>>>>>>>>> base=0x0000000000200000
>>>>>>>>>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff,
>>>>>>>>>>>>> base=0x0000000000200000
>>>>>>>>>>>>> (XEN) GDTR: limit=0x00001dd8,
>>>>>>>>>>>>> base=0x0000000000200000
>>>>>>>>>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff,
>>>>>>>>>>>>> base=0x0000000000000000
>>>>>>>>>>>>> (XEN) IDTR: limit=0x00000188,
>>>>>>>>>>>>> base=0x0000000000201df0
>>>>>>>>>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff,
>>>>>>>>>>>>> base=0x0000000000201ff2
>>>>>>>>>>>>> (XEN) Guest PAT = 0x0000000000000000
>>>>>>>>>>>>> (XEN) TSC Offset = ffffffe4920110b7
>>>>>>>>>>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000
>>>>>>>>>>>>> (XEN) Interruptibility=0001 ActivityState=0000
>>>>>>>>>>>>> (XEN) *** Host State ***
>>>>>>>>>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20
>>>>>>>>>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040
>>>>>>>>>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000
>>>>>>>>>>>>> TRBase=ffff828c802a8b00
>>>>>>>>>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010
>>>>>>>>>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000
>>>>>>>>>>>>> CR4=00000000000026f0
>>>>>>>>>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290
>>>>>>>>>>>>> (XEN) Host PAT = 0x0000000000000000
>>>>>>>>>>>>> (XEN) *** Control State ***
>>>>>>>>>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041
>>>>>>>>>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff
>>>>>>>>>>>>> (XEN) ExceptionBitmap=00044080
>>>>>>>>>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000
>>>>>>>>>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000
>>>>>>>>>>>>> (XEN) reason=80000021 qualification=00000000
>>>>>>>>>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000
>>>>>>>>>>>>> (XEN) TPR Threshold = 0x00
>>>>>>>>>>>>> (XEN) EPT pointer = 0x0000000000000000
>>>>>>>>>>>>> (XEN) Virtual processor ID = 0x0000
>>>>>>>>>>>>> (XEN) **************************************
>>>>>>>>>>>>> (XEN) domain_crash called from vmx.c:2218
>>>>>>>>>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1:
>>>>>>>>>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]----
>>>>>>>>>>>>> (XEN) CPU: 1
>>>>>>>>>>>>> (XEN) RIP: 0060:[<000000000000002a>]
>>>>>>>>>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest
>>>>>>>>>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx:
>>>>>>>>>>>>> 0000000000000000
>>>>>>>>>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi:
>>>>>>>>>>>>> 0000000000000000
>>>>>>>>>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8:
>>>>>>>>>>>>> 0000000000000000
>>>>>>>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11:
>>>>>>>>>>>>> 0000000000000000
>>>>>>>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14:
>>>>>>>>>>>>> 0000000000000000
>>>>>>>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4:
>>>>>>>>>>>>> 0000000000000000
>>>>>>>>>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000
>>>>>>>>>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs:
>>>>>>>>>>>>> 0060
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could it be, that the real mode emulation code has a bug? What
>>>>>>>>>>>>> does
>>>>>>>>>>>>> this
>>>>>>>>>>>>> error means?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/4/22 Keir Fraser
>>>>>>>>>>>>> <keir.fraser@xxxxxxxxxxxxx<mailto:keir.fraser@xxxxxxxxxxxxx>>
>>>>>>>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg"
>>>>>>>>>>>>> <tom.rotenberg@xxxxxxxxx<mailto:tom.rotenberg@xxxxxxxxx>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Keir,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have applied your patch, and it seemed to work. However, the
>>>>>>>>>>>>> domain
>>>>>>>>>>>>> still
>>>>>>>>>>>>> crashes, and now it looks like it's because of the 'LTR'
>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Try the attached patch. It replaces the one I sent last time, and
>>>>>>>>>>>>> emulates
>>>>>>>>>>>>> both LLDT and LTR.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- Keir
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Content-Description: ATT00001.txt
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Xen-devel mailing list
>>>>>>>>>>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>>>>>>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd.
>>>>>>>>>>>>> [Company #02300071, SL9 0DZ, UK.]
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>>>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd.
>>>>>>>>>> [Company #02300071, SL9 0DZ, UK.]
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home