On 28.01.2020 14:56, Roger Pau Monné wrote:
> On Tue, Jan 28, 2020 at 02:17:51PM +0100, Jan Beulich wrote:
>> XOR-ing two arbitrary non-equal values may produce 1 even if both values
>> are different from both 0 and 1 (2 and 3 would fit, for example). Use OR
>> instead, which together with the earl
flight 146586 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146586/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On 29.01.2020 18:14, Andrew Cooper wrote:
> On 29/01/2020 17:03, Jan Beulich wrote:
>> The original check was not too strict: While we don't use one page of
>> memory per CPU, we do use ons page of VA space per CPU. It is the
>
> one.
>
>> latter which matters here.
>>
>> Undo that part of the ch
On 29.01.2020 19:37, Wei Liu wrote:
> On Thu, Jan 23, 2020 at 12:28:00PM +0100, Jan Beulich wrote:
>> On 22.01.2020 21:23, Wei Liu wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-x86/guest/hyperv-hcall.h
>>> @@ -0,0 +1,98 @@
>>> +/*
On 29.01.2020 20:29, PGNet Dev wrote:
> with xen cmd line opts reduced to
>
> options=dom0_max_vcpus=4 dom0_mem=4016M,max:4096M loglvl=all
> guest_loglvl=all noreboot=false sync_console=true sched_debug iommu=verbose
> apic_verbosity=verbose
>
> still no freq data/control
Sure, there was
On 30.01.20 09:18, Jan Beulich wrote:
On 29.01.2020 20:29, PGNet Dev wrote:
with xen cmd line opts reduced to
options=dom0_max_vcpus=4 dom0_mem=4016M,max:4096M loglvl=all
guest_loglvl=all noreboot=false sync_console=true sched_debug iommu=verbose
apic_verbosity=verbose
still no freq
> -Original Message-
> From: Marek Marczykowski-Górecki
> Sent: 29 January 2020 21:23
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Rzeszutek Wilk ; George
> Dunlap ; Andrew Cooper
> ; Ian Jackson
> Subject: Re: [Xen-de
On Wed, Jan 29, 2020 at 10:43:07PM +, tosher 1 wrote:
> > BTW, are you creating the driver domain with 'driver_domain=1' in the xl
> config file?
>
> No, I wasn't aware of the 'driver_domain' configuration option before, and
> this is what I was missing. With this configuration option, I wa
On 29.01.2020 17:59, PGNet Dev wrote:
> (XEN) [2020-01-29 16:44:58] Set CPU acpi_id(1) cpuid(0) Px State info:
> (XEN) [2020-01-29 16:44:58] _PCT: descriptor=130, length=12,
> space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
> (XEN) [2020-01-29 16:44:58] _PCT: descriptor=130,
On Wed, Jan 29, 2020 at 12:12:34PM +, Anthony PERARD wrote:
> Calculate the frequency of the APIC timer that Xen provides.
>
> Even though the frequency is currently hard-coded, it isn't part of
> the public ABI that Xen provides and thus may change at any time. OVMF
> needs to determine the f
On 30.01.2020 04:56, osstest service owner wrote:
> flight 146578 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/146578/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemuu-win7-a
> -Original Message-
> From: Andrew Cooper
> Sent: 29 January 2020 19:47
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: George Dunlap ; Ian Jackson
> ; Jan Beulich ; Julien Grall
> ; Konrad Rzeszutek Wilk ; Stefano
> Stabellini ; Wei Liu
> Subject: Re: [PATCH v4 1/2] docs/desi
On Thu, Jan 30, 2020 at 10:12:39AM +0100, Jan Beulich wrote:
> On 30.01.2020 04:56, osstest service owner wrote:
> > flight 146578 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/146578/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
>
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Liu
> Sent: 29 January 2020 20:20
> To: Xen Development List
> Cc: Stefano Stabellini ; Wei Liu
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George Dunlap ;
> Andrew Cooper ; Durrant, Paul
> ; Ian Jackson ; Michael
> Kelley ; Julien Gra
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 29 January 2020 20:20
> To: Xen Development List
> Cc: Durrant, Paul ; Michael Kelley
> ; Wei Liu ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Roger Pau Monné
> Subject: [PATCH v5 07/12] x86/hyperv: setup hypercall page
>
On Wed, Jan 29, 2020 at 08:20:24PM +, Wei Liu wrote:
> We want to be able to handle AP setup error in the upper layer.
Thanks, some comments below.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/guest/hypervisor.c| 6 --
> xen/arch/x86/guest/xen/xen.c | 11 +
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Liu
> Sent: 29 January 2020 20:21
> To: Xen Development List
> Cc: Stefano Stabellini ; Wei Liu
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George Dunlap ;
> Andrew Cooper ; Durrant, Paul
> ; Ian Jackson ; Michael
> Kelley ; Julien Gra
On Wed, Jan 29, 2020 at 08:20:25PM +, Wei Liu wrote:
> Push hypervisor_ap_setup down to smp_callin.
>
> Take the chance to replace xen_guest with cpu_has_hypervisor.
>
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Xen
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Liu
> Sent: 29 January 2020 20:21
> To: Xen Development List
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Durrant, Paul ;
> Michael Kelley ; Roger Pau Monné
>
> Subject: [Xen-devel] [PATCH v5 10/12] x86/hyperv: provide percpu hyper
On Wed, Jan 29, 2020 at 08:20:26PM +, Wei Liu wrote:
> Move early_cpu_init before init_e820, such that paddr_bits can be used
> by e820 code.
>
> This will reduce code repetition and prepare for further adjustment when
> L0 hypervisor comes into play.
>
> Signed-off-by: Wei Liu
Reviewed-by:
On 29.01.2020 18:10, Paul Durrant wrote:
> NOTE: steal_page() is also modified to decrement extra_pages in the case of
> a PGC_extra page being stolen from a domain.
I don't think stealing of such pages should be allowed. If anything,
the replacement page then again should be an "extra" one,
flight 146591 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146591/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On Thu, Jan 30, 2020 at 08:45:49AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Marek Marczykowski-Górecki
> > Sent: 29 January 2020 21:23
> > To: Durrant, Paul
> > Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> > ; Julien Grall ; Wei Liu
> > ; Konrad Rzeszutek W
On Wed, Jan 29, 2020 at 05:14:35PM +0100, Laszlo Ersek wrote:
> On 01/29/20 13:12, Anthony PERARD wrote:
> Assuming the OVMF platforms continue to build at this stage into the
> series, and provided that (1) and (2) are fixed:
I'll fix (1) and (2).
I've build tests both OvmfXen and OvmfPkgX64, an
On Wed, Jan 29, 2020 at 08:20:28PM +, Wei Liu wrote:
> This function will return the number of pages that need to be reserved
> in the machine address space.
>
> E820 code will use that number to adjust the maximum PFN available to
> Xen.
>
> Signed-off-by: Wei Liu
It's hard to figure out w
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 29 January 2020 20:21
> To: Xen Development List
> Cc: Durrant, Paul ; Michael Kelley
> ; Wei Liu ; Wei Liu
> ; Jan Beulich ; Andrew Cooper
> ; Roger Pau Monné
> Subject: [PATCH v5 12/12] x86/hyperv: setup VP assist page
>
> -Original Message-
> From: Jan Beulich
> Sent: 30 January 2020 10:20
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ;
> Ian Jackson ; Julien Grall ;
> Konrad Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu ; Volodymyr Babchuk
> ; Roger Pau Monn
On Wed, Jan 29, 2020 at 08:20:29PM +, Wei Liu wrote:
> Hyper-V uses a technique called overlay page for its hypercall page. It
> will insert a backing page to the guest when the hypercall functionality
> is enabled. That means we can use a page that is not backed by real
> memory for hypercall
(replying from seeing your reply on the list archives, i.e.
threading lost/broken)
On 30.01.2020 10:40, Paul Durrant wrote:
> This is getting very very complicated now, which makes me think that my
> original approach using a 'normal' page and setting an initial max_pages in
> domain_create() wa
> -Original Message-
> From: Jan Beulich
> Sent: 30 January 2020 11:02
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ;
> Ian Jackson ; Julien Grall ;
> Konrad Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu ; Volodymyr Babchuk
> ; Roger Pau Monn
On Wed, Jan 29, 2020 at 08:20:27PM +, Wei Liu wrote:
>
> +void __set_fixmap_x(
> +enum fixed_addresses_x idx, unsigned long mfn, unsigned long flags)
> +{
> +BUG_ON(idx >= __end_of_fixed_addresses_x || idx <= FIX_X_RESERVED);
> +map_pages_to_xen(__fix_x_to_virt(idx), _mfn(mfn), 1,
On Thu, Jan 30, 2020 at 11:41:43AM +0100, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 08:20:29PM +, Wei Liu wrote:
> > Hyper-V uses a technique called overlay page for its hypercall page. It
> > will insert a backing page to the guest when the hypercall functionality
> > is enabled. That m
On Thu, Jan 30, 2020 at 09:57:17AM +, Durrant, Paul wrote:
> > -static const struct hypervisor_ops ops = {
> > -.name = "Hyper-V",
> > -};
> > +static uint64_t generate_guest_id(void)
> > +{
> > +uint64_t id;
> > +
> > +id = (uint64_t)HV_XEN_VENDOR_ID << 48;
> > +id |= (xen_majo
On 17.01.2020 11:53, Anthony PERARD wrote:
> Those targets make use of $(all_sources) which depends on TARGET_ARCH,
> so we just need to set TARGET_ARCH earlier and once.
>
> XEN_TARGET_ARCH isn't expected to change during the build, so
> TARGET_SUBARCH and TARGET_ARCH aren't going to change eithe
On 17.01.2020 11:53, Anthony PERARD wrote:
> It is unnecessary to make _tests via Rules.mk because the target
> use Rules.mk as well.
>
> Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 21.01.2020 14:59, Anthony PERARD wrote:
> The top-level makefile make uses of internal implementation detail of
> the xen build system. Avoid that by creating a new target
> "install-tests" in xen/Makefile, and by fixing the top-level Makefile
> to not call xen/Rules.mk anymore.
>
> Signed-off-
On Thu, Jan 30, 2020 at 11:18:21AM +, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 11:41:43AM +0100, Roger Pau Monné wrote:
> > On Wed, Jan 29, 2020 at 08:20:29PM +, Wei Liu wrote:
> > > Hyper-V uses a technique called overlay page for its hypercall page. It
> > > will insert a backing page to
On 30/01/2020 08:09, Jan Beulich wrote:
> On 29.01.2020 18:14, Andrew Cooper wrote:
>> On 29/01/2020 17:03, Jan Beulich wrote:
>>> The original check was not too strict: While we don't use one page of
>>> memory per CPU, we do use ons page of VA space per CPU. It is the
>> one.
>>
>>> latter which
On Thu, Jan 30, 2020 at 12:39:47PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 11:18:21AM +, Wei Liu wrote:
> > On Thu, Jan 30, 2020 at 11:41:43AM +0100, Roger Pau Monné wrote:
> > > On Wed, Jan 29, 2020 at 08:20:29PM +, Wei Liu wrote:
> > > > Hyper-V uses a technique called ove
On 30/01/2020 09:15, Durrant, Paul wrote:
>>> diff --git a/docs/designs/non-cooperative-migration.md
>> b/docs/designs/non-cooperative-migration.md
>>> new file mode 100644
>>> index 00..5db3939db5
>>> --- /dev/null
>>> +++ b/docs/designs/non-cooperative-migration.md
>>> @@ -0,0 +1,272 @@
>
On Thu, Jan 30, 2020 at 09:12:14AM +0100, Jan Beulich wrote:
> On 29.01.2020 19:37, Wei Liu wrote:
> > On Thu, Jan 23, 2020 at 12:28:00PM +0100, Jan Beulich wrote:
> >> On 22.01.2020 21:23, Wei Liu wrote:
> >>> --- /dev/null
> >>> +++ b/xen/include/asm-x86/guest/hyperv-hcall.h
> >>> @@ -0,0 +1,98 @
On Thu, Jan 30, 2020 at 11:17:33AM +0100, Roger Pau Monné wrote:
> >
> > +/* This must come before e820 code becuause it sets paddr_bits. */
> ^ because
Fixed. Thanks.
Wei.
>
> Thanks, Roger.
___
Xen-de
On Wed, Jan 29, 2020 at 08:20:30PM +, Wei Liu wrote:
> These functions will be used later to make hypercalls to Hyper-V.
>
> Signed-off-by: Wei Liu
> ---
> v5:
> 1. Switch back to direct call
> 2. Fix some issues pointed out by Jan
>
> I tried using the asm(".equ ..") trick but hit a problem
On Thu, Jan 30, 2020 at 11:47:52AM +, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 12:39:47PM +0100, Roger Pau Monné wrote:
> > On Thu, Jan 30, 2020 at 11:18:21AM +, Wei Liu wrote:
> > > On Thu, Jan 30, 2020 at 11:41:43AM +0100, Roger Pau Monné wrote:
> > > > On Wed, Jan 29, 2020 at 08:20:29PM
On Wed, Jan 29, 2020 at 08:20:32PM +, Wei Liu wrote:
> Hyper-V's input / output argument must be 8 bytes aligned an not cross
> page boundary. One way to satisfy those requirements is to use percpu
> page.
>
> For the foreseeable future we only need to provide input for TLB
> and APIC hypercal
On Thu, Jan 30, 2020 at 01:08:07PM +0100, Roger Pau Monné wrote:
>
> > +}
> > +
> > /*
> > * Local variables:
> > * mode: C
> > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > index 97f9c07891..8e02b4c648 100644
> > --- a/xen/arch/x86/xen.lds.S
> > +++ b/xen/arch/x86/xen.lds.
On Thu, Jan 30, 2020 at 12:28:36PM +, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 01:08:07PM +0100, Roger Pau Monné wrote:
> >
> > > +}
> > > +
> > > /*
> > > * Local variables:
> > > * mode: C
> > > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > > index 97f9c07891..8e02b4c
Markus, what about this? Should I respin?
10.01.2020 22:41, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
Now, when preparations from
[RFC v5 000/126] error: auto propagated local_err
https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg02771.html
https://src.openvz.org/scm/~vsementsov/
On Thu, Jan 30, 2020 at 01:32:26PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 12:28:36PM +, Wei Liu wrote:
> > On Thu, Jan 30, 2020 at 01:08:07PM +0100, Roger Pau Monné wrote:
> > >
> > > > +}
> > > > +
> > > > /*
> > > > * Local variables:
> > > > * mode: C
> > > > diff --gi
On Wed, Jan 29, 2020 at 08:20:34PM +, Wei Liu wrote:
> VP assist page is rather important as we need to toggle some bits in it
> for efficient nested virtualisation.
>
> Signed-off-by: Wei Liu
> ---
> v5:
> 1. Deal with error properly instead of always panicking
> 2. Swap percpu variables dec
On Thu, Jan 30, 2020 at 10:12:51AM +0100, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 12:12:34PM +, Anthony PERARD wrote:
> > + Parameters.domid = DOMID_SELF;
> > + Parameters.gpfn = (UINTN) PagePtr >> EFI_PAGE_SHIFT;
> > + ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap,
Hi,
we use SLES12 with kernel-default-4.12.14-95.45.1.x86_64 and
xen-4.11.3_02-2.20.1.x86_64
The dump kernel doesn't start after "echo c > /proc/sysrq_trigger".
Last messages on console are:
[ 385.717532] Kernel panic - not syncing: Fatal exception
[ 385.734565] Kernel Offset: disabled
(XEN) H
On 17.01.2020 11:53, Anthony PERARD wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -49,7 +49,71 @@ default: build
> .PHONY: dist
> dist: install
>
> -build install:: include/config/auto.conf
> +
> +ifndef root-make-done
> +# section to run before calling Rules.mk, but only once.
> +#
> +
At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.
The new xc_altp2m_set_visibility() solves this by making views invisible
to vmfunc.
This is done by having a separate arch.altp2m_working_eptp that is
populated and
On 30/01/2020 12:44, Anthony PERARD wrote:
> On Thu, Jan 30, 2020 at 10:12:51AM +0100, Roger Pau Monné wrote:
>> On Wed, Jan 29, 2020 at 12:12:34PM +, Anthony PERARD wrote:
>>> + Parameters.domid = DOMID_SELF;
>>> + Parameters.gpfn = (UINTN) PagePtr >> EFI_PAGE_SHIFT;
>>> + ReturnCode = XenH
On 1/27/20 3:18 AM, sjp...@amazon.com wrote:
> From: SeongJae Park
>
> Granting pages consumes backend system memory. In systems configured
> with insufficient spare memory for those pages, it can cause a memory
> pressure situation. However, finding the optimal amount of the spare
> memory is
On Thu, Jan 30, 2020 at 11:01:29AM +0100, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 08:20:24PM +, Wei Liu wrote:
> > We want to be able to handle AP setup error in the upper layer.
>
> Thanks, some comments below.
>
> >
> > Signed-off-by: Wei Liu
> > ---
> > xen/arch/x86/guest/hyper
On 17.01.2020 11:53, Anthony PERARD wrote:
> We would like to calculate CFLAGS once and before calling Rules.mk,
> so the variable CFLAGS needs to have the same value across the whole
> build. Thus we need a new variable where some flags can change
> depending on the target name.
>
> Both the depe
On 21.01.2020 14:59, Anthony PERARD wrote:
> The XEN_BUILD_EFI tests in arch/x86/Makefile was filtering out
> CFLAGS-y, but according to dd40177c1bc8 ("x86-64/EFI: add CFLAGS to
> check compile"), it was done to filter out -MF. XEN_CFLAGS doesn't
> have those flags anymore, so no filtering is neede
On 17.01.2020 11:53, Anthony PERARD wrote:
> We are going to want $(CFLAGS) to be static and never change during
> the build, so introduce new variables that can be use to change the
> flags of a single target or of a whole directory.
I'm again struggling with the "why": What problem is there with
On Thu, Jan 30, 2020 at 10:34:29AM +, Durrant, Paul wrote:
> > +
> > +val = (virt_to_mfn(mapping) << HV_HYP_PAGE_SHIFT)
> > +| HV_X64_MSR_VP_ASSIST_PAGE_ENABLE;
>
> Perhaps it would be neater to put the viridian_page_msr union into
> hyperv-tlfs.h and then use that.
Done. Now thi
On Thu, Jan 30, 2020 at 01:42:29PM +0100, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 08:20:34PM +, Wei Liu wrote:
> > VP assist page is rather important as we need to toggle some bits in it
> > for efficient nested virtualisation.
> >
> > Signed-off-by: Wei Liu
> > ---
> > v5:
> > 1. De
On Thu, Jan 30, 2020 at 01:26:55PM +0100, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 08:20:32PM +, Wei Liu wrote:
> > Hyper-V's input / output argument must be 8 bytes aligned an not cross
> > page boundary. One way to satisfy those requirements is to use percpu
> > page.
> >
> > For the
On Thu, Jan 30, 2020 at 12:39:20PM +, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 01:32:26PM +0100, Roger Pau Monné wrote:
> > On Thu, Jan 30, 2020 at 12:28:36PM +, Wei Liu wrote:
> > > On Thu, Jan 30, 2020 at 01:08:07PM +0100, Roger Pau Monné wrote:
> > > >
> > > > > +}
> > > > > +
> > > > >
On Thu, Jan 30, 2020 at 03:22:01PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 12:39:20PM +, Wei Liu wrote:
> > On Thu, Jan 30, 2020 at 01:32:26PM +0100, Roger Pau Monné wrote:
> > > On Thu, Jan 30, 2020 at 12:28:36PM +, Wei Liu wrote:
> > > > On Thu, Jan 30, 2020 at 01:08:07PM
On 17.01.2020 11:53, Anthony PERARD wrote:
> Instead of generating the CFLAGS in Rules.mk everytime we enter a new
> subdirectory, we are going to generate most of them a single time, and
> export the result in the environment so that Rules.mk can use it. The
> only flags left to generates are the
Hi Oleksandr,
Hi Volodymyr
@@ -434,19 +435,45 @@ static void ipmmu_tlb_invalidate(struct ipmmu_vmsa_domain
*domain)
}
/* Enable MMU translation for the micro-TLB. */
-static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain *domain,
- unsigned int utlb)
+
There's no need to have twice almost the same rule. Simply add the extra
-DEFI to AFLAGS for the EFI variant, and specify both targets for the
then single rule.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -241,15 +241,12 @@ $(BASEDIR)/include/generated/c
On Thu, Jan 30, 2020 at 02:25:26PM +, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 03:22:01PM +0100, Roger Pau Monné wrote:
> > On Thu, Jan 30, 2020 at 12:39:20PM +, Wei Liu wrote:
> > > On Thu, Jan 30, 2020 at 01:32:26PM +0100, Roger Pau Monné wrote:
> > > > On Thu, Jan 30, 2020 at 12:28:36PM
On 30/01/2020 14:44, Jan Beulich wrote:
> There's no need to have twice almost the same rule. Simply add the extra
> -DEFI to AFLAGS for the EFI variant, and specify both targets for the
> then single rule.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefil
flight 146595 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146595/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
I'm very sad to inform you that Lars Kurth passed away earlier this
week. Many of us regarded Lars as a personal friend, and his loss is a
great loss to the Xen Project.
We plan to have a tribute to Lars on the XenProject blog in the near
future. Those who are attending FOSDEM may wish to attend
This patch adds a new domain_tot_pages() inline helper function into
sched.h, which will be needed by a subsequent patch.
No functional change.
NOTE: While modifying the comment for 'tot_pages' in sched.h this patch
makes some cosmetic fixes to surrounding comments.
Suggested-by: Jan Beuli
... to domain_relinquish_resources().
The teardown code frees the APICv page. This does not need to be done late
so do it in domain_relinquish_resources() rather than domain_destroy().
Signed-off-by: Paul Durrant
---
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei L
Currently it is unsafe to assign a domheap page allocated with
MEMF_no_refcount to a domain because the domain't 'tot_pages' will not
be incremented, but will be decrement when the page is freed (since
free_domheap_pages() has no way of telling that the increment was skipped).
This patch allocates
Paul Durrant (4):
x86 / vmx: move teardown from domain_destroy()...
add a domain_tot_pages() helper function
mm: make pages allocated with MEMF_no_refcount safe to assign
x86 / vmx: use a MEMF_no_refcount domheap page for
APIC_DEFAULT_PHYS_BASE
xen/arch/x86/domain.c | 2 +-
vmx_alloc_vlapic_mapping() currently contains some very odd looking code
that allocates a MEMF_no_owner domheap page and then shares with the guest
as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
to call a special function in the mm code: free_shared_domheap_page().
By u
On Thu, Jan 30, 2020 at 03:47:04PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 02:25:26PM +, Wei Liu wrote:
> > On Thu, Jan 30, 2020 at 03:22:01PM +0100, Roger Pau Monné wrote:
> > > On Thu, Jan 30, 2020 at 12:39:20PM +, Wei Liu wrote:
> > > > On Thu, Jan 30, 2020 at 01:32:26PM
Hi Oleksandr,
Oleksandr writes:
[...]
>>> +
>>> +/*
>>> + * We need to prevent the use cases where devices which use the same
>>> + * micro-TLB are assigned to different Xen domains (micro-TLB cannot be
>>> + * shared between multiple Xen domains, since it points to the context
flight 146597 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146597/
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
Volodymyr Babchuk writes:
Oleksandr,
[...]
>> diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> index c21d2d7..411fc0f 100644
>> --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> @@ -702,7 +70
flight 146584 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146584/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 17 guest-start.2 fail REGR.
vs. 146563
build-a
On 30.01.2020 15:47, Andrew Cooper wrote:
> On 30/01/2020 14:44, Jan Beulich wrote:
>> There's no need to have twice almost the same rule. Simply add the extra
>> -DEFI to AFLAGS for the EFI variant, and specify both targets for the
>> then single rule.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a
flight 146589 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146589/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
On Thu, Jan 30, 2020 at 03:03:03PM +, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 03:47:04PM +0100, Roger Pau Monné wrote:
> > On Thu, Jan 30, 2020 at 02:25:26PM +, Wei Liu wrote:
> > > On Thu, Jan 30, 2020 at 03:22:01PM +0100, Roger Pau Monné wrote:
> > > > On Thu, Jan 30, 2020 at 12:39:20PM
On 30.01.2020 10:18, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 10:12:39AM +0100, Jan Beulich wrote:
>> On 30.01.2020 04:56, osstest service owner wrote:
>>> flight 146578 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/146578/
>>>
>>> Regressions :-(
>>>
>>> Tes
I am deeply shocked by the news. I would like to express my deepest condolences
to Lars' family and friends. Lars has always been a very open-minded and
supportive person. He was definitely a big win for the Xen Project and its
community. I feel honored to have had the chance to work with him.
On Thu, Jan 30, 2020 at 04:25:44PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 03:03:03PM +, Wei Liu wrote:
> > On Thu, Jan 30, 2020 at 03:47:04PM +0100, Roger Pau Monné wrote:
> > > On Thu, Jan 30, 2020 at 02:25:26PM +, Wei Liu wrote:
> > > > On Thu, Jan 30, 2020 at 03:22:01PM
From: David Woodhouse
The live update handover requires that a region of memory be reserved
for the new Xen to use in its boot allocator. The original Xen may use
that memory but not for any pages which are mapped to domains, or which
would need to be preserved across the live update for any othe
Now with added documentation:
http://david.woodhou.se/live-update-handover.pdf
v1:
Reserve a contiguous region of memory which can be safely used by the
boot allocator in the new Xen, before the live update data stream has
been processed and thus before the locations of all the other pages
which
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/arch/x86/setup.c | 35 +--
xen/common/lu/stream.c | 34 ++
xen/include/xen/lu.h | 2 ++
3 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/
From: David Woodhouse
Signed-off-by: David Woodhouse
---
docs/specs/libxc-migration-stream.pandoc | 19 +-
docs/specs/live-update-handover.pandoc | 371 +++
2 files changed, 388 insertions(+), 2 deletions(-)
create mode 100644 docs/specs/live-update-handover.pandoc
diff
flight 146588 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
test-amd64-amd64-xl-
From: David Woodhouse
Remove a ternary operator that made my brain hurt and replace it with
something simpler that makes it clearer that the >= mbi->mods_count
is because of what find_first_bit() returns when it doesn't find
anything. Just have a simple condition to set initrdidx to zero in
that
From: David Woodhouse
Set 'e' correctly to reflect the location that Xen is actually relocated
to from its default 2MiB location. Not 2MiB below that.
This is only vaguely a bug fix. The "missing" 2MiB would have been used
in the end, and fed to the allocator. It's just that other things don't
g
From: David Woodhouse
This allows kexec userspace to tell the next Xen where the range is,
on its command line.
Signed-off-by: David Woodhouse
---
xen/arch/x86/machine_kexec.c | 13 ++---
xen/include/public/kexec.h | 1 +
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/lu/save.c | 13 -
xen/include/public/migration_stream.h | 9 +
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/xen/common/lu/save.c b/xen/common/lu/save.c
index c43962c44e..8
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/page_alloc.c | 83 +++--
1 file changed, 80 insertions(+), 3 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index a74bf02559..4ada4412dd 100644
--- a/xen/common/
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/Makefile| 1 +
xen/common/lu/Makefile | 1 +
xen/common/lu/stream.c | 135 +
xen/include/xen/lu.h | 29 +
4 files changed, 166 insertions(+)
create mode 100644 xen/com
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/vmap.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 37922f735b..8343460794 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -6
1 - 100 of 148 matches
Mail list logo
