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
> > > > >
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
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
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 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
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
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
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
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
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
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
> >
>>> 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?
>>
>>
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.
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.
___
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
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
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
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 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
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
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
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
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,
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
---
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
---
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
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
---
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
---
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 @@
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
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
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
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:
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
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,
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
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
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
---
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
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
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
>
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:
>
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
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
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/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
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(-)
flight 135185 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135185/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134611
build-arm64
>>> 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.
>>> 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
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
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:
>>> 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 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 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
>
>>> 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
>>> 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
>>> 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
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
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
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
>>> 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
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:
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:
>
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
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
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.
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:
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
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
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.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
>> >> >
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
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
>>> 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
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
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
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
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
84 matches
Mail list logo
