Andrew Cooper writes:
> (XEN) traps.c:1576: GPF (): 82d08031a80f
> [vmx.c#vmx_msr_read_intercept+0x387/0x3fd] -> 82d08037c9f2
> (XEN) traps.c:1576: GPF (): 82d08031a80f
> [vmx.c#vmx_msr_read_intercept+0x387/0x3fd] -> 82d08037c9f2
> (d2) xs_write(/vm/95f11fc0-b9e7-47ff-85
Jan Beulich writes:
> On 21.09.2019 01:14, Sarah Newman wrote:
>> With nestedhvm=1, the L2 HVM guest is either hanging (Xen 4.8) or
>> crashing (Xen 4.12.1) the L1 Xen hypervisor with recent versions of
>> Linux. We
>> isolated the commit to:
>>
>> commit 093ae8f9a86a974c920b613860f1f7fd5bbd70ab
Jason Andryuk writes:
>> So if I understand correctly, the problem is that PCI passthrough
>> doesn't work with stubdomains, unless qemu is patched?
>
> Hi, Chris.
>
> I pulled in the QEMU patch because I found that my Intel wired
> ethernet device didn't work without it. I believe my Intel wire
Christopher Clark writes:
> On Tue, Dec 4, 2018 at 10:11 AM Chris Brannon wrote:
>>
>> Hi,
>> I set up a network driver domain for a dom0; it uses HVM
>> virtualization. It worked very well when not using a device model
>> stubdomain, but when I requested the
Hi,
I set up a network driver domain for a dom0; it uses HVM
virtualization. It worked very well when not using a device model
stubdomain, but when I requested the use of a device model stubdomain in
my xl.cfg file, the domU refused to boot. It gave the following error
message.
[76594.195404] xe
I just got the following patch from a colleague. It's a backport of
the XSA 274 kernel patch to 4.9.x kernels. The kernel patch given in
the XSA would not apply cleanly. Would someone mind reviewing it? It
would be much appreciated.
commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
Th
George Dunlap writes:
> Can you attach the following?
>
> * the output of `xl dmesg`
> * the output of `dmesg`
> * the config file for the guest
Attached.
> I just tested stubdoms with staging-4.10 and everything works
> correctly *as long as dom0 is assigned all memory*. If I limit the
> amou
I recently made a build of xen 4.10.0 and installed it.
I have a pre-existing HVM guest that uses the following configuration:
1 hard drive using the phy disk backend. The guest also uses a device
model stubdomain. After upgrading, it refuses to start, due to a
stubdomain timeout:
Parsing config
I have the following traceback from xen-netback, under kernel 4.9.58.
Does anyone know what might be going on here?
[ cut here ]
kernel BUG at drivers/net/xen-netback/rx.c:325!
invalid opcode: [#1] SMP
task: 88028f18cec0 task.stack: c90045e08000
RIP: e030:[]
