flight 146583 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146583/
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
flight 146581 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146581/
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
flight 146580 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146580/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
146121
test-amd64-i3
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-amd64 7 xen-boot fail REGR. vs. 146563
test-amd64-amd64-x
On 1/29/20 4:10 AM, Dario Faggioli wrote:
> On Wed, 2020-01-22 at 18:56 +, Jim Fehlig wrote:
>> On 1/21/20 10:05 AM, Jürgen Groß wrote:
>>> On 21.01.20 17:56, Kevin Stange wrote:
Since Xen 4.12, credit2 is the default scheduler, but at least as
of
libvirt 5.1.0 virsh doesn't
flight 146582 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146582/
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
George,
Note that without your patch "golang/xenlight: Don't try to marshall
zero-length arrays in fromC", some of these constructors will panic.
Thanks,
-NR
On Wed, Jan 29, 2020 at 7:09 PM Nick Rosbrook wrote:
>
> Generate constructors for generated Go types. Call libxl__init so
> the Go type
Generate constructors for generated Go types. Call libxl__init so
the Go type can be properly initialized.
If a type has a keyed union field, add a parameter to the function
signature to set the key variable, and call the init function for the
keyed union.
Signed-off-by: Nick Rosbrook
---
tools
> 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 was able to make the
HVM driver domain work. However, the PV drive
Hi Anthony,
On 19/12/2019 17:11, Anthony PERARD wrote:
On Mon, Dec 16, 2019 at 02:34:51PM +, Paul Durrant wrote:
It is not safe to close an event channel from the QEMU main thread when
that channel's poller is running in IOThread context.
This patch adds a new xen_device_set_event_channel_
Hi,
I have noticed Wei began to use the tag today. It reminded me that I
never followed-up on the patch, sorry for that.
On 08/11/2019 19:09, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: george.dun...@citrix.com
CC: jul...@xen.org
CC: lars.ku...@citri
Hi all,
+1.
Cheers,
On 27/01/2020 14:12, George Dunlap wrote:
I have drafted an explicit policy on what is (generally) required to
check a patch in. It's been through several rounds, and v4 has been
acked [1].
I've had informal assent from all committers, but just to dot all our
i's and cros
Hi Jeff,
On 21/01/2020 14:39, Jeff Kubascik wrote:
The VGICv3 module does not implement security extensions for guests.
Furthermore, per the ARM Generic Interrupt Controller Architecture
Specification (ARM IHI 0069E), section 9.9.15, the GICD_IGRPMODR
register should be RAZ/WI to non-secure acce
On Wed, Jan 29, 2020 at 02:47:02PM +, Paul Durrant wrote:
> +**node data**
> +
> +
> +`|||`
> +
> +
> +`` is considered relative to the domain path `/local/domain/$domid`
> +and hence must not begin with `/`.
How backend settings are going to be serialized? For example vif backend
has a bun
flight 146579 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146579/
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
flight 146575 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146575/
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
flight 146574 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146574/
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-
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 page.
Use the top-most addressable page for that purpose. Adjust
And add myself as a maintainer.
Sort the list alphabetically while at it.
Signed-off-by: Wei Liu
Signed-off-by: Wei Liu
---
MAINTAINERS | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1915e09f8b..04d91482cd 100644
--- a/MAINTAINERS
+++ b/
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 hypercalls, so skip setting up an output page.
We will also need to provide
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 with %c again.
mm.c:5736:5: error: invalid 'asm': operand is not a condit
This will be useful when invoking hypercall that targets specific
vcpu(s).
Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
---
v5:
1. Add Jan's Ack.
v4:
1. Use private.h
2. Add Paul's review tag
v2:
1. Fold into setup_pcpu_arg function
---
xen/arch/x86/guest/hyperv/hyp
We want to be able to handle AP setup error in the upper layer.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hypervisor.c| 6 --
xen/arch/x86/guest/xen/xen.c | 11 +--
xen/include/asm-x86/guest/hypervisor.h | 6 +++---
3 files changed, 16 insertions(+), 7 deletio
This patch sereis implements several important functionalities to run
Xen on top of Hyper-V.
See individual patches for more details. First few patches are generic
x86 changes. The rest is Hyper-V specific.
I've checked the assembly code as well as putting in a test patch to
make sure the hyperca
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
---
xen/arch/x86/e820.c | 14 --
xen/arch/x86/setup.c | 5 +++--
2 fi
This allows us to set aside some address space for executable mapping.
This fixed map range starts from XEN_VIRT_END so that it is within reach
of the .text section.
Shift the percpu stub range and shrink livepatch range accordingly.
Signed-off-by: Wei Liu
---
v5:
1. drop __virt_to_fix_x
2. also
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 declarations' location
v4:
1. Use private.h
2. Prevent leak
v3:
1. Use xen
Test if the infrastructure works.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/hyperv.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
b/xen/arch/x86/guest/hyperv/hyperv.c
index 932a648ff7..4387b6541e 100644
--- a/xen/arch/x86/gues
Push hypervisor_ap_setup down to smp_callin.
Take the chance to replace xen_guest with cpu_has_hypervisor.
Signed-off-by: Wei Liu
---
xen/arch/x86/smpboot.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index c9d1a
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
---
xen/arch/x86/guest/hypervisor.c| 8
xen/include/asm-x86/guest/hypervisor.h
On 29/01/2020 14:47, Paul Durrant 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 @@
> +# Non-Coope
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
and,
xl dmesg
(XEN) 92118000 - 9213c000
flight 146577 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146577/
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 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 @@
> > +/**
> > + * asm-x86/guest/hyp
On Thu, Jan 23, 2020 at 11:13:10AM +0100, Jan Beulich wrote:
> On 22.01.2020 22:57, Andrew Cooper wrote:
> > On 22/01/2020 20:23, Wei Liu wrote:
> >> These functions will be used later to make hypercalls to Hyper-V.
> >>
> >> Signed-off-by: Wei Liu
> >
> > After some experimentation,
> >
> > dif
flight 146576 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146576/
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 29/01/2020 12:36, Paul Durrant wrote:
> = Projects =
>
> == Hypervisor ==
>
> === x86 ===
>
> * Intel Processor Trace virtualization enabling (v1)
> - Luwei Kang
Hasn't seen any activity in several releases. Probably safe to drop.
Also at least somewhat entangled with CPUID/MSR support.
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 change, but leave everything else in place.
>
> Signed-of
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
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
Drop "mm: modify domain_adjust_tot_pages() to better handle a zero
adjustment".
Paul Durrant (3):
x86 / vmx: move teardown from domain_destroy()...
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
xe
... 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
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
latter which matters here.
Undo that part of the change, but leave everything else in place.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/
flight 146573 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146573/
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 29/01/2020 12:59, Jan Beulich wrote:
> Domain creation failure paths don't call domain_relinquish_resources(),
> yet allocations and alike done from hvm_domain_initialize() need to be
> undone nevertheless. Call the function also from hvm_domain_destroy(),
> after making sure all descendants are
On Wed, Jan 29, 2020 at 03:59:32PM +0100, Jan Beulich wrote:
[...]
> >> I seem to recall recommending to export absolute symbols from
> >> assembly code. The question is how easily usable they would
> >> be from C, or how clumsy the resulting code would look.
> >
> > Even if I use absolute symbol
On 01/29/20 13:12, Anthony PERARD wrote:
> Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
> value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.
>
> Currently, nothing appear to use the value in PcdFSBClock before
> XenPlatformPei had a chance to set it even
On 01/29/20 13:12, 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 frequency by an other me
On Wed, Jan 29, 2020 at 9:09 AM Tamas K Lengyel
wrote:
>
> On Wed, Jan 29, 2020 at 7:56 AM Tamas K Lengyel
> wrote:
> >
> > On Wed, Jan 29, 2020 at 7:44 AM Jan Beulich wrote:
> > >
> > > On 29.01.2020 15:05, Tamas K Lengyel wrote:
> > > > On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich wrote:
> > >
On 01/29/20 13:12, Anthony PERARD wrote:
> We are going to use new fields from the Xen headers. Apply the EDK2
> coding style so that the code that is going to use it doesn't look out
> of place.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
> Signed-off-by: Anthony PERARD
> ---
>
On 01/29/20 13:12, Anthony PERARD wrote:
> We are going to want to change the value of PcdFSBClock at run time in
> OvmfXen, so move it to the PcdsDynamic section.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
> Signed-off-by: Anthony PERARD
> ---
> CC: Bob Feng
> CC: Liming Gao
On Wed, Jan 29, 2020 at 7:56 AM Tamas K Lengyel
wrote:
>
> On Wed, Jan 29, 2020 at 7:44 AM Jan Beulich wrote:
> >
> > On 29.01.2020 15:05, Tamas K Lengyel wrote:
> > > On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich wrote:
> > >>
> > >> On 28.01.2020 18:02, Tamas K Lengyel wrote:
> > >>> On Tue, Jan
On 01/29/20 13:12, Anthony PERARD wrote:
> To avoid nasm generating a warning, replace the macro by the value
> expected to be stored in eax.
> Ia32/XenPVHMain.asm:76: warning: dword data exceeds bounds
>
> Reported-by: Laszlo Ersek
> Signed-off-by: Anthony PERARD
> ---
> OvmfPkg/XenResetVect
Hi Oleksandr,
Oleksandr Tyshchenko writes:
[...]
> @@ -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,
> -
On 29/01/2020 00:36, Daniel Smith wrote:
> ### Discussion
>
> Requested: an in-Xen-tree reference domB implementation
>
> Note: the hypervisor interface supports starting a domain with a
> specified domid. This is not made available by the libxl toolstack.
>
> Xen has logic on permission delegation
flight 146572 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146572/
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 29.01.2020 16:28, Jan Beulich wrote:
> On 17.01.2020 11:53, Anthony PERARD wrote:
>> It isn't necessary to include Config.mk here because this Makefile is
>> only used by xen/Rules.mk which already includes Config.mk.
>
> And so is xen/test/livepatch/Makefile afaics from its parent dir
> Makefi
On 17.01.2020 11:53, Anthony PERARD wrote:
> It isn't necessary to include Config.mk here because this Makefile is
> only used by xen/Rules.mk which already includes Config.mk.
And so is xen/test/livepatch/Makefile afaics from its parent dir
Makefile. With this also adjusted (or it explained why I
> -Original Message-
> From: Jan Beulich
> Sent: 29 January 2020 15:15
> 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 Mo
On 29.01.2020 15:38, Paul Durrant wrote:
> @@ -2371,6 +2383,8 @@ void free_domheap_pages(struct page_info *pg, unsigned
> int order)
>
> if ( likely(d) && likely(d != dom_cow) )
> {
> +long pages = 0;
> +
> /* NB. May recursively lock from relinquish_me
> -Original Message-
> From: Jan Beulich
> Sent: 29 January 2020 15:08
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ;
> Ian Jackson ; Julien Grall ;
> Konrad Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu
> Subject: Re: [PATCH v6 2/4] mm: mod
On 29.01.2020 15:38, Paul Durrant wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -727,8 +727,7 @@ static long
> memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
> (j * (1UL << exch.out.extent_order)));
>
> spin
On 29.01.2020 15:42, Wei Liu wrote:
> On Tue, Jan 28, 2020 at 04:38:42PM +0100, Jan Beulich wrote:
>> On 28.01.2020 16:15, Wei Liu wrote:
>>> On Thu, Jan 23, 2020 at 12:04:00PM +0100, Jan Beulich wrote:
On 22.01.2020 21:23, Wei Liu wrote:
> This allows us to set aside some address space fo
On Wed, Jan 29, 2020 at 7:44 AM Jan Beulich wrote:
>
> On 29.01.2020 15:05, Tamas K Lengyel wrote:
> > On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich wrote:
> >>
> >> On 28.01.2020 18:02, Tamas K Lengyel wrote:
> >>> On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich wrote:
>
> On 27.01.2020 19:
From: Oleksandr Tyshchenko
For the IPMMU-VMSA 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 bank to use for the page walk).
As each Xen dom
Paul Durrant (2):
docs/designs: Add a design document for non-cooperative live migration
docs/designs: Add a design document for migration of xenstore data
docs/designs/non-cooperative-migration.md | 272 ++
docs/designs/xenstore-migration.md| 121 ++
2 fil
It has become apparent to some large cloud providers that the current
model of cooperative migration of guests under Xen is not usable as it
relies on software running inside the guest, which is likely beyond the
provider's control.
This patch introduces a proposal for non-cooperative live migratio
On 1/28/20 8:41 PM, Nick Rosbrook wrote:
>> I think marshaling and unmarshalling should be fine, *as long as* the
>> structure being unmarshalled actually went through the
>> libxl__init() function first.
>>
>> In fact, I was kicking around the idea of adding a non-exported field to
>> all the gene
This patch details proposes extra migration data and xenstore protocol
extensions to support non-cooperative live migration of guests.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano S
Hello,
Current nested VMX code advertises support for the MSR bitmap feature,
yet the implementation isn't done. Previous to this series Xen just maps
the nested guest MSR bitmap (as set by L1) and that's it, the L2 guest
ends up using the L1 MSR bitmap.
This series adds handling of the L2 MSR bi
Current implementation of nested VMX has a half baked handling of MSR
bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but
doesn't actually load it into the nested vmcs, and thus the nested
guest vmcs ends up using the same MSR bitmap as the L1 VMM.
This is wrong as there's no assur
Nested VMX doesn't expose support for
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE,
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or
SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should
always be trapped in the nested guest MSR bitmap, or else a nested
guest could access the hardware x2APIC MSRs giv
On 29.01.2020 15:05, Tamas K Lengyel wrote:
> On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich wrote:
>>
>> On 28.01.2020 18:02, Tamas K Lengyel wrote:
>>> On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich wrote:
On 27.01.2020 19:06, Tamas K Lengyel wrote:
> When plugging a hole in the target
On Tue, Jan 28, 2020 at 04:38:42PM +0100, Jan Beulich wrote:
> On 28.01.2020 16:15, Wei Liu wrote:
> > On Thu, Jan 23, 2020 at 12:04:00PM +0100, Jan Beulich wrote:
> >> On 22.01.2020 21:23, Wei Liu wrote:
> >>> This allows us to set aside some address space for executable mapping.
> >>> This fixed
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
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()...
mm: modify domain_adjust_tot_pages() to better handle a zero
adjustment
mm: make MEMF_no_refcount pages safe to assign
x86 / vmx: use a MEMF_no_refcount domheap page for
APIC_DEFAULT_PHYS_BASE
xen/arch/x86/hvm/vmx
Currently the function will pointlessly acquire and release the global
'heap_lock' in this case.
NOTE: No caller yet calls domain_adjust_tot_pages() with a zero 'pages'
argument, but a subsequent patch will make this possible.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George D
... 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
On 17.01.2020 11:53, Anthony PERARD wrote:
> From: Anthony PERARD
>
> Most of the code executed by Rules.mk isn't necessary for the clean
> target, especially not the CFLAGS. This make running make clean much
> faster.
>
> This extract the code into a different Makefile. It doesn't want to
> inc
On Wed, Jan 29, 2020 at 7:05 AM Tamas K Lengyel
wrote:
>
> On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich wrote:
> >
> > On 28.01.2020 18:02, Tamas K Lengyel wrote:
> > > On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich wrote:
> > >>
> > >> On 27.01.2020 19:06, Tamas K Lengyel wrote:
> > >>> When pluggi
flight 146571 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146571/
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 17.01.2020 11:53, Anthony PERARD wrote:
> From: Anthony PERARD
>
> Collect all the clean targets as we are going to modify it shortly.
> Also, this is inspired by Linux's Kbuild.
>
> "Kbuild.include" isn't included by "Makefile", but the "_clean" target
> is only used by Rules.mk which includ
On 17.01.2020 11:53, Anthony PERARD wrote:
> This is part of upgrading our build system and import more of Linux's
> one.
>
> In Linux, subdir-y in Makefiles is only used to descend into
> subdirectory when there are no object to build, Xen doesn't have that
> and all subdir have object to be incl
> I *think* to guarantee that libxl__init() has been called when
> unmarshaling, we would need to generate UnmarshalJSON functions to
> implement json.Unmarshaler. E.g.,:
>
> func (dd *DeviceDisk) UnmarshalJSON(data []byte) error {
> if dd == nil { // Or maybe this is the 'initialized' chec
> === x86 ===
VM forking series is at v6
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Wed, Jan 29, 2020 at 6:27 AM Jan Beulich wrote:
>
> On 28.01.2020 18:02, Tamas K Lengyel wrote:
> > On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich wrote:
> >>
> >> On 27.01.2020 19:06, Tamas K Lengyel wrote:
> >>> When plugging a hole in the target physmap don't use the access permission
> >>> re
On 29.01.2020 14:53, Tamas K Lengyel wrote:
> On Wed, Jan 29, 2020 at 6:10 AM Jan Beulich wrote:
>>
>> On 27.01.2020 19:06, Tamas K Lengyel wrote:
>>> Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
>>> when the mem_access permission is being set on a page that has not
On Wed, Jan 29, 2020 at 6:10 AM Jan Beulich wrote:
>
> On 27.01.2020 19:06, Tamas K Lengyel wrote:
> > Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
> > when the mem_access permission is being set on a page that has not yet been
> > copied over from the parent.
>
> Yo
> Right, but the bad news is that there are no helpful hypervisor
> messages at all. Sadly this is partly my fault, because I should
> have asked you to do this log collection with a debug hypervisor.
> Most of the possibly interesting messages would appear only there.
> In any event, problems sta
flight 146567 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146567/
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-
On 29.01.2020 14:08, Andrew Cooper wrote:
> On 29/01/2020 08:17, Jan Beulich wrote:
>> On 28.01.2020 18:14, Andrew Cooper wrote:
>>> On 28/01/2020 13:59, Jan Beulich wrote:
On 27.01.2020 21:21, Andrew Cooper wrote:
> Without this fix, there is apparently a problem with Roger's "[PATCH v3
On 28.01.2020 18:02, Tamas K Lengyel wrote:
> On Tue, Jan 28, 2020 at 9:56 AM Jan Beulich wrote:
>>
>> On 27.01.2020 19:06, Tamas K Lengyel wrote:
>>> When plugging a hole in the target physmap don't use the access permission
>>> returned by __get_gfn_type_access as it can be non-sensical, leading
flight 146570 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146570/
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 27.01.2020 19:06, Tamas K Lengyel wrote:
> Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
> when the mem_access permission is being set on a page that has not yet been
> copied over from the parent.
You talking of page-forking here, don't you mean ...
> --- a/xen/a
On 29/01/2020 08:17, Jan Beulich wrote:
> On 28.01.2020 18:14, Andrew Cooper wrote:
>> On 28/01/2020 13:59, Jan Beulich wrote:
>>> On 27.01.2020 21:21, Andrew Cooper wrote:
Without this fix, there is apparently a problem with Roger's "[PATCH v3
7/7]
x86/tlb: use Xen L0 assisted TLB
> -Original Message-
> From: David Woodhouse
> Sent: 29 January 2020 13:05
> To: xen-devel@lists.xenproject.org; Durrant, Paul
> Cc: Woodhouse, David ; luwei.k...@intel.com;
> marma...@invisiblethingslab.com; andrew.coop...@citrix.com;
> roger@citrix.com
> Subject: Re: [ANNOUNCE] Xen
On Wed, 2020-01-29 at 12:36 +, Paul Durrant wrote:
> This email only tracks big items for xen.git tree. Please reply for items
> you would like to see in 4.14 so that people have an idea what
> is going on and prioritise accordingly.
>
> You're welcome to provide description and use cases of t
> -Original Message-
> From: Jan Beulich
> Sent: 29 January 2020 12:48
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [ANNOUNCE] Xen 4.14 Development Update
>
> On 29.01.2020 13:36, Paul Durrant wrote:
> > === x86 ===
> >
> > * Intel Processor Trace virtualizati
On 1/29/20 2:05 PM, Thomas Zimmermann wrote:
> The atomic helpers automatically send out fake VBLANK events if no
> vblanking has been initialized. This would apply to xen, but xen has
> its own vblank logic. To avoid interfering with the atomic helpers,
> disable automatic vblank events explicitly
1 - 100 of 164 matches
Mail list logo
