flight 153537 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153537/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
flight 153533 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153533/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
flight 153527 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
flight 153502 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 152631
build-amd64-xsm
flight 153522 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153522/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
flight 153494 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153494/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 152877
flight 153509 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
flight 153486 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153486/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 152332
build-amd64-xsm
flight 153503 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153503/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
flight 153498 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153498/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
flight 153478 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153478/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 152631
build-amd64-xsm
flight 153495 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153495/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
flight 153468 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 152877
flight 153484 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
On Tue, Sep 01, 2020 at 10:33:26AM +0200, Roger Pau Monne wrote:
> +static int fill_list(unsigned int nr_pages)
> +{
> + struct dev_pagemap *pgmap;
> + void *vaddr;
> + unsigned int i, alloc_pages = round_up(nr_pages, PAGES_PER_SECTION);
> + int nid, ret;
> +
> + pgmap =
flight 153460 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153460/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 152332
build-amd64-xsm
Hello,
Why XenGT doesn't have any new version?
On Tuesday, September 1, 2020, 09:21:27 PM GMT+4:30, Xu, Terrence
wrote:
Hi Mario,
Sorry to make you feel uncomfortable.
I think it is not setup guide problem, the main reason is the Xen code is very
old (We are upgrading
Hi Mario,
Sorry to make you feel uncomfortable.
I think it is not setup guide problem, the main reason is the Xen code is very
old (We are upgrading GVT-g code on Linux kernel side and we haven’t upgraded
the Xen and Qemu source for XenGT for at least 2 years) but your GCC is new
(You are
flight 153479 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153479/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
Thanks for this interesting experiment. My recollection was correct that
exceptions are very fast but only if you don't capture stack traces (which we
we do capture). With backtraces the difference is not massive. It still does
pay off to use exceptions when they are raised rarely as the it
Change the catch-all behavior for MSR not explicitly handled. Instead
of allow full read-access to the MSR space and silently dropping
writes return an exception when the MSR is not explicitly handled.
Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
---
Changes since v2:
- Added missing
Linux PV guests will attempt to read the FEATURE_CONTROL MSR, so move
the handling done in VMX code into guest_rdmsr as it can be shared
between PV and HVM guests that way.
Signed-off-by: Roger Pau Monné
---
Changes from v1:
- Move the VMX implementation into guest_rdmsr.
---
Move the special handling of reads to it's own switch case, and also
add support for BU_CFG2. On the write side ignore writes if the MSR is
readable, otherwise return a #GP.
This is in preparation for changing the default MSR read/write
behavior, which will instead return #GP on not explicitly
Hello,
The current series attempts to change the current MSR default handling
behavior, which is to silently drop writes to writable MSRs, and allow
reading any MSR not explicitly handled.
After this series access to MSRs not explicitly handled will trigger a
#GP fault. I've tested this series
From: Andrew Cooper
Now that the main PV/HVM MSR handlers raise #GP for all unknown MSRs, there is
no need to special case these MSRs any more.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/arch/x86/msr.c | 46
Report LFENCE_SERIALISE unconditionally for DE_CFG on AMD hardware and
silently drop writes.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Drop the bot_cpu checks and don't attempt to read the MSR, just
return LFENCE_SERIALISE unconditionally.
- Add a
From: Andrew Cooper
Change the catch-all behavior for MSR not explicitly handled. Instead
of allow full read-access to the MSR space and silently dropping
writes return an exception when the MSR is not explicitly handled.
Signed-off-by: Andrew Cooper
[remove rdmsr_safe from default case in
The SYSCFG, TOP_MEM1 and TOP_MEM2 MSRs are currently exposed to guests
and writes are silently discarded. Make this explicit in the SVM code
now, and just return default constant values when attempting to read
any of the MSRs, while continuing to silently drop writes.
Signed-off-by: Roger Pau
Such handling consist in checking that no bits have been changed from
the read value, if that's the case silently drop the write, otherwise
inject a fault.
At least Windows guests will expect to write to the MISC_ENABLE MSR
with the same value that's been read from it.
Signed-off-by: Roger Pau
flight 153474 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153474/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
On 01.09.20 16:45, Roger Pau Monné wrote:
On Tue, Sep 01, 2020 at 10:33:26AM +0200, Roger Pau Monne wrote:
+static int fill_list(unsigned int nr_pages)
+{
+ struct dev_pagemap *pgmap;
+ void *vaddr;
+ unsigned int i, alloc_pages = round_up(nr_pages, PAGES_PER_SECTION);
+
flight 153452 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153452/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 152631
build-amd64-xsm
On 01/09/2020 10:28, Roger Pau Monné wrote:
> On Tue, Sep 01, 2020 at 03:50:34AM +0100, Igor Druzhinin wrote:
>> Guest kernel does need to know in some cases where the tables are located
>> to treat these regions properly. One example is kexec process where
>> the first kernel needs to pass
flight 153469 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153469/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
On Tue, Sep 01, 2020 at 03:50:34AM +0100, Igor Druzhinin wrote:
> Guest kernel does need to know in some cases where the tables are located
> to treat these regions properly. One example is kexec process where
> the first kernel needs to pass firmware region locations to the second
> kernel which
This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
being used by non DAX devices.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Ira Weiny
Acked-by: Andrew Morton
---
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Andrew Morton
Cc:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will
In order to protect against the header being included multiple times
on the same compilation unit.
Signed-off-by: Roger Pau Monné
Reviewed-by: Boris Ostrovsky
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
---
This is required as a
Hello,
The following series contain some fixes in order to split Xen
unpopulated memory handling from the ballooning driver using the
ZONE_DEVICE functionality, so that physical memory regions used to map
foreign pages are not tied to memory hotplug.
Note this is currently only available for x86
flight 153461 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153461/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
flight 153437 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 152877
make 3.81 doesn't support multiline variables defined with
define var =
...
endef
Dropping the "=" in the first line will fix the issue.
Fixes: ded08cdfa72bb ("tools: generate most contents of library make variables")
Fixes: ddb2934a914df ("stubdom: add correct dependencies for Xen
On 01.09.2020 12:55, Jürgen Groß wrote:
> On 01.09.20 12:27, Jan Beulich wrote:
>> The assignment operator is optional, and use of it breaks with make 3.81.
>>
>> Fixes: ded08cdfa72b ("tools: generate most contents of library make
>> variables")
>> Suggested-by: Juergen Gross
>> Signed-off-by:
On 01.09.20 12:27, Jan Beulich wrote:
The assignment operator is optional, and use of it breaks with make 3.81.
Fixes: ded08cdfa72b ("tools: generate most contents of library make variables")
Suggested-by: Juergen Gross
Signed-off-by: Jan Beulich
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@
flight 153441 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 152332
build-amd64-xsm
On 01.09.2020 12:16, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 01 September 2020 11:11
>> To: xen-devel@lists.xenproject.org
>> Cc: Ian Jackson ; Wei Liu ; Paul Durrant
>>
>> Subject: [PATCH] tools/hotplug/Linux: don't needlessly use non-standard
>>
The assignment operator is optional, and use of it breaks with make 3.81.
Fixes: ded08cdfa72b ("tools: generate most contents of library make variables")
Suggested-by: Juergen Gross
Signed-off-by: Jan Beulich
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -94,7 +94,7 @@ INSTALL_DIR_ROOT = [
> -Original Message-
> From: Jan Beulich
> Sent: 01 September 2020 11:11
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson ; Wei Liu ; Paul Durrant
>
> Subject: [PATCH] tools/hotplug/Linux: don't needlessly use non-standard
> features in vif-bridge
>
> We're not after any
We're not after any "fall-through" behavior here. Replace the constructs
with ones understood by all conforming shells, including older bash
(problem observed with 3.1.51(1)).
Fixes: b51715f02bf9 ("tools/hotplug/Linux: remove code duplication in
vif-bridge")
Signed-off-by: Jan Beulich
---
Hi Thomas,
On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
[...]
>
> The whole lot is also available from git:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git device-msi
>
> This has been tested on Intel/AMD/KVM but lacks testing on:
>
> - HYPERV
> This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
> being used by non DAX devices.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Ira Weiny
> Acked-by: Andrew Morton
> ---
> Cc: Dan Williams
> Cc: Vishal Verma
> Cc: Dave Jiang
> Cc:
flight 153435 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153435/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 152631
build-amd64-xsm
flight 153445 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153445/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
On Tue, Aug 18, 2020 at 11:20:16AM +0200, Gerd Hoffmann wrote:
> Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
> through to the __sg_alloc_table_from_pages() call, otherwise use
> SCATTERLIST_MAX_SEGMENT.
>
> Also add max_segment field to drm driver and pass it to
>
flight 153440 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153440/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386
> -Original Message-
> From: Jan Beulich
> Sent: 31 August 2020 15:26
> To: Roger Pau Monné
> Cc: Jürgen Groß ; osstest service owner
> ; xen-
> de...@lists.xenproject.org; Durrant, Paul
> Subject: RE: [EXTERNAL] [xen-unstable test] 153154: regressions - trouble:
> broken/fail/pass
>
Guest kernel does need to know in some cases where the tables are located
to treat these regions properly. One example is kexec process where
the first kernel needs to pass firmware region locations to the second
kernel which is now a requirement after 02a3e3cdb7f12 ("x86/boot: Parse SRAT
table
Guest kernel does need to know in some cases where the tables are located
to treat these regions properly. One example is kexec process where
the first kernel needs to pass firmware region locations to the second
kernel which is now a requirement after 02a3e3cdb7f12 ("x86/boot: Parse SRAT
table
On Tue, Sep 01, 2020 at 08:01:30AM +0200, Jan Beulich wrote:
> On 01.09.2020 00:55, Elliott Mitchell wrote:
> > On Mon, Aug 31, 2020 at 08:52:45AM +0200, Jan Beulich wrote:
> >> On 31.08.2020 08:37, Elliott Mitchell wrote:
> >>> Preferences in sorting?
> >>
> >> Alphabetical sorting is what we
flight 153442 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153442/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
On 01.09.2020 00:55, Elliott Mitchell wrote:
> On Mon, Aug 31, 2020 at 08:52:45AM +0200, Jan Beulich wrote:
>> On 31.08.2020 08:37, Elliott Mitchell wrote:
>>> Preferences in sorting?
>>
>> Alphabetical sorting is what we generally aim for here.
>
> Going into specific example since those best
61 matches
Mail list logo
