>>> On 11.06.19 at 18:09, wrote:
> On 07.06.19 17:23, Jan Beulich wrote:
> On 24.05.19 at 20:12, wrote:
>>> From: Andrii Anisov
>>>
>>> Existing interface to register runstate are with its virtual address
>>> is prone to issues which became more obvious with KPTI enablement in
>>> guests. Th
flight 137576 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137576/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 9694d3c1a707ebfc10d407f51d669bba0f958359
baseline version:
freebsd 8ebeb68c968
On 6/12/19 14:34, Jan Beulich wrote:
On 12.06.19 at 02:23, wrote:
On 6/11/19 22:03, Jan Beulich wrote:
On 11.06.19 at 08:02, wrote:
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -240,12 +240,14 @@ SECTIONS
*(.altinstructions)
__alt_instructions_end = .;
>>> On 11.06.19 at 18:04, wrote:
> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
>> On Wed, Jun 05, 2019 at 08:53:46AM -0600, Jan Beulich wrote:
>> >
>> >> @@ -307,8 +303,7 @@ static int apply_microcode(const struct
>> >> microcode_patch
> *patch)
>> >>
>> >> mc_intel = patch-
>>> On 11.06.19 at 18:55, wrote:
> On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
>> Instead of setting the scheduler percpu lock address in each of the
>> switch_sched instances of the different schedulers do that in
>> schedule_cpu_switch() which is the single caller of that function.
>
>>> On 11.06.19 at 20:52, wrote:
> Julien Grall writes:
>> Volodymyr was going to resend the series with documentation (as a
>> separate patch). But I would be happy to take #1 and #2 assuming that
>> documentation patch is going to be sent.
>
> Yes, sorry for the delay. I'm going to send resend
>>> On 11.06.19 at 21:56, wrote:
> Hi,
>
> On 11/06/2019 19:37, Stefano Stabellini wrote:
>> On Tue, 14 May 2019, Julien Grall wrote:
>>> Currently, the MFN will be incremented even if it is invalid. This will
>>> result to have a valid MFN after the first iteration.
>>>
>>> While this is not a m
>>> On 12.06.19 at 09:36, wrote:
> On 6/12/19 14:34, Jan Beulich wrote:
> On 12.06.19 at 02:23, wrote:
>>> On 6/11/19 22:03, Jan Beulich wrote:
>>> On 11.06.19 at 08:02, wrote:
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -240,12 +240,14 @@ SECTIONS
>>>
On 28/05/2019 11:32, Juergen Gross wrote:
> @@ -1870,8 +1871,19 @@ int schedule_cpu_switch(unsigned int cpu, struct
> cpupool *c)
> old_lock = pcpu_schedule_lock_irq(cpu);
>
> vpriv_old = idle->sched_priv;
> -ppriv_old = per_cpu(schedule_data, cpu).sched_priv;
> -sched_switch_s
On 12.06.19 09:40, Jan Beulich wrote:
On 11.06.19 at 18:55, wrote:
On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
Instead of setting the scheduler percpu lock address in each of the
switch_sched instances of the different schedulers do that in
schedule_cpu_switch() which is the single
On 12.06.19 10:05, Andrew Cooper wrote:
On 28/05/2019 11:32, Juergen Gross wrote:
@@ -1870,8 +1871,19 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool
*c)
old_lock = pcpu_schedule_lock_irq(cpu);
vpriv_old = idle->sched_priv;
-ppriv_old = per_cpu(schedule_data, cpu
On 6/12/19 15:58, Jan Beulich wrote:
On 12.06.19 at 09:36, wrote:
On 6/12/19 14:34, Jan Beulich wrote:
On 12.06.19 at 02:23, wrote:
On 6/11/19 22:03, Jan Beulich wrote:
On 11.06.19 at 08:02, wrote:
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -240,12 +240,14 @@ SECTIONS
Hi,
On 6/12/19 6:42 AM, Baodong Chen wrote:
Swap function can be used when calling sort().
or else, the default swap function generic_swap() is used,
which is a little inefficient.
I am not entirely convince this will be more efficient. mmio_handler
does not fit in 64 bit, so the compiler may
Hi all,
Any remarks on the patch at hand are appreciated.
Thanks,
Alex
On 04.06.2019 14:49, Alexandru Stefan ISAILA wrote:
> This patch aims to have mem access vm events sent from the emulator.
> This is useful where we want to only emulate a page walk without
> checking the EPT, but we still wa
>>> On 12.06.19 at 10:19, wrote:
> On 12.06.19 10:05, Andrew Cooper wrote:
>> On 28/05/2019 11:32, Juergen Gross wrote:
>>> @@ -1870,8 +1871,19 @@ int schedule_cpu_switch(unsigned int cpu, struct
> cpupool *c)
>>> old_lock = pcpu_schedule_lock_irq(cpu);
>>>
>>> vpriv_old = idle->sc
From: Andrii Anisov
The vcpu structure member last_run_time is used by credit scheduler only.
In order to get better encapsulation, it is moved from a generic
structure to the credit scheduler private vcpu definition. Also, rename
the member to last_sched_time in order to reflect that it is the t
On Tue, 2019-05-28 at 13:52 +0200, Juergen Gross wrote:
> On 28/05/2019 13:44, Jan Beulich wrote:
> > > > > On 28.05.19 at 12:33, wrote:
> > > --- a/xen/arch/x86/sysctl.c
> > > +++ b/xen/arch/x86/sysctl.c
> > > @@ -200,7 +200,8 @@ long arch_do_sysctl(
> > >
> > > case XEN_SYSCTL_CPU_HOT
On Wed, 2019-06-12 at 10:06 +0200, Juergen Gross wrote:
> On 12.06.19 09:40, Jan Beulich wrote:
> > > > > On 11.06.19 at 18:55, wrote:
> > > On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> > > > Signed-off-by: Juergen Gross
> > > >
> > > Reviewed-by: Dario Faggioli
> > >
> > > I'm wo
On Wed, 2019-06-12 at 10:32 +0100, Jan Beulich wrote:
> > > > On 12.06.19 at 10:19, wrote:
> > On 12.06.19 10:05, Andrew Cooper wrote:
> > > On 28/05/2019 11:32, Juergen Gross wrote:
> > > >
> > > > +per_cpu(scheduler, cpu) = new_ops;
> > > > +sd->sched_priv = ppriv;
> > > > +
> > > > +
flight 137672 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137672/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 480800c76969b38f13b6909eb679b23571417538
baseline version:
xen c066
On 6/12/19 17:08, Julien Grall wrote:
Hi,
On 6/12/19 6:42 AM, Baodong Chen wrote:
Swap function can be used when calling sort().
or else, the default swap function generic_swap() is used,
which is a little inefficient.
I am not entirely convince this will be more efficient. mmio_handler
doe
When running as a Xen guest selecting "nosmt" either via command line
or implicitly via default settings makes no sense, as the guest has no
clue about the real system topology it is running on. With Xen it is
the hypervisor's job to ensure the proper bug mitigations are active
regarding smt settin
>>> On 12.06.19 at 11:56, wrote:
> On Wed, 2019-06-12 at 10:32 +0100, Jan Beulich wrote:
>> > > > On 12.06.19 at 10:19, wrote:
>> > On 12.06.19 10:05, Andrew Cooper wrote:
>> > > On 28/05/2019 11:32, Juergen Gross wrote:
>> > > >
>> > > > +per_cpu(scheduler, cpu) = new_ops;
>> > > > +sd-
>>> On 12.06.19 at 12:12, wrote:
> When running as a Xen guest selecting "nosmt" either via command line
> or implicitly via default settings makes no sense, as the guest has no
> clue about the real system topology it is running on. With Xen it is
> the hypervisor's job to ensure the proper bug m
On 12.06.19 12:19, Jan Beulich wrote:
On 12.06.19 at 12:12, wrote:
When running as a Xen guest selecting "nosmt" either via command line
or implicitly via default settings makes no sense, as the guest has no
clue about the real system topology it is running on. With Xen it is
the hypervisor's j
On Wed, 2019-06-12 at 12:35 +0300, Andrii Anisov wrote:
> From: Andrii Anisov
>
> The vcpu structure member last_run_time is used by credit scheduler
> only.
> In order to get better encapsulation, it is moved from a generic
> structure to the credit scheduler private vcpu definition. Also,
> ren
flight 137574 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137574/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which did not
The current code in do_boot_cpu() makes a CMOS write (even in the case of an
FADT reduced hardware configuration) and two writes into the BDA for the
start_eip segment and offset.
BDA 0x67 and 0x69 hail from the days of the DOS and the 286, when IBM put
together the fast way to return from Protect
(Moving from xen-users to xen-devel).
On 11/06/2019 23:18, Stefano Stabellini wrote:
I managed to reproduced the issue, and I know how to get past it. Try
using the raw kernel Image (arch/arm64/boot/Image) instead of Image.gz
for dom0 and domU. That fixed it for me.
Julien, I didn't manage to
On 12/06/2019 11:14, Jan Beulich wrote:
On 12.06.19 at 11:56, wrote:
>> On Wed, 2019-06-12 at 10:32 +0100, Jan Beulich wrote:
>> On 12.06.19 at 10:19, wrote:
On 12.06.19 10:05, Andrew Cooper wrote:
> On 28/05/2019 11:32, Juergen Gross wrote:
>> +per_cpu(scheduler, cpu) =
>>> On 12.06.19 at 13:05, wrote:
> The current code in do_boot_cpu() makes a CMOS write (even in the case of an
> FADT reduced hardware configuration) and two writes into the BDA for the
> start_eip segment and offset.
>
> BDA 0x67 and 0x69 hail from the days of the DOS and the 286, when IBM put
On 12/06/2019 12:51, Jan Beulich wrote:
On 12.06.19 at 13:05, wrote:
>> The current code in do_boot_cpu() makes a CMOS write (even in the case of an
>> FADT reduced hardware configuration) and two writes into the BDA for the
>> start_eip segment and offset.
>>
>> BDA 0x67 and 0x69 hail from t
>>> On 12.06.19 at 13:55, wrote:
> On 12/06/2019 12:51, Jan Beulich wrote:
> On 12.06.19 at 13:05, wrote:
>>> The current code in do_boot_cpu() makes a CMOS write (even in the case of an
>>> FADT reduced hardware configuration) and two writes into the BDA for the
>>> start_eip segment and off
On Wed, 2019-06-12 at 06:00 -0600, Jan Beulich wrote:
> > > > Reported-by: David Woodhouse
> > >
> > > Does this mean there was an actual problem resulting from this code
> > > being there, or simply the observation that this code is all dead?
> > > Clarifying one way or the other by half a sente
On 12/06/2019 13:14, David Woodhouse wrote:
> On Wed, 2019-06-12 at 06:00 -0600, Jan Beulich wrote:
> Reported-by: David Woodhouse
Does this mean there was an actual problem resulting from this code
being there, or simply the observation that this code is all dead?
Clarifying on
Hi,
On 12/06/2019 11:08, chenbaodong wrote:
On 6/12/19 17:08, Julien Grall wrote:
Hi,
On 6/12/19 6:42 AM, Baodong Chen wrote:
Swap function can be used when calling sort().
or else, the default swap function generic_swap() is used,
which is a little inefficient.
I am not entirely convince
On Wed, 2019-06-12 at 13:20 +0100, Andrew Cooper wrote:
> You definitely complained about the BDA on IRC, which is why I started
> looking, but I'm happy to leave you out of the patch if you'd prefer.
I did indeed complain about the BDA, but mostly when we were reading
the amount of memory availab
On 12/06/2019 13:23, David Woodhouse wrote:
> On Wed, 2019-06-12 at 13:20 +0100, Andrew Cooper wrote:
>> You definitely complained about the BDA on IRC, which is why I started
>> looking, but I'm happy to leave you out of the patch if you'd prefer.
> I did indeed complain about the BDA, but mostly
When a message is requeue'd in Xen's internal queue, the queue
entry contains the length of the message so that Xen knows to
send a VIRQ to the respective domain when enough space frees up
in the ring. Due to a small bug, however, Xen doesn't populate
the length of the msg if a given write fails, s
On 12/06/2019 13:34, Nicholas Tsirakis wrote:
> When a message is requeue'd in Xen's internal queue, the queue
> entry contains the length of the message so that Xen knows to
> send a VIRQ to the respective domain when enough space frees up
> in the ring. Due to a small bug, however, Xen doesn't po
Hi,
On 11/06/2019 21:24, Andrew Cooper wrote:
On 11/06/2019 20:56, Julien Grall wrote:
On 11/06/2019 19:37, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
Currently, the MFN will be incremented even if it is invalid. This will
result to have a valid MFN after the first ite
The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
counter MSRs, hardware configuration MSR, MMIO configuration base address
MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to the
PV emulation infrastructure by using the code path of AMD.
[Rebase over 0cd0
Add Hygon Dhyana support to the acpi cpufreq and cpuidle subsystems by
using the code path of AMD.
[Rebase over 0cd07414 "x86/cpu: Renumber X86_VENDOR_* to form a bitmap"]
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/acpi/cpu_idle.c | 3 ++-
xen/arch/x86/acpi/cpufreq/cp
Hi Stefano,
On 11/06/2019 23:35, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
At the moment, the flags are not enough to describe what kind of update
will done on the VA range. They need to be used in conjunction with the
enum xenmap_operation.
It would be more convenient
On 12/06/2019 13:54, Pu Wen wrote:
> The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
> counter MSRs, hardware configuration MSR, MMIO configuration base address
> MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to the
> PV emulation infrastructure by usi
On Wed, Jun 12, 2019 at 12:12:28PM +0200, Juergen Gross wrote:
> When running as a Xen guest selecting "nosmt" either via command line
> or implicitly via default settings makes no sense, as the guest has no
> clue about the real system topology it is running on. With Xen it is
> the hypervisor's j
On Wed, 2019-06-12 at 12:27 +0100, Andrew Cooper wrote:
> It is a consequence of our extra magic scheduler locks which protect
> the
> pointer used to locate them, and the ensuing double-step in ???
> (seriously - I can't figure out the function names created by the
> sched_lock() monstrosity) whic
On Wed, Jun 12, 2019 at 8:47 AM Andrew Cooper wrote:
>
> On 12/06/2019 13:34, Nicholas Tsirakis wrote:
> > When a message is requeue'd in Xen's internal queue, the queue
> > entry contains the length of the message so that Xen knows to
> > send a VIRQ to the respective domain when enough space fre
flight 137675 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137675/
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 Stefano,
On 12/06/2019 01:10, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The code handling Xen PT update has quite a few restrictions on what it
can do. This is not a bad thing as it keeps the code simple.
There are already a few checks scattered in current page tabl
On 12.06.19 13:48, Peter Zijlstra wrote:
On Wed, Jun 12, 2019 at 12:12:28PM +0200, Juergen Gross wrote:
When running as a Xen guest selecting "nosmt" either via command line
or implicitly via default settings makes no sense, as the guest has no
clue about the real system topology it is running o
On 2019/6/7 0:31, Andrew Cooper wrote:
I've rebased the patches over my CPUID work, and pushed the ones which
still apply cleanly to staging. However, some don't apply cleanly any
more, so I left those alone.
Please could you check the current staging build (and in particular,
that I didn't acc
Hi,
This patch is fully committed now.
Thank you for the reviews!
Cheers,
On 14/05/2019 13:11, Julien Grall wrote:
Hi all,
I spent the last few months looking at Xen boot and memory management to make
it simpler, more efficient and also more compliant in respect of the Arm Arm.
The full rew
On Wed, 12 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 12/06/2019 01:10, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > The code handling Xen PT update has quite a few restrictions on what it
> > > can do. This is not a bad thing as it keeps the code simple.
>
On Wed, 12 Jun 2019, Julien Grall wrote:
> Hi,
>
> On 11/06/2019 21:24, Andrew Cooper wrote:
> > On 11/06/2019 20:56, Julien Grall wrote:
> > > On 11/06/2019 19:37, Stefano Stabellini wrote:
> > > > On Tue, 14 May 2019, Julien Grall wrote:
> > > > > Currently, the MFN will be incremented even if i
Hi,
On 12/06/2019 16:54, Stefano Stabellini wrote:
On Wed, 12 Jun 2019, Julien Grall wrote:
On 12/06/2019 01:10, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
I understand we could skip the valid check on REMOVE, but should we skip
it on MODIFY too? Is that also going to b
On 12/06/2019 16:10, Pu Wen wrote:
> On 2019/6/7 0:31, Andrew Cooper wrote:
>> I've rebased the patches over my CPUID work, and pushed the ones which
>> still apply cleanly to staging. However, some don't apply cleanly any
>> more, so I left those alone.
>>
>> Please could you check the current st
Remove myself as vm_event maintaner, add Alexandru and Petre as
Bitdefender vm_event maintainers.
Signed-off-by: Razvan Cojocaru
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6fbdc2b..d60e3a5 100644
--- a/MAINTAINERS
+++ b/M
flight 137583 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137583/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-pvshim 7 xen-boot fail in 137475 pass in 137583
test-amd64-amd64-xl-qemuu-de
On 6/12/19 7:02 PM, Razvan Cojocaru wrote:
Remove myself as vm_event maintaner, add Alexandru and Petre as
Bitdefender vm_event maintainers.
Signed-off-by: Razvan Cojocaru
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6f
flight 137575 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137575/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 137388
test-amd64-amd64-xl-
On 12/06/2019 17:08, Razvan Cojocaru wrote:
On 6/12/19 7:02 PM, Razvan Cojocaru wrote:
Remove myself as vm_event maintaner, add Alexandru and Petre as
Bitdefender vm_event maintainers.
Signed-off-by: Razvan Cojocaru
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
flight 137584 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137584/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 136977
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
flight 137676 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137676/
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 Stefano,
On 5/2/19 12:30 AM, Stefano Stabellini wrote:
Improve Dom0-less documentation: include a complete configuration
example.
Signed-off-by: Stefano Stabellini
diff --git a/docs/features/dom0less.pandoc b/docs/features/dom0less.pandoc
index 4e342b7..e076e37 100644
--- a/docs/features/d
On Wed, Jun 12, 2019 at 5:35 AM Nicholas Tsirakis
wrote:
>
> When a message is requeue'd in Xen's internal queue, the queue
> entry contains the length of the message so that Xen knows to
> send a VIRQ to the respective domain when enough space frees up
> in the ring. Due to a small bug, however,
On 12/06/2019 20:58, Christopher Clark wrote:
> On Wed, Jun 12, 2019 at 5:35 AM Nicholas Tsirakis
> wrote:
>> When a message is requeue'd in Xen's internal queue, the queue
>> entry contains the length of the message so that Xen knows to
>> send a VIRQ to the respective domain when enough space fr
On 09/05/2019 18:25, Ankur Arora wrote:
> xen_cpuid_base() is used to probe and setup features early in a
> guest's lifetime.
>
> We want this to behave differently depending on xenhost->type: for
> instance, local xenhosts cannot intercept the cpuid instruction at all.
>
> Add op (*cpuid_base)() i
On 09/05/2019 18:25, Ankur Arora wrote:
> Allow for different hypercall implementations for different xenhost types.
> Nested xenhost, which has two underlying xenhosts, can use both
> simultaneously.
>
> The hypercall macros (HYPERVISOR_*) implicitly use the default xenhost.x
> A new macro (hyperv
branch xen-4.11-testing
xenbranch xen-4.11-testing
job test-arm64-arm64-xl-credit2
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/x
flight 137679 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137679/
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
flight 137595 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137595/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 562688707145df9d695f3fc3cb9524f3881f0e2c
baseline version:
ovmf f0718d1d6b47745a4249f
On Tue, 14 May 2019, Julien Grall wrote:
> With the newly introduced flags, it is now possible to know how the page
> will be updated through the flags.
>
> All the use of xenmap_operation are now replaced with the flags. At the
> same time, validity check are now removed as they are gathered in
>
On Tue, 14 May 2019, Julien Grall wrote:
> Currently, the virtual address of the 3rd level page-tables is obtained
> using mfn_to_virt().
>
> On Arm32, mfn_to_virt can only work on xenheap page. While in practice
> all the page-tables updated will reside in xenheap, in practive the
On Tue, 14 May 2019, Julien Grall wrote:
> {set, clear}_fixmap() are currently open-coding update to the Xen
> page-tables. This can be avoided by using the generic helpers
> map_pages_to_xen() and destroy_xen_mappings().
>
> Both function are not meant to fail for fixmap, hence the BUG_ON()
> che
On Tue, 14 May 2019, Julien Grall wrote:
> set_pte_flags_on_range() is yet another function that will open-code
> update to a specific range in the Xen page-tables. It can be completely
> dropped by using either modify_xen_mappings() or destroy_xen_mappings().
>
> Signed-off-by: Julien Grall
> Re
flight 137589 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137589/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-qem
On Tue, 14 May 2019, Julien Grall wrote:
> Currently, xen_pt_update_entry() is only able to update the region covered
> by xen_second (i.e 0 to 0x7fff).
>
> Because of the restriction we end to have multiple functions in mm.c
> modifying the page-tables differently.
>
> Furthermore, we never
flight 137592 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137592/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd
On 6/12/19 20:21, Julien Grall wrote:
Hi,
On 12/06/2019 11:08, chenbaodong wrote:
On 6/12/19 17:08, Julien Grall wrote:
Hi,
On 6/12/19 6:42 AM, Baodong Chen wrote:
Swap function can be used when calling sort().
or else, the default swap function generic_swap() is used,
which is a little in
flight 137683 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137683/
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
flight 137604 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137604/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 137460
test-armhf-armhf-libvirt-raw 13 saveresto
flight 137600 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137600/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 137492
test-amd64-i386-xl-qemuu-win7-amd64
flight 137618 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137618/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16
guest-start/debianhvm.repeat fail in 137513 RE
To improve TLB shootdown performance, flush the remote and local TLBs
concurrently. Introduce flush_tlb_multi() that does so. The current
flush_tlb_others() interface is kept, since paravirtual interfaces need
to be adapted first before it can be removed. This is left for future
work. In such PV en
85 matches
Mail list logo
