On 12.11.2019 14:02, Jan Beulich wrote:
> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
>> --- a/xen/arch/x86/mm/p2m-ept.c
>> +++ b/xen/arch/x86/mm/p2m-ept.c
>> @@ -1345,13 +1345,14 @@ void setup_ept_dump(void)
>> register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables",
>
flight 144191 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144191/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144035
Tests
flight 144192 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144192/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
144165
Tests which did not
On 15.11.2019 20:19, Rishi wrote:
> On Thu, Nov 14, 2019 at 10:05 PM Jan Beulich wrote:
>>
>> On 14.11.2019 17:07, Rishi wrote:
>>> In some of our hosts, Xen is not correctly exposing processor thermal
>>> capabilities to Dom0.
>>> Please refer: https://bugzilla.kernel.org/show_bug.cgi?id=205347
>
On 15.11.2019 18:16, Wei Liu wrote:
> On Fri, Nov 15, 2019 at 04:23:30PM +0100, Jan Beulich wrote:
>> On 02.10.2019 19:16, Hongyan Xia wrote:
>>> @@ -4847,22 +4848,50 @@ int mmcfg_intercept_write(
>>> }
>>>
>>> void *alloc_xen_pagetable(void)
>>> +{
>>> +mfn_t mfn;
>>> +
>>> +mfn = allo
On 18.11.2019 09:38, Alexandru Stefan ISAILA wrote:
> On 12.11.2019 14:02, Jan Beulich wrote:
>> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
>>> @@ -2572,17 +2574,36 @@ int p2m_init_altp2m_by_id(struct domain *d,
>>> unsigned int idx)
>>> altp2m_list_lock(d);
>>>
>>> if ( d-
When using posted interrupts on Intel hardware it's possible that the
vCPU resumes execution with a stale local APIC IRR register because
depending on the interrupts to be injected vlapic_has_pending_irq
might not be called, and thus PIR won't be synced into IRR.
Fix this by making sure PIR is alw
On 15.11.2019 18:13, George Dunlap wrote:
> On 11/15/19 5:06 PM, Andreas Kinzler wrote:
>> Hello All,
>>
>> I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
>> 3700X and found only very few differences. I added
>>
>> cpuid = [ "0x8008:ecx=0100"
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
--
Ack for merging thi
On 11/18/19 12:35 PM, Daniel Vetter wrote:
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Reviewed-by: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: Juergen Gro
On 18.11.19 11:35, Daniel Vetter wrote:
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@l
On 15.11.2019 19:59, Igor Druzhinin wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -932,30 +932,26 @@ static int deassign_device(struct domain *d, uint16_t
> seg, uint8_t bus,
> break;
> ret = hd->platform_ops->reassign_device(d, targe
On 17.11.2019 00:47, Marek Marczykowski-Górecki wrote:
> Before df6631 "efi: use directmap to access runtime services table"
> all usages of efi_rs pointer were guarded by efi_rs_enter(), which
> implicitly refused to operate with efi=no-rs (by checking if
> efi_l4_pgtable is NULL - which is t
On 11/15/19 5:06 PM, Andreas Kinzler wrote:
> Hello All,
>
> I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
> 3700X and found only very few differences. I added
>
> cpuid = [ "0x8008:ecx=0100" ]
>
> to xl.cfg and then Windows runs great wit
On Fri, Nov 15, 2019 at 9:43 PM Ian Jackson wrote:
>
> Oleksandr Grytsov writes ("Re: [PATCH v1 1/2] libxl: introduce new backend
> type VINPUT"):
> > 1. Move QEMU_BACKEND macro to libxl__device_type structure as function
> > and let the device to decide it has QEMU backend:
> >
> > struct li
On 18.11.2019 11:16, Roger Pau Monne wrote:
> When using posted interrupts on Intel hardware it's possible that the
> vCPU resumes execution with a stale local APIC IRR register because
> depending on the interrupts to be injected vlapic_has_pending_irq
> might not be called, and thus PIR won't be
On 18.11.2019 11:16, Roger Pau Monne wrote:
> @@ -1954,48 +1952,28 @@ static void __vmx_deliver_posted_interrupt(struct
> vcpu *v)
> * 2. The target vCPU is the current vCPU and we're in non-interrupt
> * context.
> */
> -if ( running && (in_irq() || (v != current)) )
> -
On 18.11.2019 12:39, George Dunlap wrote:
> On 11/15/19 5:06 PM, Andreas Kinzler wrote:
>> Hello All,
>>
>> I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
>> 3700X and found only very few differences. I added
>>
>> cpuid = [ "0x8008:ecx=0100"
On 18.11.2019 13:29, Jan Beulich wrote:
> On 18.11.2019 12:39, George Dunlap wrote:
>> On 11/15/19 5:06 PM, Andreas Kinzler wrote:
>>> Hello All,
>>>
>>> I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
>>> 3700X and found only very few differences. I added
>>>
>>> cpuid = [ "
On 18/11/2019 11:21, Jan Beulich wrote:
> On 15.11.2019 19:59, Igor Druzhinin wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -932,30 +932,26 @@ static int deassign_device(struct domain *d, uint16_t
>> seg, uint8_t bus,
>> break;
>>
On 18.11.2019 12:39, George Dunlap wrote:
> On 11/15/19 5:06 PM, Andreas Kinzler wrote:
>> Hello All,
>>
>> I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
>> 3700X and found only very few differences. I added
>>
>> cpuid = [ "0x8008:ecx=0100"
On Mon, Nov 18, 2019 at 10:50:47AM +0100, Jan Beulich wrote:
> On 15.11.2019 18:16, Wei Liu wrote:
> > On Fri, Nov 15, 2019 at 04:23:30PM +0100, Jan Beulich wrote:
> >> On 02.10.2019 19:16, Hongyan Xia wrote:
> >>> @@ -4847,22 +4848,50 @@ int mmcfg_intercept_write(
> >>> }
> >>>
> >>> void *all
On 12.11.2019 13:54, Jan Beulich wrote:
> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
>> @@ -4681,7 +4682,7 @@ static int do_altp2m_op(
>> break;
>>
>> case HVMOP_altp2m_set_suppress_ve:
>> -if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 )
>> +if ( a.
On 12.11.2019 13:54, Jan Beulich wrote:
> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
>> @@ -4681,7 +4682,7 @@ static int do_altp2m_op(
>> break;
>>
>> case HVMOP_altp2m_set_suppress_ve:
>> -if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 )
>> +if ( a.
On Mon, Nov 18, 2019 at 01:01:58PM +0100, Jan Beulich wrote:
> On 18.11.2019 11:16, Roger Pau Monne wrote:
> > When using posted interrupts on Intel hardware it's possible that the
> > vCPU resumes execution with a stale local APIC IRR register because
> > depending on the interrupts to be injected
On 18.11.2019 14:46, Roger Pau Monné wrote:
> On Mon, Nov 18, 2019 at 01:01:58PM +0100, Jan Beulich wrote:
>> On 18.11.2019 11:16, Roger Pau Monne wrote:
>>> When using posted interrupts on Intel hardware it's possible that the
>>> vCPU resumes execution with a stale local APIC IRR register becaus
On Mon, Nov 18, 2019 at 01:26:46PM +0100, Jan Beulich wrote:
> On 18.11.2019 11:16, Roger Pau Monne wrote:
> > @@ -1954,48 +1952,28 @@ static void __vmx_deliver_posted_interrupt(struct
> > vcpu *v)
> > * 2. The target vCPU is the current vCPU and we're in non-interrupt
> > * context.
>
On 18.11.2019 14:39, Alexandru Stefan ISAILA wrote:
> On 12.11.2019 13:54, Jan Beulich wrote:
>> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
>>> @@ -4693,8 +4694,23 @@ static int do_altp2m_op(
>>> }
>>> break;
>>>
>>> +case HVMOP_altp2m_set_suppress_ve_multi:
>>>
On 18.11.2019 15:03, Roger Pau Monné wrote:
> On Mon, Nov 18, 2019 at 01:26:46PM +0100, Jan Beulich wrote:
>> On 18.11.2019 11:16, Roger Pau Monne wrote:
>>> @@ -1954,48 +1952,28 @@ static void __vmx_deliver_posted_interrupt(struct
>>> vcpu *v)
>>> * 2. The target vCPU is the current vCPU a
On Mon, Nov 18, 2019 at 03:00:00PM +0100, Jan Beulich wrote:
> On 18.11.2019 14:46, Roger Pau Monné wrote:
> > On Mon, Nov 18, 2019 at 01:01:58PM +0100, Jan Beulich wrote:
> >> On 18.11.2019 11:16, Roger Pau Monne wrote:
> >>> When using posted interrupts on Intel hardware it's possible that the
>
On Mon, Nov 18, 2019 at 03:19:50PM +0100, Jan Beulich wrote:
> On 18.11.2019 15:03, Roger Pau Monné wrote:
> > On Mon, Nov 18, 2019 at 01:26:46PM +0100, Jan Beulich wrote:
> >> On 18.11.2019 11:16, Roger Pau Monne wrote:
> >>> @@ -1954,48 +1952,28 @@ static void __vmx_deliver_posted_interrupt(stru
flight 144193 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144193/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144042
Regression
On 11/18/19 12:54 PM, Jan Beulich wrote:
> On 18.11.2019 12:39, George Dunlap wrote:
>> On 11/15/19 5:06 PM, Andreas Kinzler wrote:
>>> Hello All,
>>>
>>> I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
>>> 3700X and found only very few differences. I added
>>>
>>> cpuid = [
Once again RPL checks have been introduced which don't account for a
32-bit kernel living in ring 1 when running in a PV Xen domain. The
case in FIXUP_FRAME has been preventing boot. Adjust BUG_IF_WRONG_CR3
as well to guard against future uses of the macro on a code path
reachable when running in P
On 18.11.2019 16:15, George Dunlap wrote:
> On 11/18/19 12:54 PM, Jan Beulich wrote:
>> On 18.11.2019 12:39, George Dunlap wrote:
>>> On 11/15/19 5:06 PM, Andreas Kinzler wrote:
Hello All,
I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
3700X and found onl
On 18.11.2019 15:20, Roger Pau Monné wrote:
> On Mon, Nov 18, 2019 at 03:00:00PM +0100, Jan Beulich wrote:
>> On 18.11.2019 14:46, Roger Pau Monné wrote:
>>> On Mon, Nov 18, 2019 at 01:01:58PM +0100, Jan Beulich wrote:
On 18.11.2019 11:16, Roger Pau Monne wrote:
> When using posted inter
Hi Thomas
On 10/30/19 15:38, Qais Yousef wrote:
> Using cpu_up/down directly to bring cpus online/offline loses synchronization
> with sysfs and could suffer from a race similar to what is described in
> commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and serialization
> during LPM").
>
On 15.11.2019 18:13, George Dunlap wrote:
On 11/15/19 5:06 PM, Andreas Kinzler wrote:
Hello All,
I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
3700X and found only very few differences. I added
cpuid = [ "0x8008:ecx=0100" ]
to xl.cfg an
On 18.11.2019 15:55, Roger Pau Monné wrote:
> On Mon, Nov 18, 2019 at 03:19:50PM +0100, Jan Beulich wrote:
>> On 18.11.2019 15:03, Roger Pau Monné wrote:
>>> On Mon, Nov 18, 2019 at 01:26:46PM +0100, Jan Beulich wrote:
On 18.11.2019 11:16, Roger Pau Monne wrote:
> @@ -1954,48 +1952,28 @@
Florijan Hamzic wrote:
> my machine recently crashes randomly. I found this thing in my logs
> before the crash happened:
...
Can you share more information regarding the Xen version you are
using?
Juergen
___
Xen-devel mailing list
Xen-devel@lists
On 11/18/19 4:11 PM, Andreas Kinzler wrote:
> On 15.11.2019 18:13, George Dunlap wrote:
>> On 11/15/19 5:06 PM, Andreas Kinzler wrote:
>>> Hello All,
>>>
>>> I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
>>> 3700X and found only very few differences. I added
>>>
>>> cpuid =
Hello,
Trying to build a simple version of XSA-304 Live-Patch for 4.13 gives
the following error during LP upload:
(XEN) livepatch: lp: Unknown symbol: .LC7
Bisecting identified the first bad commit as:
commit 854a7ca60e35 "create-diff-object: Do not include all .rodata
sections"
Base
> On 18. Nov 2019, at 17:42, Sergey Dyasli wrote:
>
> Hello,
>
> Trying to build a simple version of XSA-304 Live-Patch for 4.13 gives
> the following error during LP upload:
>
>(XEN) livepatch: lp: Unknown symbol: .LC7
>
> Bisecting identified the first bad commit as:
>
>commit 854
On 18/11/2019 16:47, Wieczorkiewicz, Pawel wrote:
>
>
>> On 18. Nov 2019, at 17:42, Sergey Dyasli wrote:
>>
>> Hello,
>>
>> Trying to build a simple version of XSA-304 Live-Patch for 4.13 gives
>> the following error during LP upload:
>>
>>(XEN) livepatch: lp: Unknown symbol: .LC7
>>
>> Bise
This new ev allows to arrange a non-reentrant callback to be called.
This happen immediately after the current event is processed and after
other ev_immediates that would have already been registered.
Signed-off-by: Anthony PERARD
---
Notes:
v3:
- new patch
tools/libxl/libxl_event.c
Which allow to cancel the lock operation while it is in Active state.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
Notes:
v2:
- Renamed libxl__ev_qmplock_dispose to libxl__ev_slowlock_dispose
- This new API was part of the patch "Introduce libxl__ev_qmplock" in v1.
tool
No functionnal changes.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
tools/libxl/libxl_disk.c| 6 +++---
tools/libxl/libxl_dm.c | 8
tools/libxl/libxl_dom_save.c| 2 +-
tools/libxl/libxl_dom_suspend.c | 2 +-
tools/libxl/libxl_domain.c | 8
This patch workaround the fact that it's not possible to connect
multiple time to a single QMP socket. QEMU listen on the socket with
a backlog value of 1, which mean that on Linux when concurrent thread
call connect() on the socket, they get EAGAIN.
Background:
This happens when attempting to
We are going to want to include libxl__ev_devlock into libxl__ev_qmp.
No functional changes.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
Notes:
New patch in v2:
Move of the struct was done in "libxl_qmp: Have a lock for QMP
socket access" before.
tools/libxl/l
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.fix-ev_qmp-multi-connect-v3
v3:
Two patches left to review:
- libxl: Introduce libxl__ev_immediate (new)
- libxl_qmp: Have a lock for QMP socket access
And Jürgen already gave his ack o
We are going to introduce a different lock based on the same
implementation as the ev_devlock but with a different path. The
different slowlock will be differentiated by calling different _init()
functions.
So we rename libxl__ev_devlock to lib__ev_slowlock, but keep
libxl__ev_devlock_init().
Som
Allow to deregister the callback associated with a child death event.
The death isn't immediate will need to be collected later, so the
ev_child machinery register its own callback.
libxl__ev_child_kill_deregister() might be called by an AO operation
that is finishing/cleaning up without a chance
> On 18. Nov 2019, at 18:09, Sergey Dyasli wrote:
>
> On 18/11/2019 16:47, Wieczorkiewicz, Pawel wrote:
>>
>>
>>> On 18. Nov 2019, at 17:42, Sergey Dyasli wrote:
>>>
>>> Hello,
>>>
>>> Trying to build a simple version of XSA-304 Live-Patch for 4.13 gives
>>> the following error during LP u
Anthony PERARD writes ("[XEN PATCH for-4.13 v3 6/7] libxl: Introduce
libxl__ev_immediate"):
> This new ev allows to arrange a non-reentrant callback to be called.
> This happen immediately after the current event is processed and after
> other ev_immediates that would have already been registered.
Anthony PERARD writes ("[XEN PATCH for-4.13 v3 7/7] libxl_qmp: Have a lock for
QMP socket access"):
> This patch workaround the fact that it's not possible to connect
> multiple time to a single QMP socket. QEMU listen on the socket with
> a backlog value of 1, which mean that on Linux when concur
Oleksandr Grytsov writes ("Re: [PATCH v1 1/2] libxl: introduce new backend type
VINPUT"):
> On Fri, Nov 15, 2019 at 9:43 PM Ian Jackson wrote:
> > Sorry for the delay replying. In your earlier mails I had trouble
> > figuring out what you meant but this little vignette makes it clear to
> > me.
On Mon, Nov 18, 2019 at 05:28:17PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[XEN PATCH for-4.13 v3 6/7] libxl: Introduce
> libxl__ev_immediate"):
> > This new ev allows to arrange a non-reentrant callback to be called.
> > This happen immediately after the current event is processed and
Oleksandr Grytsov writes ("[PATCH v1 1/2] libxl: introduce new backend type
VINPUT"):
> From: Oleksandr Grytsov
>
> There are two kind of VKBD devices: with QEMU backend and user space
> backend. In current implementation they can't be distinguished as both use
> VKBD backend type. As result, us
Anthony PERARD writes ("Re: [XEN PATCH for-4.13 v3 6/7] libxl: Introduce
libxl__ev_immediate"):
> Sound good. I'll also switch to STAILQ instead, single-link tail queue
> for a FIFO list.
Err, yes, that would make sense. I should have considered whether you
chose the right kind of list but it do
This new ev allows to arrange a non-reentrant callback to be called.
This happen immediately after the current event is processed and after
other ev_immediates that would have already been registered.
Signed-off-by: Anthony PERARD
---
Notes:
v4:
- rework foreach loop in egc_run_callbacks
Anthony PERARD writes ("[XEN PATCH for-4.13 v4 6/7] libxl: Introduce
libxl__ev_immediate"):
> This new ev allows to arrange a non-reentrant callback to be called.
> This happen immediately after the current event is processed and after
> other ev_immediates that would have already been registered.
When nestedhvm_hap_nested_page_fault() returns L0_ERROR,
hvm_hap_nested_page_fault() operates on the adjusted gpa. However, it
operates with the original npfec, which is no longer be correct.
In particular, it is possible to get a nested fault where the translation is
not present in L12 (and ther
flight 144194 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144194/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
On 15.11.2019 12:01, Andreas Kinzler wrote:
On 14.11.2019 12:29, Jan Beulich wrote:
On 14.11.2019 00:10, Andreas Kinzler wrote:
I came across the following: https://lkml.org/lkml/2019/8/29/536
Could that be the reason for the problem mentioned below? Xen is using
HPET as clocksource on the plat
On Mon, 18 Nov 2019, Qais Yousef wrote:
> I had to make an educated guess that you're probably the 'maintainer' of cpu
> hotplug - but there's no explicit entry that says that. Please let me know if
> I need to bring the attention of others too.
:)
> The series do have few rough edges to address
flight 144195 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144195/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144035
Tests
On Fri, Nov 15, 2019 at 05:23:28PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[XEN PATCH for-4.13] libxl_pci: Don't hold QMP
> connection while waiting"):
> > After sending the 'device_del' command for a PCI passthrough device,
> > we wait until QEMU has effectively deleted the device, th
On Mon, Nov 18, 2019 at 05:30:36PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[XEN PATCH for-4.13 v3 7/7] libxl_qmp: Have a lock
> for QMP socket access"):
> > This patch workaround the fact that it's not possible to connect
> > multiple time to a single QMP socket. QEMU listen on the soc
flight 144197 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144197/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail blocked in 144154
test-amd64-amd64-xl-qemuu-win7-amd6
flight 144198 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144198/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144105
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
flight 144203 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144203/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 18.11.19 19:15, Andrew Cooper wrote:
When nestedhvm_hap_nested_page_fault() returns L0_ERROR,
hvm_hap_nested_page_fault() operates on the adjusted gpa. However, it
operates with the original npfec, which is no longer be correct.
In particular, it is possible to get a nested fault where the t
On Mon, Nov 18, 2019 at 3:08 PM Jan Beulich wrote:
>
> On 15.11.2019 20:19, Rishi wrote:
> > On Thu, Nov 14, 2019 at 10:05 PM Jan Beulich wrote:
> >>
> >> On 14.11.2019 17:07, Rishi wrote:
> >>> In some of our hosts, Xen is not correctly exposing processor thermal
> >>> capabilities to Dom0.
> >>
flight 144199 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144199/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144042
Tests whic
Ok, to sum up -- there's definitely a pretty major regression on all
this hardware with Xen 4.13 RC2:
https://www.dell.com/en-us/work/shop/gateways-embedded-computing/sc/gateways-embedded-pcs/edge-gateway?~ck=bt
Without efi=no-rs option Xen panics on boot (sorry for attaching the
screenshot
On Sun, Nov 17, 2019 at 10:15 PM Jürgen Groß wrote:
>
> On 16.11.19 02:12, Roman Shaposhnik wrote:
> > NOTE: this may or may not be a hair on fire problem, reporting it
> > anyway since I'd hate to pass on something that maybe a serious issue.
> > I haven't had time to debug this just yet -- so ju
On Nov 19, 2019, at 02:13, Roman Shaposhnik wrote:
>
> Ok, to sum up -- there's definitely a pretty major regression on all
> this hardware with Xen 4.13 RC2:
>
> https://www.dell.com/en-us/work/shop/gateways-embedded-computing/sc/gateways-embedded-pcs/edge-gateway?~ck=bt
>
> Without efi=no
On Mon, Nov 18, 2019 at 11:31 PM Rich Persaud wrote:
>
> On Nov 19, 2019, at 02:13, Roman Shaposhnik wrote:
> >
> > Ok, to sum up -- there's definitely a pretty major regression on all
> > this hardware with Xen 4.13 RC2:
> >
> > https://www.dell.com/en-us/work/shop/gateways-embedded-computin
78 matches
Mail list logo
