flight 144058 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144058/
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
flight 144075 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144075/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 8c4330818f6ee70cbf7428a40a28a73df1272d10
baseline version:
xen a458
flight 144059 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144059/
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 144071 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144071/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 143023
build-amd64-libvirt
On 12/11/2019 17:15, Jan Beulich wrote:
> On 12.11.2019 17:09, Andrew Cooper wrote:
>> On 04/11/2019 15:31, Jan Beulich wrote:
>>> On 04.11.2019 16:22, Andrew Cooper wrote:
On 04/11/2019 15:03, Jan Beulich wrote:
> On 04.11.2019 15:59, Andrew Cooper wrote:
>> On 04/11/2019 13:25, Jan B
On 13.11.2019 14:22, Andrew Cooper wrote:
> I am not convinced the behaviour is worth changing, and I don't have
> time for this scope creep.
There's no scope creep here at all. All I'm asking for is that you
don't blindly OR in EFER_NX into trampoline_efer, but rather check
that it will be possib
c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
for NULL.
intremap_table_entries() internally uses virt_to_page() which falls over
ASSERT(va >= XEN_VIRT_START);
in __virt_to_page().
Signed-o
On 13.11.2019 01:11, Boris Ostrovsky wrote:
> On 11/11/19 9:46 AM, Jan Beulich wrote:
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -393,6 +393,8 @@
>> #define MSR_AMD_PSTATE_DEF_BASE 0xc0010064
>> #define MSR_AMD64_OSVW_ID_LENGTH0xc0010
IOMMUs are owned by DOM_XEN, and with XSA-302, DOM_IO is used for
quarantined domains. Use %pd in the printk to render the system
domains more intelligently.
Before:
(XEN) :00:01.0 - dom 0 - node 0 - MSIs < >
(XEN) :00:00.0 - dom 0 - node 0 - MSIs < >
(XEN) :80:00.2 - do
On 13/11/2019 13:41, Andrew Cooper wrote:
> c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
> intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
> for NULL.
>
> intremap_table_entries() internally uses virt_to_page() which falls over
>
> ASSERT(
On 13.11.2019 01:15, Boris Ostrovsky wrote:
> On 11/11/19 9:46 AM, Jan Beulich wrote:
>> There's no apparent reason why it can be used on 64-bit only.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/drivers/xen/Kconfig
>> +++ b/drivers/xen/Kconfig
>> @@ -285,7 +285,7 @@ config XEN_ACPI_PROCESSOR
>>
...when their values are larger than the per-domain configured limits.
Signed-off-by: Paul Durrant
---
After mining through commits it is still unclear to me exactly when Xen
stopped honouring the global values, but I really think this commit should
be back-ported to stable trees as it was a beha
Commit 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs right after table
allocation") moved ourselves into a more secure default state, but
didn't take sufficient care to also undo the effects when handing a
previously disabled device back to a(nother) domain. Put the fields
that may have been changed el
Sorry, the Cc list got dropped... I'll re-send.
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 13 November 2019 13:47
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul
> Subject: [PATCH] domain_create: honour global grant/maptrack frame
> limits...
>
> ...when their va
Looks good,
Reviewed-by: Christoph Hellwig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
...when their values are larger than the per-domain configured limits.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Wei Liu
After mining through commits it is stil
> +int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni,
> + struct mm_struct *mm, unsigned long start,
> + unsigned long length,
> + const struct mmu_interval_notifier_ops *ops);
> +int mmu_interva
Reviewed-by: Christoph Hellwig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Looks good,
Reviewed-by: Christoph Hellwig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Looks good:
Reviewed-by: Christoph Hellwig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 13/11/2019 13:47, Paul Durrant wrote:
> ...when their values are larger than the per-domain configured limits.
>
> Signed-off-by: Paul Durrant
> ---
> After mining through commits it is still unclear to me exactly when Xen
> stopped honouring the global values, but I really think this commit sh
On 13.11.19 14:47, Jan Beulich wrote:
On 13.11.2019 01:15, Boris Ostrovsky wrote:
On 11/11/19 9:46 AM, Jan Beulich wrote:
There's no apparent reason why it can be used on 64-bit only.
Signed-off-by: Jan Beulich
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -285,7 +285,7 @@ config XE
On 12.11.2019 17:06, Jürgen Groß wrote:
> On 12.11.19 14:48, Jan Beulich wrote:
>> On 02.10.2019 13:20, Juergen Gross wrote:
>>> +static int hypfs_add_entry(struct hypfs_dir *parent, struct hypfs_entry
>>> *new)
>>> +{
>>> +int ret = -ENOENT;
>>> +struct list_head *l;
>>> +
>>> +if ( !
> -Original Message-
> From: Andrew Cooper
> Sent: 13 November 2019 14:05
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] domain_create: honour global
> grant/maptrack frame limits...
>
> On 13/11/2019 13:47, Paul Durrant wrote:
> > ...when their va
On 12.11.2019 17:45, Jürgen Groß wrote:
> On 12.11.19 15:22, Jan Beulich wrote:
>> On 02.10.2019 13:20, Juergen Gross wrote:
>>> @@ -79,3 +80,11 @@ subdir-$(CONFIG_UBSAN) += ubsan
>>>
>>> subdir-$(CONFIG_NEEDS_LIBELF) += libelf
>>> subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
>>> +
>>> +config
On 13.11.2019 14:44, Andrew Cooper wrote:
> IOMMUs are owned by DOM_XEN, and with XSA-302, DOM_IO is used for
> quarantined domains. Use %pd in the printk to render the system
> domains more intelligently.
>
> Before:
> (XEN) :00:01.0 - dom 0 - node 0 - MSIs < >
> (XEN) :00:00.0 -
On 13.11.2019 14:41, Andrew Cooper wrote:
> c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
> intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
> for NULL.
>
> intremap_table_entries() internally uses virt_to_page() which falls over
>
> ASSER
On 13.11.19 14:41, Andrew Cooper wrote:
c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
for NULL.
intremap_table_entries() internally uses virt_to_page() which falls over
ASSERT(va >= XEN_V
On 13.11.19 14:44, Andrew Cooper wrote:
IOMMUs are owned by DOM_XEN, and with XSA-302, DOM_IO is used for
quarantined domains. Use %pd in the printk to render the system
domains more intelligently.
Before:
(XEN) :00:01.0 - dom 0 - node 0 - MSIs < >
(XEN) :00:00.0 - dom 0 - n
On 13.11.19 15:07, Jan Beulich wrote:
On 12.11.2019 17:06, Jürgen Groß wrote:
On 12.11.19 14:48, Jan Beulich wrote:
On 02.10.2019 13:20, Juergen Gross wrote:
+static int hypfs_add_entry(struct hypfs_dir *parent, struct hypfs_entry *new)
+{
+int ret = -ENOENT;
+struct list_head *l;
+
+
On 13.11.19 15:12, Jan Beulich wrote:
On 12.11.2019 17:45, Jürgen Groß wrote:
On 12.11.19 15:22, Jan Beulich wrote:
On 02.10.2019 13:20, Juergen Gross wrote:
@@ -79,3 +80,11 @@ subdir-$(CONFIG_UBSAN) += ubsan
subdir-$(CONFIG_NEEDS_LIBELF) += libelf
subdir-$(CONFIG_HAS_DEVICE_TREE) +
On 13.11.2019 12:55, osstest service owner wrote:
> flight 144059 xen-4.12-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/144059/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-qemuu-neste
On 13.11.2019 15:40, Jürgen Groß wrote:
> On 13.11.19 15:07, Jan Beulich wrote:
>> On 12.11.2019 17:06, Jürgen Groß wrote:
>>> On 12.11.19 14:48, Jan Beulich wrote:
On 02.10.2019 13:20, Juergen Gross wrote:
> +static unsigned int hypfs_get_entry_len(struct hypfs_entry *entry)
> +{
On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich wrote:
>
> On 12.11.2019 15:05, Tamas K Lengyel wrote:
> > On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich wrote:
> >> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
> >>> +else
> >>> +{
> >>> +rc = p2m_set_suppress_ve_multi
On Wed, Nov 13, 2019 at 7:51 AM Tamas K Lengyel wrote:
>
> On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich wrote:
> >
> > On 12.11.2019 15:05, Tamas K Lengyel wrote:
> > > On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich wrote:
> > >> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
> > >>> +e
On 13/11/2019 14:42, Jan Beulich wrote:
> On 13.11.2019 12:55, osstest service owner wrote:
>> flight 144059 xen-4.12-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/144059/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which co
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Re-name and modify signature of toGo function to fromC. The reason for
> using 'fromC' rather than 'toGo' is that it is not a good idea to define
> methods on the C types. Also, add error return type to Bitmap's toC function.
>
>
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define StringList as []string an implement fromC and toC functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
>
> tools/golang/xenlight/xenlight.go | 29 +
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define Mac as [6]byte and implement fromC, toC, and String functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
>
> tools/golang/xenlight/xenlight.go | 35 +++
Hello,
The current interrupt posting code doesn't flush the PIR into the IRR
when interrupts are modified, and as a result a vCPU can receive vectors
from a tear down or moved interrupt. Fix this by making sure PIR is
always synced to IRR when vMSI or vIO-APIC interrupts are modified.
Roger Pau M
When using posted interrupts and the guest migrates MSI from vCPUs Xen
needs to flush any pending PIRR vectors on the previous vCPU, or else
those vectors could get wrongly injected at a later point when the MSI
fields are already updated.
The usage of a fixed vCPU in lowest priority mode when usi
If posted interrutps are being used sync PIR to IRR when an unmasked
vIO-APIC entry is modified. Do this in order to prevent vectors in the
IRR being set after a change to a vIO-APIC entry has been performed.
Signed-off-by: Roger Pau Monné
---
Cc: Juergen Gross
---
xen/arch/x86/hvm/vioapic.c |
... if the vCPU is different than the one currently running or if it's
running on a different pCPU.
No functional change intended.
Suggested by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Cc: Juergen Gross
---
xen/arch/x86/hvm/vmx/vmx.c | 11 +++
1 file changed, 11 insertions(+)
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define MsVmGenid as [int(C.LIBXL_MS_VM_GENID_LEN)]byte and implement fromC
> and toC functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
>
> tools/golang/xenlight/xenlight.
Debugger support in the hypervisor is rarely used and it is opening a
way for dom0 to modify the running hypervisor by very easy means.
Add a Kconfig option to control support of gdbsx. Default is off.
Signed-off-by: Juergen Gross
---
xen/Kconfig.debug | 4
xen/arch/x86/Kconf
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define EvLink as empty struct as there is currently no reason the internal of
> this type should be used in Go.
>
> Implement fromC and toC functions as no-ops.
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
___
On 11/13/19 8:44 AM, Jan Beulich wrote:
> On 13.11.2019 01:11, Boris Ostrovsky wrote:
>> On 11/11/19 9:46 AM, Jan Beulich wrote:
>>> --- a/arch/x86/include/asm/msr-index.h
>>> +++ b/arch/x86/include/asm/msr-index.h
>>> @@ -393,6 +393,8 @@
>>> #define MSR_AMD_PSTATE_DEF_BASE0xc0010064
>
Hello Stefano,
On 11.11.19 22:57, Stefano Stabellini wrote:
Oh man, this is truly horrible.
I feel your pain.
If we really have to do this please:
- use the same dummy function name in all files
No, because
- the function should be static
those functions will not handle the case if a
On Wed, Nov 13, 2019 at 05:59:52AM -0800, Christoph Hellwig wrote:
> > +int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni,
> > + struct mm_struct *mm, unsigned long start,
> > + unsigned long length,
> > +
On 13.11.2019 15:57, Tamas K Lengyel wrote:
> On Wed, Nov 13, 2019 at 7:51 AM Tamas K Lengyel wrote:
>>
>> On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich wrote:
>>>
>>> On 12.11.2019 15:05, Tamas K Lengyel wrote:
On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich wrote:
> On 06.11.2019 16:35, Ale
On 13.11.2019 17:22, Juergen Gross wrote:
> Debugger support in the hypervisor is rarely used and it is opening a
> way for dom0 to modify the running hypervisor by very easy means.
>
> Add a Kconfig option to control support of gdbsx. Default is off.
>
> Signed-off-by: Juergen Gross
Acked-by:
There were two problems here: The first closing parentheses got parsed
by make to end the $(call invocation, and the escaping of the quotes
wasn't right either, as there's nowhere they would get un-escaped.
Signed-off-by: Jan Beulich
---
This needs to be tested in an environment where this was ac
Dear Julien,
On 13.11.19 07:51, Julien Grall wrote:
Was this reported to Arm?
All mentioned ARM Compiler issues were reported to ARM. Unfortunately, ARM
hesitated to discus them in community, yet asked to open support cases, e.g.
[1].
All issues and their WA's were acknowledged by ARM in corr
Hi Jan,
Sorry for delayed reply
On Thu, 2019-11-07 at 08:31 +0100, Jan Beulich wrote:
> On 06.11.2019 23:08, Artem Mygaiev wrote:
> > On Wed, Nov 6, 2019 at 4:28 PM Jan Beulich <
> > jbeul...@suse.com
> > > wrote:
> > > On 06.11.2019 10:19, Andrii Anisov wrote:
> > > > --- a/Config.mk
> > > > +++
On 13/11/2019 16:22, Juergen Gross wrote:
> Debugger support in the hypervisor is rarely used and it is opening a
> way for dom0 to modify the running hypervisor by very easy means.
>
> Add a Kconfig option to control support of gdbsx. Default is off.
>
> Signed-off-by: Juergen Gross
> ---
> xen/
flight 144082 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144082/
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 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define CpuidPolicyList as a wrapper struct with field val of type
> *C.libxl_cpuid_policy_list and implement fromC and toC functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Re-define Uuid as [16]byte and implement fromC, toC, and String functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
>
> tools/golang/xenlight/xenlight.go | 37 ++
On 10/7/19 4:13 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Re-define Hwcap as [8]uint32, and implement toC function. Also, re-name and
> modify signature of toGo function to fromC.
>
> Signed-off-by: Nick Rosbrook
Looks good. Just one comment...
> ---
> Cc: George Dunlap
> Cc: Ian J
For system with large numbers of CPUs, the 'r' debugkey is unwieldy. Sibling
and core masks are a single block of adjacent bits, so are vastly shorter to
render with %pbl.
Before:
(XEN) CPU[00] nr_run=0, sort=157,
sibling=,,,,,,,0003,
On Wed, Nov 13, 2019 at 9:52 AM Jan Beulich wrote:
>
> On 13.11.2019 15:57, Tamas K Lengyel wrote:
> > On Wed, Nov 13, 2019 at 7:51 AM Tamas K Lengyel wrote:
> >>
> >> On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich wrote:
> >>>
> >>> On 12.11.2019 15:05, Tamas K Lengyel wrote:
> On Tue, Nov 12
> Any particular reason to use `cslice` here rather than `mapslice` (or
> vice versa)?
>
> Not a big deal, but since they're of the came element in the C struct,
> it seems like it would be better to give them the same name. (Don't
> have a strong opinion on which one).
IIRC, I found the name `ma
flight 144068 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144068/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bfcf262488a140550a53361c225a9b2b1bee0db8
baseline version:
ovmf e92b155740cdbf10a85ed
> Doesn't this method want a pointer receiver?
Yes, since I'm allocating a new slice. If I wasn't allocating a new
slice, this would be okay since the slice contains a pointer to the
underlying array.
-NR
___
Xen-devel mailing list
Xen-devel@lists.xenp
Ran same test and did not hit the issue.
Tested-by: Joe Jin
On 11/13/19 7:59 AM, Roger Pau Monne wrote:
> When using posted interrupts and the guest migrates MSI from vCPUs Xen
> needs to flush any pending PIRR vectors on the previous vCPU, or else
> those vectors could get wrongly injected at a
> What's the point of this?
>
> I realize it's slightly annoying to have to type `mac[0], mac[1], ...`,
> but I'd rather do that once than make the runtime copy everything over
> into a slice of interfaces every String() call.
As I think you realized by looking at subsequent patches, this is to
ge
flight 144067 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR. v
Hello All,
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 platform/mainboard. Is there an (easy) way to
verify if Xen uses PC10?
Regards Andreas
On 12.10.2019 20:47, Andreas K
flight 144070 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144070/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 144050
test-armhf-armhf-xl-rtds
On Tue, 12 Nov 2019, 05:57 Stefano Stabellini,
wrote:
> On Wed, 6 Nov 2019, Andrii Anisov wrote:
> > From: Andrii Anisov
> >
> > ARM Compiler 6 has a proven bug: it compiles data only C files with
> > SoftVFP attributes. This leads to a failed linkage afterwards with
> > an error:
> >
> > Error:
On Thu, 14 Nov 2019, 02:15 Artem Mygaiev, wrote:
> Hi Jan,
>
> Sorry for delayed reply
>
> On Thu, 2019-11-07 at 08:31 +0100, Jan Beulich wrote:
> > On 06.11.2019 23:08, Artem Mygaiev wrote:
> > > On Wed, Nov 6, 2019 at 4:28 PM Jan Beulich <
> > > jbeul...@suse.com
> > > > wrote:
> > > > On 06.11
From: Julian Tuminaro and Jenish Rakholiya
Current implementation of find_os is based on the hard-coded values for
different Windows version. It uses the value for get the address to
start looking for DOS header in the given specified range. However, this
is not scalable to all version of Windows
flight 144073 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144073/
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 14.11.19 00:06, osstest service owner wrote:
flight 144067 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmres
On Tue, 12 Nov 2019, 11:45 Peng Fan, wrote:
> Hi Julien,
>
> Inline marked with [Peng Fan]
>
> From: Julien Grall
> Sent: 2019年11月9日 6:44
> To: Stefano Stabellini ; Andre Przywara <
> andre.przyw...@arm.com>
> Cc: Peng Fan ; Jürgen Groß ;
> julien.gr...@arm.com; xen-de...@lists.xen.org
> Subject
On 13.11.19 18:26, Andrew Cooper wrote:
On 13/11/2019 16:22, Juergen Gross wrote:
Debugger support in the hypervisor is rarely used and it is opening a
way for dom0 to modify the running hypervisor by very easy means.
Add a Kconfig option to control support of gdbsx. Default is off.
Signed-off
On 13.11.19 19:36, Andrew Cooper wrote:
For system with large numbers of CPUs, the 'r' debugkey is unwieldy. Sibling
and core masks are a single block of adjacent bits, so are vastly shorter to
render with %pbl.
Before:
(XEN) CPU[00] nr_run=0, sort=157,
sibling=,,,00
On 13.11.19 14:47, Jan Beulich wrote:
On 13.11.2019 01:15, Boris Ostrovsky wrote:
On 11/11/19 9:46 AM, Jan Beulich wrote:
There's no apparent reason why it can be used on 64-bit only.
Signed-off-by: Jan Beulich
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -285,7 +285,7 @@ config XE
78 matches
Mail list logo
