I've been looking at kexec into Xen, and from Xen.
Kexec-tools doesn't support Multiboot v2, and doesn't treat the Xen
image as relocatable. So it loads it at address zero, which causes lots
of amusement:
Firstly, head.S trusts the low memory limit found in the BDA, which has
been scribbled on. H
flight 135218 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135218/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 130965
build-i386
flight 135223 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135223/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 133580
test-arm64-arm64-xl
On Fri, 26 Apr 2019, Julien Grall wrote:
> On 4/26/19 4:48 PM, Jan Beulich wrote:
> > > > > On 26.04.19 at 17:38, wrote:
> > > On 26/04/2019 10:42, Jan Beulich wrote:
> > > > > > > On 26.04.19 at 11:19, wrote:
> > > > > So how does the PDX work for memory below 4GB? Do you still call
> > > > > pf
Hi,
On 4/26/19 4:48 PM, Jan Beulich wrote:
On 26.04.19 at 17:38, wrote:
On 26/04/2019 10:42, Jan Beulich wrote:
On 26.04.19 at 11:19, wrote:
So how does the PDX work for memory below 4GB? Do you still call
pfn_to_pdx or those pages?
Of course. We merely never compress any of the low 32 ad
On 4/26/19 10:23 PM, Julien Grall wrote:
Hi Ian,
Thank you for looking into this.
On 4/26/19 5:39 PM, Ian Jackson wrote:
Signed-off-by: Ian Jackson
CC: Julien Grall
CC: Stefano Stabellini
---
ts-kernel-build | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
dif
Hi Ian,
On 4/26/19 5:40 PM, Ian Jackson wrote:
Our armhf hosts are devboards and very slow, as well as scarce. It
5takes 17ks or so for a kernel build. This will go *much* faster on
NIT: s/5takes/takes/
an amd64 box and we have lots of those too.
standalone-generate-dump-flight-runvars sh
Hi Ian,
Thank you for looking into this.
On 4/26/19 5:39 PM, Ian Jackson wrote:
Signed-off-by: Ian Jackson
CC: Julien Grall
CC: Stefano Stabellini
---
ts-kernel-build | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/ts-kernel-build b/ts-kernel-build
Hi Ian,
On 4/18/19 5:31 PM, Ian Jackson wrote:
Sometimes we find ourselves seriously lacking the capacity to run
particular job(s). The result can be that the whole system stands
mostly idle while a small proportion of the resources runs flat out
with a giant queue.
In this series we arrange f
flight 135205 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135205/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 134594
build-arm64-xsm
Since F24, I haven't seen or heard of anyone who uses Xen over KVM anywhere
other than this thread... I'm +1 for making this test an "Optional" one.
Geoff Marr
IRC: coremodule
On Fri, Apr 26, 2019 at 10:33 AM Adam Williamson
wrote:
> On Thu, 2017-07-06 at 13:19 -0700, Adam Williamson wrote:
>
Yup +1 from my side too. Xen is hardly tested since a lot of time.
On Fri, Apr 26, 2019 at 10:07 PM Geoffrey Marr wrote:
> Since F24, I haven't seen or heard of anyone who uses Xen over KVM
> anywhere other than this thread... I'm +1 for making this test an
> "Optional" one.
>
> Geoff Marr
> IRC
On Fri, Apr 26, 2019 at 10:22:13PM +0530, Sumantro Mukherjee wrote:
> Yup +1 from my side too. Xen is hardly tested since a lot of time.
Hi!
And that is thanks to one of the GRUB2 bugs that needs some love
from Peter Jones.
As without that bug being fixed - it is very difficult to test it - as y
On 04/25/19 22:23, Igor Druzhinin wrote:
> On Xen, hvmloader firmware leaves address decoding enabled for
> enumerated PCI device before jumping into OVMF. OVMF seems to
> expect it to be disabled and tries to size PCI BARs in several places
> without disabling it which causes BAR64, for example, b
Disable it by default as it is only an experimental subsystem.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: George D
Patch cf4b30dca0a "Add debug code to detect illegal page_lock and put_page_type
ordering" added extra sanity checking to page_lock/page_unlock for debug builds
with the assumption that no hypervisor path ever locks two pages at once.
This assumption doesn't hold during memory sharing so we introdu
Improves performance for release builds.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
xen/include/asm-x86/mem_sharing.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/asm-x86/mem_sharing.h
b/xen/include/asm-x86/mem_s
Calling _put_page_type while also holding the page_lock
for that page can cause a deadlock.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Wei Liu
Cc: Roger Pau Monne
---
v3: simplified patch by keeping the additional references already in-place
---
x
flight 135317 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135317/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd 5 host-install(5) fail REGR. vs. 135233
build-amd64-free
Introduce job_create_build_crossable, which takes a target->host
architecture map in its arguments, and use it for build-kern,
passing an empty architecture map.
Overall functional change is only to add
host_arch=$arch
to the kernel build jobs, which has no ultimate effect because it's
the same
Make an explicit list of the prefixes and a loop to walk over them.
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index ec867e4f..fc
Our armhf hosts are devboards and very slow, as well as scarce. It
5takes 17ks or so for a kernel build. This will go *much* faster on
an amd64 box and we have lots of those too.
standalone-generate-dump-flight-runvars shows that the only change is
to change host_arch from armhf to amd64 in buil
No functional change.
Verified with standalone-generate-dump-flight-runvars.
Signed-off-by: Ian Jackson
---
mfi-common | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/mfi-common b/mfi-common
index f91156fe..dad03e39 100644
--- a/mfi-common
+++ b/mfi-common
@@ -216,6 +2
No functional change.
Signed-off-by: Ian Jackson
---
ts-debian-di-install | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ts-debian-di-install b/ts-debian-di-install
index 361a1710..5cb3d35d 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -152,10 +152,10 @
Change `target_var' to set `IDENT_V' rather than just V. For
compatibility with older flights and older flight construction,
look for plain V too when looking up the variable.
And, we now look at all_host_V before V. This has no functional
change with existing flights, because existing flights o
Cross building this will be much much faster and help with our severe
armhf resource shortage. To achieve this it is necessary to clean up
some technical debt, so that we can separately control host
architecture, rather than just using the job's main $r{arch}.
Ian Jackson (15):
TestSupport: tar
This is just tidying up. The only effect is that now these would
honour $r{all_guest_arch} as a fallback. But right now,
$r{GUEST_arch} will always be set, and that is what ends up in
$gho->{Arch}.
Signed-off-by: Ian Jackson
---
ts-debian-di-install | 2 +-
ts-debian-install| 2 +-
2 files
Right now this is a simple wrapper around target_cmd_build.
No functional change.
Signed-off-by: Ian Jackson
---
ts-kernel-build | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/ts-kernel-build b/ts-kernel-build
index 3dad7d36..72ca98a1 100755
--- a/ts-
With existing flights these are $r{arch} and GUEST_arch.
Nothing uses these yet.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6ab64d56..16c17e37 100644
--- a/Osstest/TestSupport.p
No functional change.
Signed-off-by: Ian Jackson
---
ts-memdisk-try-append | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-memdisk-try-append b/ts-memdisk-try-append
index 67c250bd..f6ec2fd5 100755
--- a/ts-memdisk-try-append
+++ b/ts-memdisk-try-append
@@ -23,7 +23,7 @@ a
Signed-off-by: Ian Jackson
CC: Julien Grall
CC: Stefano Stabellini
---
ts-kernel-build | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/ts-kernel-build b/ts-kernel-build
index 72ca98a1..29c6c43d 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -21,6 +
This comment was lamenting the very problem we are fixing now. It
would now be possible to test i386->amd64 tools migration, by writing
an appropriate test job with different src_host_arch and
dst_host_arch etc.
Signed-off-by: Ian Jackson
---
make-flight | 4 ++--
1 file changed, 2 insertions(+
Having it in the middle makes it quite hard to find !
No functional change.
Signed-off-by: Ian Jackson
---
ts-kernel-build | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/ts-kernel-build b/ts-kernel-build
index 29c6c43d..b9ba9ef5 100755
--- a/t
No functional change with existing flights. But the effect is that
now, generally, ts-* scripts and the support code will honour
host_arch, if it is set, in preference to arch.
This patch contains only replacements of $r{arch} with $ho->{Arch} or
$gho->{Arch}. In fact, perhaps surprisingly, ther
We are going to want to do this after selecthost.
No functional change.
Signed-off-by: Ian Jackson
---
ts-host-install | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/ts-host-install b/ts-host-install
index 45f04764..3c14f171 100755
--- a/ts-host-instal
On Thu, 2017-07-06 at 13:19 -0700, Adam Williamson wrote:
> On Thu, 2017-07-06 at 15:59 -0400, Konrad Rzeszutek Wilk wrote:
> > > > I would prefer for it to remain as it is.
> > >
> > > This is only practical if it's going to be tested, and tested regularly
> > > - not *only* on the final release
On 26/04/2019 17:22, Julien Grall wrote:
> Hi Dario,
>
> On 26/04/2019 16:13, Dario Faggioli wrote:
>> On Tue, 2019-04-23 at 12:13 +0300, Andrii Anisov wrote:
>>> Hello Dario,
>>>
>>> On 20.04.19 18:24, Dario Faggioli wrote:
In schedule(), if we pick, as the next vcpu to run (next) the same
>>
Hi Dario,
On 26/04/2019 16:13, Dario Faggioli wrote:
On Tue, 2019-04-23 at 12:13 +0300, Andrii Anisov wrote:
Hello Dario,
On 20.04.19 18:24, Dario Faggioli wrote:
In schedule(), if we pick, as the next vcpu to run (next) the same
one
that is running already (prev), we never get to call
contex
Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH 5/6] Debian: preferred
arch: Apply setarch to sshd"):
> What is wrong with setting XEN_TARGET_ARCH=x86_{64,32} ?
I considered this. (Indeed it's what I do in my own ad-hoc builds on
my workstation.) But:
Firstly it would involve maintenance
flight 135319 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135319/
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 Tue, 2019-04-23 at 12:13 +0300, Andrii Anisov wrote:
> Hello Dario,
>
> On 20.04.19 18:24, Dario Faggioli wrote:
> > In schedule(), if we pick, as the next vcpu to run (next) the same
> > one
> > that is running already (prev), we never get to call
> > context_switch().
>
> And what about `if
>>> On 26.04.19 at 17:38, wrote:
> On 26/04/2019 10:42, Jan Beulich wrote:
> On 26.04.19 at 11:19, wrote:
>>> So how does the PDX work for memory below 4GB? Do you still call
>>> pfn_to_pdx or those pages?
>>
>> Of course. We merely never compress any of the low 32 address
>> bits, i.e. our
flight 135318 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135318/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 20029ca22baaeb9418c1fd9df88d12d32d585cb6
baseline version:
ovmf c2f643479eb3f00d930c4
Hi Jan,
On 26/04/2019 10:42, Jan Beulich wrote:
On 26.04.19 at 11:19, wrote:
On 26/04/2019 10:12, Jan Beulich wrote:
On 25.04.19 at 23:27, wrote:
On 25/04/2019 18:51, Stefano Stabellini wrote:
For a first we need to gather feedback from contributors that know a bit
more of the code that may
On 26.04.19 17:06, Julien Grall wrote:
Hi,
On 26/04/2019 14:49, Andrii Anisov wrote:
On 25.04.19 23:42, Julien Grall wrote:
I am not sure why I use A.k because this is a pretty old spec.
I did mean that A.k. is not publicly available, even now, so it is not quite
right to refer such a do
On Fri, Apr 26, 2019 at 8:47 AM Jan Beulich wrote:
>
> >>> On 26.04.19 at 15:18, wrote:
> > On Fri, Apr 26, 2019 at 7:12 AM Jan Beulich wrote:
> >>
> >> >>> On 26.04.19 at 14:24, wrote:
> >> > On Fri, Apr 26, 2019 at 3:24 AM Jan Beulich wrote:
> >> >>
> >> >> >>> On 26.04.19 at 02:12, wrote:
On 26.04.19 17:31, Julien Grall wrote:
However, speaking with Mark Rutland, it would be best to keep the sequence
suggest in this patch. So SCTLR_EL2.WXN is visible before the flush and the
flush will ensure all current entries are removed. So none of the entries
should have WXN cleared.
So
>>> On 26.04.19 at 15:18, wrote:
> On Fri, Apr 26, 2019 at 7:12 AM Jan Beulich wrote:
>>
>> >>> On 26.04.19 at 14:24, wrote:
>> > On Fri, Apr 26, 2019 at 3:24 AM Jan Beulich wrote:
>> >>
>> >> >>> On 26.04.19 at 02:12, wrote:
>> >> > I would be OK with putting the whole thing behind
>> >> > CO
On 26/04/2019 15:15, Andrii Anisov wrote:
Julien,
Sorry, reply format is broken. It should be as following:
On 26.04.19 16:50, Andrii Anisov wrote:
To be honest, I am not entirely sure whether the isb() is necessary
here. At worst, an entry of an existing mappings is not cached with the
SCTL
Julien,
Sorry, reply format is broken. It should be as following:
On 26.04.19 16:50, Andrii Anisov wrote:
To be honest, I am not entirely sure whether the isb() is necessary
here. At worst, an entry of an existing mappings is not cached with the
SCTLR_EL2.WXN set. This may only defer the proble
Hi,
On 26/04/2019 14:49, Andrii Anisov wrote:
On 25.04.19 23:42, Julien Grall wrote:
I am not sure why I use A.k because this is a pretty old spec.
I did mean that A.k. is not publicly available, even now, so it is not quite
right to refer such a document, at least without mentioning it is i
On 25.04.19 23:37, Julien Grall wrote:
The understanding is correct. I am not entirely sure how I can improve
the comment.
I've re-read the comment again, and realized it actually fits. So let it be.
To be honest, I am not entirely sure whether the isb() is necessary
here. At worst, an entr
On 25.04.19 23:42, Julien Grall wrote:
I am not sure why I use A.k because this is a pretty old spec.
I did mean that A.k. is not publicly available, even now, so it is not quite
right to refer such a document, at least without mentioning it is internal.
I should
have used the last one (i.e
Hello Julien,
On 25.04.19 23:26, Julien Grall wrote:
Why can't we let the compiler deciding for us? The more that inline is
pretty broken. See:
https://www.kernel.org/doc/local/inline.html
Ah, ok. So let it be.
--
Sincerely,
Andrii Anisov.
___
Xen
On 26/04/2019 12:58, Amit Tomer wrote:
Hello,
Hi,
Could we instead try to automatically blacklist any device using PPI?
Just tested following change:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d983677..0c82976 100644
--- a/xen/arch/arm/domain_build.c
+
On Fri, Apr 26, 2019 at 7:12 AM Jan Beulich wrote:
>
> >>> On 26.04.19 at 14:24, wrote:
> > On Fri, Apr 26, 2019 at 3:24 AM Jan Beulich wrote:
> >>
> >> >>> On 26.04.19 at 02:12, wrote:
> >> > I would be OK with putting the whole thing behind
> >> > CONFIG_HAS_MEM_SHARING and having that be off
>>> On 26.04.19 at 14:24, wrote:
> On Fri, Apr 26, 2019 at 3:24 AM Jan Beulich wrote:
>>
>> >>> On 26.04.19 at 02:12, wrote:
>> > I would be OK with putting the whole thing behind
>> > CONFIG_HAS_MEM_SHARING and having that be off by default. Is that a
>> > feasible route from your POV?
>>
>> So
On Tue, 2019-04-23 at 10:44 +0100, Andrew Cooper wrote:
> On 20/04/2019 16:24, Dario Faggioli wrote:
>
> Definitely +1 to algorithm changes which avoid its use entirely.
>
> A few cosmetic observations.
>
Ok...
> > diff --git a/xen/common/sched_credit2.c
> > b/xen/common/sched_credit2.c
> > inde
On Tue, 2019-04-23 at 11:56 +0200, Juergen Gross wrote:
> On 23/04/2019 11:50, George Dunlap wrote:
> >
> > > On Apr 20, 2019, at 4:24 PM, Dario Faggioli
> > > wrote:
> > >
> > > We can, therefore, get rid of all the `if`-s testing prev and
> > > next being
> > > different, trading them with an
On Fri, Apr 26, 2019 at 3:26 AM Jan Beulich wrote:
>
> >>> On 25.04.19 at 21:57, wrote:
> > On Thu, Apr 25, 2019 at 12:58 PM Andrew Cooper
> > wrote:
> >>
> >> On 25/04/2019 16:32, Tamas K Lengyel wrote:
> >> > diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
> >> > index 6faa563
On Fri, Apr 26, 2019 at 3:24 AM Jan Beulich wrote:
>
> >>> On 26.04.19 at 02:12, wrote:
> > I would be OK with putting the whole thing behind
> > CONFIG_HAS_MEM_SHARING and having that be off by default. Is that a
> > feasible route from your POV?
>
> So is there anything wrong with my earlier su
flight 135316 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
On 26/04/2019 12:59, Andrew Cooper wrote:
> On 18/03/2019 16:13, Jan Beulich wrote:
>> All,
>>
>> the release is due by the end of the month, but will likely don't make
>> it before early April. Please point out backports you find missing from
>> the respective staging branch, but which you conside
On 18/03/2019 16:13, Jan Beulich wrote:
> All,
>
> the release is due by the end of the month, but will likely don't make
> it before early April. Please point out backports you find missing from
> the respective staging branch, but which you consider relevant. The
> one commit I've queued already
Hello,
> Could we instead try to automatically blacklist any device using PPI?
Just tested following change:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d983677..0c82976 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1289,6 +1289,1
The timer needs to remain active only until all pending IRQ instances
have seen EOIs from their respective domains. Stop it when the in-flight
count has reached zero in desc_guest_eoi(). Note that this is race free
(with __do_IRQ_guest()), as the IRQ descriptor lock is being held at
that point.
Al
>>> On 26.04.19 at 12:22, wrote:
> Currently, configuration of the SYSENTER MSRs are behind a vendor check for
> Intel and Centaur, but this misses Zhaoxin.
>
> Use the feature bit, rather than a vendor check. cpu_has_sep is cleared early
> for AMD processors, which can't use SYSENTER/SYSEXIT wh
flight 84146 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/84146/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
osstest service owner writes ("[osstest test] 135301: regressions - FAIL"):
> flight 135301 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/135301/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-arm64-
Currently, configuration of the SYSENTER MSRs are behind a vendor check for
Intel and Centaur, but this misses Zhaoxin.
Use the feature bit, rather than a vendor check. cpu_has_sep is cleared early
for AMD processors, which can't use SYSENTER/SYSEXIT when operating in long
mode.
Suggested-by: Ja
flight 135312 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135312/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
version targeted for testi
Andrew，
Do I need to submit a v3 with cpu_has_sep based solution? Or do you deal with
it?
> -Original Message-
> From: Andrew Cooper
> Sent: Thursday, April 25, 2019 9:42 PM
> To: Jan Beulich ; FionaLi-oc
> Cc: Roger Pau Monne ; Wei Liu ;
> xen-devel ; Cobe Chen(BJ-RD)
>
> Subject: Re:
>>> On 25.04.19 at 18:36, wrote:
> Alright,
>
> there was a lengthy discussion on this topic on IRC - log attached. The
> consensus appears to be to use Canonical messages with a CAPITALISED tag.
> E.g. "[TAG] Xen 4.13 Development Update".
>
> The options which seemed to have least objections
>>> On 26.04.19 at 00:59, wrote:
>> On Apr 25, 2019, at 12:36, Lars Kurth wrote:
>>
>> Alright,
>>
>> there was a lengthy discussion on this topic on IRC - log attached. The
> consensus appears to be to use Canonical messages with a CAPITALISED tag.
> E.g. "[TAG] Xen 4.13 Development Update"
>>> On 26.04.19 at 11:19, wrote:
> On 26/04/2019 10:12, Jan Beulich wrote:
> On 25.04.19 at 23:27, wrote:
>>> On 25/04/2019 18:51, Stefano Stabellini wrote:
>>> For a first we need to gather feedback from contributors that know a bit
>>> more of the code that may be affected. AFAICT, there ar
On 25/04/2019 16:32, Tamas K Lengyel wrote:
> Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing"
> introduced
> grabbing extra references for pages that drop references tied to
> PGC_allocated.
> However, these pages are actually owned by dom_cow, resulting both sharing and
> un
>>> On 25.04.19 at 21:57, wrote:
> On Thu, Apr 25, 2019 at 12:58 PM Andrew Cooper
> wrote:
>>
>> On 25/04/2019 16:32, Tamas K Lengyel wrote:
>> > diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
>> > index 6faa563167..594de6148f 100644
>> > --- a/xen/include/asm-x86/mm.h
>> > +++
>>> On 26.04.19 at 02:12, wrote:
> I would be OK with putting the whole thing behind
> CONFIG_HAS_MEM_SHARING and having that be off by default. Is that a
> feasible route from your POV?
So is there anything wrong with my earlier suggestion of
re-purposing the sharing field to attach a structure
Hi,
On 26/04/2019 10:12, Jan Beulich wrote:
On 25.04.19 at 23:27, wrote:
>> On 25/04/2019 18:51, Stefano Stabellini wrote:
>>> Xen assumes that RAM starts at addresses greater than 0x0 in a few
>>> places. The PDX code is one of them but there are more.
>>
>> A bit more context in the commit
>>> On 25.04.19 at 23:27, wrote:
> On 25/04/2019 18:51, Stefano Stabellini wrote:
>> Xen assumes that RAM starts at addresses greater than 0x0 in a few
>> places. The PDX code is one of them but there are more.
>
> A bit more context in the commit message would have been useful. Imagine
> if we
On Thu, Apr 25, 2019 at 05:44:45PM +0100, Andrew Cooper wrote:
> * Use XFREE() instead of opencoding it in nvmx_cpu_dead()
> * Avoid redundant evaluations of per_cpu()
> * Don't allocate vvmcs_buf at all if it isn't going to be used. It is never
>touched on hardware lacking the VMCS Shadowi
flight 135310 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135310/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
>>> On 26.04.19 at 00:31, wrote:
> On Thu, 25 Apr 2019, Jan Beulich wrote:
>> But I agree with Julien (in case this wasn't explicit enough from
>> my earlier replay) that it first needs to be clarified whether such
>> an interface is wanted in the first place.
>
> I have written down a few more d
>>> On 25.04.19 at 18:22, wrote:
> Although there are things that I'm not sure about:
> - whether iocaps are always used by software in Dom0 when passing
> through certain physical memory and whether their usage is enforced by Xen
I'm afraid I'm struggling to understand what exactly you mean.
Pas
84 matches
Mail list logo
