On 28.01.2020 18:25, Roger Pau Monné wrote:
> On Tue, Jan 28, 2020 at 04:49:09PM +0100, Jan Beulich wrote:
>> On 28.01.2020 15:54, Roger Pau Monné wrote:
>>> On Tue, Jan 28, 2020 at 02:16:53PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -844
flight 146565 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146565/
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 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 flush when available" on native AMD
>>> hardware.
>
On 28.01.2020 18:01, Durrant, Paul wrote:
>> From: Jan Beulich
>> Sent: 28 January 2020 15:23
>>
>> On 24.01.2020 16:31, Paul Durrant wrote:
>>> 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 incremen
> -Original Message-
> From: Jan Beulich
> Sent: 29 January 2020 08:22
> 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
As requested I configured one host with:
> loglvl=all guest_loglvl=all
and collected one day of logs via serial interface:
https://drive.google.com/drive/folders/1sQvyNH0Sz28tUeVRZl9mowhB0Htd8ZpO?usp=sharing
searching for "error" or "multicalls.c" leads to some stacktraces that might be
intere
On 29.01.2020 09:29, peter.kur...@gdata.de wrote:
> As requested I configured one host with:
>
>> loglvl=all guest_loglvl=all
>
> and collected one day of logs via serial interface:
>
> https://drive.google.com/drive/folders/1sQvyNH0Sz28tUeVRZl9mowhB0Htd8ZpO?usp=sharing
>
> searching for "error
On 28.01.2020 18:41, PGNet Dev wrote:
> ( posted this already to xen-users, and @ distro list; advised to bring it
> here )
>
> I'm running linux kernel
>
> lsb_release -rd
> Description:openSUSE Leap 15.1
> Release:15.1
>
> uname -rm
>
Hey Julien,
On 12/18/19 2:57 PM, Julien Grall wrote:
Hi Varad,
Please send new version of a patch in a new thread rather than
in-reply to the first version.
On 18/12/2019 10:53, Varad Gautam wrote:
XEN_DOMCTL_destroydomain creates a continuation if domain_kill
-ERESTARTS.
In that scenario,
Hey Jan,
On 12/18/19 2:42 PM, Jan Beulich wrote:
On 18.12.2019 11:53, Varad Gautam wrote:
XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTS.
In that scenario, it is possible to receive multiple _pirq_guest_unbind
calls for the same pirq from domain_kill, if the pirq has
XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTS.
In that scenario, it is possible to receive multiple _pirq_guest_unbind
calls for the same pirq from domain_kill, if the pirq has not yet been
removed from the domain's pirq_tree, as:
domain_kill()
-> domain_relinquish
On Wed, Jan 29, 2020 at 09:01:34AM +0100, Jan Beulich wrote:
> On 28.01.2020 18:25, Roger Pau Monné wrote:
> > On Tue, Jan 28, 2020 at 04:49:09PM +0100, Jan Beulich wrote:
> >> On 28.01.2020 15:54, Roger Pau Monné wrote:
> >>> On Tue, Jan 28, 2020 at 02:16:53PM +0100, Jan Beulich wrote:
> ---
On 29.01.2020 10:38, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 09:01:34AM +0100, Jan Beulich wrote:
>> On 28.01.2020 18:25, Roger Pau Monné wrote:
>>> On Tue, Jan 28, 2020 at 04:49:09PM +0100, Jan Beulich wrote:
On 28.01.2020 15:54, Roger Pau Monné wrote:
> On Tue, Jan 28, 2020 at 0
flight 146566 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146566/
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 146569 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146569/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen f910c3ebc6a178c5cbbc0868134be536fae7f7cf
baseline version:
xen f190
On 29/01/2020 09:27, v...@amazon.com wrote:
Hey Julien,
Hi,
On 12/18/19 2:57 PM, Julien Grall wrote:
Hi Varad,
Please send new version of a patch in a new thread rather than
in-reply to the first version.
On 18/12/2019 10:53, Varad Gautam wrote:
XEN_DOMCTL_destroydomain creates a cont
Hi,
On 29/01/2020 09:28, Varad Gautam wrote:
XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTS.
In that scenario, it is possible to receive multiple _pirq_guest_unbind
calls for the same pirq from domain_kill, if the pirq has not yet been
removed from the domain's pirq_tr
flight 146564 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146564/
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
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
... 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
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
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
Hello,
Thanks for the patch! Next time could you please try to reply to the
previous questions before sending a new version:
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00257.html
On Wed, Jan 29, 2020 at 10:28:07AM +0100, Varad Gautam wrote:
> XEN_DOMCTL_destroydomain creates
Hi,
On 28/01/2020 18:09, Igor Druzhinin wrote:
On 28/01/2020 09:32, Julien Grall wrote:
On 27/01/2020 18:56, Igor Druzhinin wrote:
The existing RCU barrier implementation is prone to a deadlock scenario
due to IRQs being re-enabled inside stopmachine context. If due to a race
IRQs are re-enabl
Hi,
I'm not aware on any prior discussion w.r.t. dates for Xen 4.14 so as RM I'd
like to propose the following:
Last posting: May 1st 2020
Hard Freeze: May 22nd 2020
Release: June 26th
That puts summit between hard freeze and release, but I don't see that as a
problem and may even be benef
On 29.01.2020 11:55, Durrant, Paul wrote:
> I'm not aware on any prior discussion w.r.t. dates for Xen 4.14 so as RM
> I'd like to propose the following:
>
> Last posting: May 1st 2020
> Hard Freeze: May 22nd 2020
> Release: June 26th
Was 4.13 really more than 1.5 months late? The above would
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 appear to understand credit2 and
> > >
On 29.01.2020 11:16, Paul Durrant wrote:
> 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.
With this mem
> -Original Message-
> From: Jan Beulich
> Sent: 29 January 2020 11:08
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] Xen 4.14 dates
>
> On 29.01.2020 11:55, Durrant, Paul wrote:
> > I'm not aware on any prior discussion w.r.t. dates for Xen 4.14 so as
>
> -Original Message-
> From: Jan Beulich
> Sent: 29 January 2020 11:13
> 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 v5 2/4] mm: mod
On 29.01.2020 11:16, Paul Durrant wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2287,11 +2287,14 @@ int assign_pages(
>
> for ( i = 0; i < (1 << order); i++ )
> {
> +unsigned long count_info = pg[i].count_info;
> +
> ASSERT(page_get_owner(
On 29.01.2020 12:13, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 29 January 2020 11:08
>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>> Subject: Re: [Xen-devel] Xen 4.14 dates
>>
>> On 29.01.2020 11:55, Durrant, Paul wrote:
>>> I'm not aware on any pr
On 29.01.20 12:08, Jan Beulich wrote:
On 29.01.2020 11:55, Durrant, Paul wrote:
I'm not aware on any prior discussion w.r.t. dates for Xen 4.14 so as RM I'd
like to propose the following:
Last posting: May 1st 2020
Hard Freeze: May 22nd 2020
Release: June 26th
Was 4.13 really more than 1.
On 29.01.2020 11:30, Roger Pau Monné wrote:
> Hello,
>
> Thanks for the patch! Next time could you please try to reply to the
> previous questions before sending a new version:
>
> https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00257.html
>
> On Wed, Jan 29, 2020 at 10:28:07AM +
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
At the end of a commit, atomic helpers can generate a fake VBLANK event
automatically. Originally implemented for writeback connectors, the
functionality can be used by any driver and/or hardware without proper
VBLANK interrupt.
The patch updates the documentation to make this behaviour official:
As udl does not initialize vblanking, atomic helpers initialize the
value of struct drm_crtc_state.no_vblank to be true. No need to set
it from within the driver.
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/udl/udl_modeset.c | 11
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
As ast does not initialize vblanking, atomic helpers initialize the
value of struct drm_crtc_state.no_vblank to be true. No need to set
it from within the driver.
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_mode.c | 2 --
1 fi
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.
v5:
* update comment
v4:
* separat
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over drivers.
The current implementation looks at state of a device wrt vblanking. If
vblanking has been initial
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
The atomic helpers automatically send out fake VBLANK events if no
vblanking has been initialized. Remove the sending code from the
driver.
v4:
* separate commit from core vblank changes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gp
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
---
MdePkg/MdePkg.dec | 8
1 file changed, 4 in
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
---
OvmfPkg/Include/IndustryStandard/Xen/xen.h | 17
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 though TimerLib is included
in modules runned befor
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/XenResetVector/Ia32/XenPVHMain.asm | 2 +-
1 file changed, 1 insertio
Patch series available in this git branch:
git://xenbits.xen.org/people/aperard/ovmf.git br.apic-timer-freq-v1
Hi,
OvmfXen uses the APIC timer, but with an hard-coded frequency that may change
as pointed out here:
https://edk2.groups.io/g/devel/message/45185
<20190808134423.ybqg3qkpw5ucfzk4@A
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 mean.
Fortunately, Xen provides a way to determines
flight 146563 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146563/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail REGR. vs. 146543
Tests which did not succeed
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 the feature you're
working on.
= Timeline =
We now adopt a fixed
On Wed, Jan 29, 2020 at 12:36:18PM +, Paul Durrant wrote:
> * Linux stub domains (RFC v2)
> - Marek Marczykowski-Górecki
There is v4 series already.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: W
On 29.01.2020 13:36, Paul Durrant wrote:
> === x86 ===
>
> * Intel Processor Trace virtualization enabling (v1)
> - Luwei Kang
>
> * Linux stub domains (RFC v2)
> - Marek Marczykowski-Górecki
>
> * Fixes to #DB injection
> - Andrew Cooper
>
> * CPUID/MSR Xen/toolstack improvements
> -Original Message-
> From: Marek Marczykowski-Górecki
> Sent: 29 January 2020 12:44
> To: xen-devel@lists.xenproject.org; Durrant, Paul
> Cc: Woodhouse, David ; luwei.k...@intel.com;
> andrew.coop...@citrix.com; roger@citrix.com
> Subject: Re: [ANNOUNCE] Xen 4.14 Development Update
On 29.01.20 13: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 the feature you're
workin
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 idempotent.
Note that while viridian_{domain,v
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
> -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 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: 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 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
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
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 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
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
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-
> 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
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
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: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
> === 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
> 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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 164 matches
Mail list logo
