On 10.09.2020 05:57, Marek Marczykowski-Górecki wrote:
> After updating from Xen 4.13 to Xen 4.14 I have troubles starting any
> HVM: just after hvmloader saying "Invoking SeaBIOS" I get "(XEN) MMIO
> emulation failed (1): d29v0 32bit @ 0008:fffeedf d -> "
>
> I come to a situation where seemingly
On 09.09.2020 03:28, Elliott Mitchell wrote:
> The top-level .gitignore file for Xen has gotten rather messy. Looks
> like at times a few people may have added some blank lines looking
> towards some later cleanup. Alas no one ever got around to that later
> cleanup.
>
> When looking at one port
flight 154032 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154032/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-qem
Hi,
After updating from Xen 4.13 to Xen 4.14 I have troubles starting any
HVM: just after hvmloader saying "Invoking SeaBIOS" I get "(XEN) MMIO
emulation failed (1): d29v0 32bit @ 0008:fffeedf d -> "
I come to a situation where seemingly the same domU started via xl
works, while when started via
flight 154031 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154031/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 152853
Tests which did not s
flight 154023 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154023/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 152631
test-amd64-i386-x
flight 154016 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154016/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 152849
test-amd64-amd64-xl-qemuu-ws16-amd64
Ick, I guess I'm also demonstrating how close to the head I was versus
how close I /thought/ I was.
Adjustment is pretty simple, "/arch/*/efi/ebmalloc.c" would be added to
xen/.gitignore in patch #06. "/include/*.h" would bd added to
tools/.gitignore in patch #10 (though #10 was pretty beta anywa
flight 154030 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154030/
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
The portion of the global .gitignore attributeable to tools/ocaml/ is
significant. As such, create a local .gitignore file. Currently the
OCAML bits for Xen are also somewhat contained to this one area too.
Slashes were left at the start of all filenames. Entries without slashes
match files in
stubdom/ is a significant portion of the remaining targeted matches in
the global .gitignore file.
Slashes were left at the start of all filenames. Entries without slashes
match files in subdirectories, entries with a slash anywhere are a
specific path. I feel it is more consistent to have leadi
This sorts .gitignore and cleans a few entries up.
Notably I *think* "dist/*" and "install/*" should be "/dist/*" and
"/install/*" as I'm doubting whether anyone will have those directories
anywhere, but the top. Yet on top of this there is also an entry for
"dist" which I'm unsure of.
I'm rathe
Going through and breaking targetted matches off of the top-level
.gitignore file. This is the patch to create docs/.gitignore.
Merge docs/man[1-9]/ together while I'm at it.
Slashes were left at the start of all filenames. Entries without slashes
match files in subdirectories, entries with a s
The portion of .gitignore associated with xen/ is fairly large, create a
new directory-specific .gitignore file for xen/.
Slashes were left at the start of all filenames. Entries without slashes
match files in subdirectories, entries with a slash anywhere are a
specific path. I feel it is more c
Since it seems I'm removing all path-specific entries from .gitignore,
the ones for config/ need their own file too.
Slashes were left at the start of all filenames. Entries without slashes
match files in subdirectories, entries with a slash anywhere are a
specific path. I feel it is more consis
The portion of .gitignore associated with tools/ is rather large, create
a new directory-specific .gitignore file for tools/.
git's ignore format include shell globs, but not the extensions many
shells provide. "/include/xen-foreign/*.(c|h|size)" doesn't work.
With a bunch of headers.chk files b
Subdirectories which have .gitignore files should not be referenced in
the global .gitignore files. Move several lines to appropriate subdirs.
When moved to the subdirectories the slash after the directory name is
left on as otherwise the names potentially become unanchored (without a
leading sla
The portion of the global .gitignore attributeable to tools/firmware/ is
significant. As such, create a local .gitignore file.
Several duplicate lines have been filtered out.
Several overlapping lines were merged ("_rombios*_.c" and "rombios*.s"
cover more than previous authors thought).
Slashe
"stubdom/*.tar.gz" already existed as an entry. Given the presence of
tarball ignore rules for tools, generalize the entry to match most
tarballs. Tarballs should generally be left out of git repositories and
"-f" is appropriate for the very rare exception.
Multiple "config.h" entries had been p
The top-level .gitignore file for Xen has gotten rather messy. Looks
like at times a few people may have added some blank lines looking
towards some later cleanup. Alas no one ever got around to that later
cleanup.
When looking at one portion of the situation I ended up doing some
cleanup and it
As "config.cache", "config.log" and "config.status" already have global
matching patterns, remove these subdirectory entries.
"autom4te.cache/" similarly had a global match, so remove those
duplicates.
"*.py[ocd]", "*.tmp" and "*.bin" were present, go after their duplicates
too.
"docs/txt/" cove
On Thu, Jul 23, 2020 at 11:51:52AM +0200, Lukas Wunner wrote:
> On Thu, Jul 23, 2020 at 05:13:06PM +0800, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-9):
> [...]
> > commit: 3233e41d3e8ebcd44e92da47ffed97fd49b84278 ("[PATCH] PCI: pciehp: Fix
> > AB-BA deadlock
On 09/09/2020 17:00, Jan Beulich wrote:
> On 08.09.2020 17:41, 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 ACPI region locations to the sec
flight 154015 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154015/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152332
build-amd64-xsm
On 09/09/2020 16:45, Jan Beulich wrote:
> As of de94e8b4f996 ("x86/EFI: sanitize build logic") it is identical to
> prelink_lto.o.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
>
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -135,14 +135,11 @@ ifeq ($(CONFIG_LTO),y)
flight 154005 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154005/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 152853
build-i386-xsm
MMIO regions below the maximum address on the memory map can have a
backing page struct that's shared with dom_io (see x86
arch_init_memory and it's usage of share_xen_page_with_guest), and
thus also fulfill the is_special_page check because the page has the
Xen heap bit set.
This is incorrect for
flight 154026 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154026/
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
ITSC being visible to the guest is currently implicit with the toolstack
unconditionally asking for it, and Xen clipping it based on the vTSC and/or
XEN_DOMCTL_disable_migrate settings.
This is problematic for several reasons.
First, the implicit vTSC behaviour manifests as a real bug on migratio
On Tue, Sep 08, 2020 at 08:46:58PM +, George Dunlap wrote:
>
>
> > On Sep 8, 2020, at 6:03 PM, Nick Rosbrook wrote:
> >
> > On Fri, Sep 04, 2020 at 05:40:00PM +0100, George Dunlap wrote:
> >> Remove all go files and generation targets.
> >>
> >> Add a convenience macro to build the package
On 07.09.2020 11:58, Paul Durrant wrote:
> With the comment addition...
>
> Reviewed-by: Paul Durrant
With Paul's R-b I'm intending to time out waiting for a VMX
maintainer ack early next week.
Jan
On 08.09.2020 17:41, 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 ACPI region locations to the second
> kernel which is now a requirement in Li
> -Original Message-
> From: Roger Pau Monne
> Sent: 09 September 2020 15:51
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Paul Durrant
>
> Subject: [PATCH] x86/hvm: don't treat MMIO pages as special ones regarding
> cache attr
As of de94e8b4f996 ("x86/EFI: sanitize build logic") it is identical to
prelink_lto.o.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -135,14 +135,11 @@ ifeq ($(CONFIG_LTO),y)
prelink_lto.o: $(ALL_OBJS)
$(LD_LTO) -r -o $@ $^
-prelink-efi_lto.o: $
flight 154021 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154021/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 317d84abe3bfbdff10ae1cc4f38b49307838c6c4
baseline version:
ovmf 63d92674d240ab4ecab94
On 09.09.20 16:55, Olaf Hering wrote:
On Wed, Sep 09, Juergen Gross wrote:
+++ b/tools/libs/guest/include/xenguest.h
+#include
In case this file will be installed via make install:
Does any of the pending patches create that file?
No. This include was in xenctrl_dom.h previously and ha
On Wed, Sep 09, Juergen Gross wrote:
> +++ b/tools/libs/guest/include/xenguest.h
> +#include
In case this file will be installed via make install:
Does any of the pending patches create that file?
Olaf
signature.asc
Description: PGP signature
flight 154020 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154020/
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
Hi,
On 09/09/2020 14:54, Olaf Hering wrote:
Am Wed, 9 Sep 2020 14:43:28 +0100
schrieb Julien Grall :
If you think that bridge-utils should be dropped, then please send a
proposal to remove/deprecate brctl.
This was already done with 0e7c69bd3c0b35a677d73843b39522787ccf5a3f.
The current code
Today xenctrl_dom.h is part of libxenctrl as it is included by
xc_private.c. This seems not to be needed, so merge xenctrl_dom.h into
xenguest.h where its contents really should be.
Replace all #includes of xenctrl_dom.h by xenguest.h ones or drop them
if xenguest.h is already included.
Signed-of
On 09/09/2020 10:53, Olaf Hering wrote:
> Use existing helper to allocate a bitmap.
>
> Signed-off-by: Olaf Hering
Reviewed-by: Andrew Cooper
To match the read side which is already split out. A future change will want
to use them.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/include/asm-x86/msr.h | 30 --
1 file changed, 20 insertions(+
They are currently named after the FSGSBASE instructions, but are not thin
wrappers around said instructions, and therefore do not accurately reflect the
logic they perform, especially when it comes to functioning safely in non
FSGSBASE context.
Rename them to {read,write}_{fs,gs}_base() to avoid
Save the segment selectors with explicit asm, rather than with read_sreg().
This permits the use of MOV's m16 encoding, which avoids indirecting the
selector value through a register.
For {save,load}_segments(), opencode the fs/gs helpers, as the optimiser is
unable to rearrange the logic down to
Split into two functions. Passing a load of zeros in results in somewhat poor
register scheduling in __context_switch().
Update the prefetching comment to note that the main point is the TLB fill.
Reorder the writes in svm_load_segs() to access the VMCB fields in ascending
order, which gets bett
This is follow-on work from the fixes for Linux 5.9 with FSGSBASE.
Andrew Cooper (5):
x86/asm: Rename FS/GS base helpers
x86/asm: Split __wr{fs,gs}base() out of write_{fs,gs}_base()
x86/pv: Optimise prefetching in svm_load_segs()
x86/pv: Optimise to the segment context switching paths
x8
is_pv_32bit_domain() is an expensive predicate, but isn't used for speculative
safety in this case. Swap to checking the Long Mode bit in the CPUID policy,
which is the architecturally correct behaviour.
is_canonical_address() isn't a trivial predicate, but it will become more
complicated when 5-
Am Wed, 9 Sep 2020 14:43:28 +0100
schrieb Julien Grall :
> If you think that bridge-utils should be dropped, then please send a
> proposal to remove/deprecate brctl.
This was already done with 0e7c69bd3c0b35a677d73843b39522787ccf5a3f.
The current code is just the simple form of a fallback, it d
Hi,
On 09/09/2020 14:17, Olaf Hering wrote:
Am Wed, 9 Sep 2020 14:06:42 +0100
schrieb Julien Grall :
"bridge-utils (if iroute version < ...)"
A brief search in git://git.kernel.org/pub/scm/network/iproute2/iproute2.git
shows bridge support appeared in v3.5.0 from 2012.
One can barely run X
> On 9 Sep 2020, at 13:35, Diego Sueiro wrote:
>
> Copy temp files used to add/remove dhcpd configurations to avoid
> replacing potential symlinks.
>
> If dhcp.conf is a symlink pointing to dhcp.conf.real, using 'mv'
> creates a new file dhcp.conf where cp will actually modify
> dhcp.conf.rea
On 09.09.2020 15:17, Olaf Hering wrote:
> Am Wed, 9 Sep 2020 14:06:42 +0100
> schrieb Julien Grall :
>
>> "bridge-utils (if iroute version < ...)"
>
> A brief search in git://git.kernel.org/pub/scm/network/iproute2/iproute2.git
> shows bridge support appeared in v3.5.0 from 2012.
>
> One can ba
flight 153998 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153998/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 152631
test-armhf-armhf-
Am Wed, 9 Sep 2020 14:06:42 +0100
schrieb Julien Grall :
> "bridge-utils (if iroute version < ...)"
A brief search in git://git.kernel.org/pub/scm/network/iproute2/iproute2.git
shows bridge support appeared in v3.5.0 from 2012.
One can barely run Xen on such old dists, so the patch is fine as i
On 07.09.2020 09:40, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch adds a full I/O TLB flush to the error paths of iommu_map() and
> iommu_unmap().
>
> Without this change callers need constructs such as:
>
> rc = iommu_map/unmap(...)
> err = iommu_flush(...)
> if ( !rc )
> rc = err
On 09/09/2020 13:52, Olaf Hering wrote:
Am Wed, 9 Sep 2020 13:43:10 +0100
schrieb Julien Grall :
So can you expand how this is an unusual combination?
'ip' is the tool of choice since a couple of years. What 'git grep' shows is
just compat code.
Right. I think we want to keep bridge-uti
Am Wed, 9 Sep 2020 13:43:10 +0100
schrieb Julien Grall :
> So can you expand how this is an unusual combination?
'ip' is the tool of choice since a couple of years. What 'git grep' shows is
just compat code.
Olaf
pgpHVAGHf0gSR.pgp
Description: Digitale Signatur von OpenPGP
Hi,
On 09/09/2020 11:48, Olaf Hering wrote:
Having the latest Xen, but an obsolete iproute package, is an unusual
combination.
The README suggests that bridge-utils is required for /sbin/brctl. On
Debian bullseyes:
42sh> sudo apt-file search brctl
bash-completion: /usr/share/bash-completion
>-Original Message-
>From: Wei Liu
>Sent: 07 September 2020 16:10
>To: Bertrand Marquis
>Cc: Wei Liu ; Diego Sueiro ; xen-
>de...@lists.xenproject.org; nd ; Ian Jackson
>
>Subject: Re: [PATCH 2/3] tools/hotplug: Fix dhcpd symlink removal in vif-nat
>
>On Mon, Sep 07, 2020 at 03:01:37PM +0
Copy temp files used to add/remove dhcpd configurations to avoid
replacing potential symlinks.
If dhcp.conf is a symlink pointing to dhcp.conf.real, using 'mv'
creates a new file dhcp.conf where cp will actually modify
dhcp.conf.real instead of replacing the symlink with a real
file.
Using 'cp' p
Fix some paths after reorg of library locations, and drop unreachable
maintainer.
Juergen Gross (2):
maintainers: fix libxl paths
maintainers: remove unreachable remus maintainer
MAINTAINERS | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--
2.26.2
The mails for Yang Hongyang are bouncing, remove him from MAINTAINERS
file.
Signed-off-by: Juergen Gross
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 482407b049..dab38a6a14 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -426,7 +426,6 @@ T: gi
Fix the paths of libxl in the MAINTAINERS file.
Signed-off-by: Juergen Gross
---
MAINTAINERS | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 26c5382075..482407b049 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -357,7 +357,8 @@ M: Ian
flight 154017 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154017/
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 09.09.20 13:37, David Hildenbrand wrote:
> On 09.09.20 13:24, Michael Ellerman wrote:
>> David Hildenbrand writes:
>>> On 09.09.20 09:17, Greg Kroah-Hartman wrote:
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
> We soon want to pass flags, e.g., to mark added Syste
Move the libxlutil source to tools/libs/util and delete tools/libxl.
Signed-off-by: Juergen Gross
---
.gitignore| 6 +-
tools/Makefile| 1 -
tools/Rules.mk| 7 -
tools/libs/Makefile
Carve out all libxenlight related sources and move them to
tools/libs/light in order to use the generic library build environment.
The closely related sources for libxl-save-helper and the libxl test
environment are being moved, too.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
.gitignor
The rest batch of the library build rework: the two remaining main
libraries libxenlight and libxlutil are moved to tools/libs/ directory.
Changes in V5:
- removed already applied patches (1-27)
- rebased to current xen staging
Changes in V4:
- removed already applied patches (1-8, 10)
- added ne
libxlutil doesn't follow the standard name pattern of all other Xen
libraries, so add another make variable which can be used to allow
other names.
Signed-off-by: Juergen Gross
---
tools/Rules.mk | 3 ++-
tools/libs/libs.mk | 41 +
2 files changed, 23
Rename *_libxlutil make variables to *_libxenutil in order to avoid
nasty indirections when moving libxlutil under the tools/libs
infrastructure.
Signed-off-by: Juergen Gross
---
tools/Rules.mk | 10 +-
tools/libxl/Makefile | 4 ++--
tools/xl/Makefile| 4 ++--
3 files changed
On 09.09.20 13:24, Michael Ellerman wrote:
> David Hildenbrand writes:
>> On 09.09.20 09:17, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
David Hildenbrand writes:
> On 09.09.20 09:17, Greg Kroah-Hartman wrote:
>> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
>>> We soon want to pass flags, e.g., to mark added System RAM resources.
>>> mergeable. Prepare for that.
>>
>> What are these random "flags", and how do
On Wed, Sep 09, 2020 at 11:01:19AM +0100, Andrew Cooper wrote:
> On 09/09/2020 10:53, Olaf Hering wrote:
> > Use existing helper to allocate a bitmap.
> >
> > Signed-off-by: Olaf Hering
>
> Reviewed-by: Andrew Cooper
Acked-by: Wei Liu
I've rebased pushed this patch to staging to save another
flight 153999 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153999/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 151777
build-arm64-libvirt
It mentions just stale and obsolete distributions.
They are not suitable to build current Xen, since a couple of years.
Signed-off-by: Olaf Hering
---
tools/examples/Makefile | 1 -
tools/examples/README.incompatibilities | 38 -
2 files changed, 39 delet
Having the latest Xen, but an obsolete iproute package, is an unusual
combination.
Signed-off-by: Olaf Hering
---
README | 1 -
1 file changed, 1 deletion(-)
diff --git a/README b/README
index 0e4787c1a6..ce580d3029 100644
--- a/README
+++ b/README
@@ -57,7 +57,6 @@ provided by your OS distribu
osstest service owner writes ("[xen-unstable test] 153983: regressions - FAIL"):
> flight 153983 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/153983/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> t
flight 154011 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154011/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 1e2d3be2e516e6f415ca6029f651b76a8563a27c
baseline version:
xen f4c1
flight 154014 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154014/
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
Use existing helper to allocate a bitmap.
Signed-off-by: Olaf Hering
---
tools/libxc/xc_sr_save.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index 80b1d5de1f..bc5a1a723c 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools
flight 153983 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153983/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 7 xen-boot fail REGR. vs. 152877
Regressions which
On Tue, Sep 08, 2020 at 10:10:12PM +0200, David Hildenbrand wrote:
> Let's try to merge system ram resources we add, to minimize the number
> of resources in /proc/iomem. We don't care about the boundaries of
> individual chunks we added.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "K. Y. Sri
flight 153984 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153984/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152332
build-amd64-xsm
Olaf Hering, le mer. 09 sept. 2020 10:58:28 +0200, a ecrit:
> Giving an enum a name turns it into a variable, which is bad when it is
> done in a header file that is consumbed by multiple files.
>
> ld:
> /home/abuild/rpmbuild/BUILD/xen-4.14.20200616T103126.3625b04991/non-dbg/stubdom/vtpmmgr/vtpm
flight 154010 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154010/
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
Giving an enum a name turns it into a variable, which is bad when it is
done in a header file that is consumbed by multiple files.
ld:
/home/abuild/rpmbuild/BUILD/xen-4.14.20200616T103126.3625b04991/non-dbg/stubdom/vtpmmgr/vtpmmgr.a(vtpm_cmd_handler.o):(.bss+0x0):
multiple definition of `tpm_ver
flight 154009 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154009/
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 154006 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154006/
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 09.09.20 09:17, Greg Kroah-Hartman wrote:
> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
>> We soon want to pass flags, e.g., to mark added System RAM resources.
>> mergeable. Prepare for that.
>
> What are these random "flags", and how do we know what should be passed
> t
On 09.09.20 09:16, Greg Kroah-Hartman wrote:
> On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote:
>> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
>> always set to 0 by hardware. This is far from beautiful (and confusing),
>> and the bit only applies to SY
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
> We soon want to pass flags, e.g., to mark added System RAM resources.
> mergeable. Prepare for that.
What are these random "flags", and how do we know what should be passed
to them?
Why not make this an enumerated type so that w
On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote:
> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
> always set to 0 by hardware. This is far from beautiful (and confusing),
> and the bit only applies to SYSRAM. So let's move it out of the
> bus-specific (
flight 154003 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154003/
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
92 matches
Mail list logo
