At 18:31 + on 03 Feb (1580754711), Julien Grall wrote:
> On 03/02/2020 17:37, George Dunlap wrote:
> > On 2/3/20 5:22 PM, Julien Grall wrote:
> >> On 03/02/2020 17:10, George Dunlap wrote:
> >>> On 2/3/20 4:58 PM, Julien Grall wrote:
> From: Julien Grall
>
> It is not entirely
flight 146751 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146751/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 146563
Tests which did not
flight 146752 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146746 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146746/
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
flight 146745 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146745/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
flight 146749 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146749/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146750 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146750/
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
flight 146740 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146740/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs.
On Mon, Jan 27, 2020 at 07:11:11PM +0100, Roger Pau Monne wrote:
[...]
>
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index 26798b317c..dfe264cf83 100644
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -4157,7 +4157,6 @@
On Wed, Feb 05, 2020 at 04:50:53PM +, Andrew Cooper wrote:
> These are believed-unused, and the underlying infrastructure is about to be
> rewritten completely.
>
> Signed-off-by: Andrew Cooper
Acked-by: Marek Marczykowski-Górecki
--
Best Regards,
Marek Marczykowski-Górecki
Invisible
flight 146748 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146748/
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
There is no need for every CPU to set a guest property.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/xen/xen.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 1f868f2f8d..3cf8f667a1
Hi Jan,
On 05/02/2020 16:47, Jan Beulich wrote:
On 05.02.2020 17:25, Xia, Hongyan wrote:
Ping.
Sorry, there's just too much else also needing attention. I'm
doing what I can review-wise, and I assume some others do so,
too. You're very welcome to help with the review load.
Wei and I
flight 146747 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146747/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
Hi Jan,
On 05/02/2020 16:38, Jan Beulich wrote:
On 05.02.2020 15:34, Julien Grall wrote:
On 05/02/2020 13:16, Jan Beulich wrote:
This is more robust than the raw xmalloc_bytes().
Also add a sanity check on the input page range.
It feels to me that the commit message/title should focus on
While we are in the process of overhauling boot time CPUID/MSR handling, the
existing logic is going to have to remain in roughly this form for backwards
compatibility.
Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single
libxl__cpuid_legacy() to reduce the complexity
HVM_PARAM_PAE_ENABLED is undocumented and Xen has never acted upon its value,
contrary perhaps to expectations based on how other boolean fields work.
It was only ever used as a non-standard calling convention for
xc_cpuid_apply_policy() but that has been fixed now.
Purge its use, and any
These functions should never have been exposed. They don't have external
users, and can't usefully be used for several reasons.
Move libxl_cpuid_{set,apply_policy}() to being internal functions, and leave
an equivalent of the nop stubs in the API for caller compatibility.
Signed-off-by: Andrew
These have no callers, and the underlying infrastructure is about to be
rewritten completely.
Signed-off-by: Andrew Cooper
---
CC: Christian Lindig
---
tools/ocaml/libs/xc/xenctrl.ml | 7 -
tools/ocaml/libs/xc/xenctrl.mli | 7 -
tools/ocaml/libs/xc/xenctrl_stubs.c | 62
This series attempts to remove some of the more insane behaviours from early
CPUID handling. This is a little RFC to get a feel, but I intend to extend
the same kind of handling to ITSC (and get rid of nomigrate), and provide some
slightly nested-virt behaviour until it can become a domaincreate
These are believed-unused, and the underlying infrastructure is about to be
rewritten completely.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/python/xen/lowlevel/xc/xc.c | 98 ---
1 file changed, 98
The sole use of HVM_PARAM_PAE_ENABLED is as a non-standard calling convention
for xc_cpuid_apply_policy(). Pass PAE as a regular parameter instead.
Leave a rather better explaination of why only HVM guests have a choice in PAE
setting.
No functional change.
Signed-off-by: Andrew Cooper
---
On 05.02.2020 17:25, Xia, Hongyan wrote:
> Ping.
Sorry, there's just too much else also needing attention. I'm
doing what I can review-wise, and I assume some others do so,
too. You're very welcome to help with the review load.
Jan
> On Tue, 2020-01-28 at 13:50 +, Hongyan Xia wrote:
>>
On 05.02.2020 17:14, Roger Pau Monné wrote:
> Ping?
>
> Just want to make sure this doesn't go under the radar.
It's safely sitting in my to-be-looked-at folder, but there's
way too much else to look after to get to it, yet.
Jan
___
Xen-devel mailing
On 05.02.2020 15:34, Julien Grall wrote:
> On 05/02/2020 13:16, Jan Beulich wrote:
>> This is more robust than the raw xmalloc_bytes().
>>
>> Also add a sanity check on the input page range.
>
> It feels to me that the commit message/title should focus on the sanity
> check. The xmalloc_array()
On 05.02.20 17:03, Sergey Dyasli wrote:
Hello,
I'm currently investigating a Live-Patch application failure in core-
scheduling mode and this is an example of what I usually get:
(it's easily reproducible)
(XEN) [ 342.528305] livepatch: lp: CPU8 - IPIing the other 15 CPUs
(XEN) [
Ping.
On Tue, 2020-01-28 at 13:50 +, Hongyan Xia wrote:
> From: Wei Liu
>
> We are going to switch to using domheap page for page tables.
> A new set of APIs is introduced to allocate and free pages of page
> tables based on mfn instead of the xenheap direct map address. The
> allocation
Ping?
Just want to make sure this doesn't go under the radar.
Thanks, Roger.
On Mon, Jan 27, 2020 at 07:11:08PM +0100, Roger Pau Monne wrote:
> Hello,
>
> The following series aims to improve the TLB flush times when running
> nested Xen, and it's specially beneficial when running in shim
Hello,
I'm currently investigating a Live-Patch application failure in core-
scheduling mode and this is an example of what I usually get:
(it's easily reproducible)
(XEN) [ 342.528305] livepatch: lp: CPU8 - IPIing the other 15 CPUs
(XEN) [ 342.558340] livepatch: lp: Timed out on
flight 146744 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146744/
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
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 04 February 2020 15:37
> To: Xen Development List
> Cc: Durrant, Paul ; Michael Kelley
> ; Wei Liu ; Wei Liu
> ; Jan Beulich ; Andrew Cooper
> ; Roger Pau Monné
> Subject: [PATCH v7 05/10] x86/hyperv: setup hypercall page
Hi Thomas
On 11/25/19 11:27, Qais Yousef wrote:
> Changes in v2:
> * Add 2 new patches that create smp_shutdown_nonboot_cpus() to be used
> in machine_shutdown() in ia64, arm and arm64
> * Use proper kernel-doc for the newly introduced functions
> * Renamed a function
>
On Wed, Feb 05, 2020 at 02:17:02PM +0100, Jan Beulich wrote:
> Checking the result of a multiplication against a certain limit has no
> sufficient implication on the original value's range. In the case here
> it is in particular problematic that while handling the domctl we do
>
> if (
On Wed, Feb 05, 2020 at 03:00:24PM +, Wei Liu wrote:
> On Wed, Feb 05, 2020 at 03:04:16PM +0100, Roger Pau Monné wrote:
> [...]
> > > +static void __init setup_hypercall_page(void)
> > > +{
> > > +union hv_x64_msr_hypercall_contents hypercall_msr;
> > > +union hv_guest_os_id guest_id;
On Wed, Feb 05, 2020 at 03:04:16PM +0100, Roger Pau Monné wrote:
[...]
> > +static void __init setup_hypercall_page(void)
> > +{
> > +union hv_x64_msr_hypercall_contents hypercall_msr;
> > +union hv_guest_os_id guest_id;
> > +unsigned long mfn;
> > +
> > +
Hi Jan,
On 05/02/2020 13:16, Jan Beulich wrote:
This is more robust than the raw xmalloc_bytes().
Also add a sanity check on the input page range.
It feels to me that the commit message/title should focus on the sanity
check. The xmalloc_array() is just a cleanup is "less important".
Hi Jan,
On 05/02/2020 13:16, Jan Beulich wrote:
... when plain xzalloc() (which is more type safe) does.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -969,7 +969,7 @@ static void gicv2_add_v2m_frame_to_list(
Hi Jan,
On 05/02/2020 13:36, Jan Beulich wrote:
On 05.02.2020 12:24, Julien Grall wrote:
Hi Jan,
On 04/02/2020 15:13, Jan Beulich wrote:
On 04.02.2020 14:51, Julien Grall wrote:
On 04/02/2020 13:40, Jan Beulich wrote:
On 04.02.2020 14:33, Julien Grall wrote:
At the moment,
> On 05.02.2020 12:23, David Woodhouse wrote:
>> On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
>>> Yet, as you say elsewhere, whether an MFN has an
>>> entry in frame_table[] is entirely unclear, so permitting boot-
>>> allocator pages to be freed via alloc_domheap_pages() nevertheless
On Wed, Feb 5, 2020 at 4:40 AM Jan Beulich wrote:
>
> On 03.02.2020 17:12, Tamas K Lengyel wrote:
> > @@ -4414,6 +4424,40 @@ static int hvm_allow_get_param(struct domain *d,
> > return rc;
> > }
> >
> > +static int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value)
> > +{
> >
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.6-rc1-tag
xen: branch for v5.6-rc1
It contains:
- a fix of a bug introduced in 5.5 for the Xen gntdev driver
- a fix of the Xen balloon driver when running on ancient Xen versions
On Tue, Feb 04, 2020 at 03:36:59PM +, 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
Am Mittwoch, 5. Februar 2020, 10:31:37 CET schrieb Jürgen Groß:
> On 05.02.20 10:03, Dietmar Hahn wrote:
> > Am Dienstag, 4. Februar 2020, 15:18:53 CET schrieb Jürgen Groß:
> >> On 04.02.20 15:07, Dietmar Hahn wrote:
> >>> Am Freitag, 31. Januar 2020, 22:59:19 CET schrieb Igor Druzhinin:
> On
flight 146742 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146742/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On 05.02.2020 12:23, David Woodhouse wrote:
> On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
>> Yet, as you say elsewhere, whether an MFN has an
>> entry in frame_table[] is entirely unclear, so permitting boot-
>> allocator pages to be freed via alloc_domheap_pages() nevertheless
>> still
On 05.02.2020 12:24, Julien Grall wrote:
> Hi Jan,
>
> On 04/02/2020 15:13, Jan Beulich wrote:
>> On 04.02.2020 14:51, Julien Grall wrote:
>>>
>>>
>>> On 04/02/2020 13:40, Jan Beulich wrote:
On 04.02.2020 14:33, Julien Grall wrote:
> At the moment, assign_pages() relies on PG_state_inuse
On 05.02.2020 14:21, Roger Pau Monné wrote:
> On Wed, Feb 05, 2020 at 09:46:25AM +0100, Jan Beulich wrote:
>> On 04.02.2020 18:34, Roger Pau Monne wrote:
>>> Import the functions and it's dependencies. Based on Linux 5.5, commit
>>> id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
>>>
>>>
On Wed, Feb 05, 2020 at 09:46:25AM +0100, Jan Beulich wrote:
> On 04.02.2020 18:34, Roger Pau Monne wrote:
> > Import the functions and it's dependencies. Based on Linux 5.5, commit
> > id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
> >
> > Signed-off-by: Roger Pau Monné
>
> Thanks for going this
On 05.02.2020 14:11, Jan Beulich wrote:
> Ilja has reported a couple of issues which were on the boundary of
> needing an XSA, due to some vagueness of the statements resulting
> from XSA-77. The first 3 patches here address these reports, after
> having settled within the Security Team that we
Checking the result of a multiplication against a certain limit has no
sufficient implication on the original value's range. In the case here
it is in particular problematic that while handling the domctl we do
if ( copy_from_guest(info->vdistance, uinfo->vdistance,
... when plain xzalloc() (which is more type safe) does.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -969,7 +969,7 @@ static void gicv2_add_v2m_frame_to_list(
nr_spis, V2M_MAX_SPI - V2M_MIN_SPI + 1);
/* Allocate an entry to record
This is more robust than the raw xmalloc_bytes().
Also add a sanity check on the input page range.
Signed-off-by: Jan Beulich
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -187,13 +187,17 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xe
uint32_t *status, *ptr;
mfn_t mfn;
There are hypercall handling paths (EFI ones are what this was found
with) needing to allocate buffers of a caller specified size. This is
generally fine, as our page allocator enforces an upper bound on all
allocations. However, certain extremely large sizes could, when adding
in allocator
A malicious guest given permission to invoke XENPF_efi_runtime_call may
play with the strings underneath Xen sizing them and copying them in.
Guard against this by re-checking the copyied in data for consistency
with the initial sizing. At the same time also check that the actual
copy-in is in
Commit 1f4eb9d27d0e ("EFI: fix getting EFI variable list on some
systems") switched to using the caller provided size for the copy-out
without making sure the copied buffer is properly scrubbed.
Reported-by: Ilja Van Sprundel
Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
---
Ilja has reported a couple of issues which were on the boundary of
needing an XSA, due to some vagueness of the statements resulting
from XSA-77. The first 3 patches here address these reports, after
having settled within the Security Team that we can't find anyone /
anything actually being
On Tue, Feb 04, 2020 at 04:02:38PM +, Xia, Hongyan wrote:
[...]
> > Keep in mind that accessing the union {pv, hvm} before knowing the
> > exact variant is dangerous.
> >
> > Because mapcache is initialised for PV only, so it should be freed
> > for
> > PV only. I think you need to put it to
On 05.02.2020 13:09, Wei Liu wrote:
> On Wed, Feb 05, 2020 at 12:12:30PM +0100, Jan Beulich wrote:
>> On 04.02.2020 16:36, Wei Liu wrote:
>>> @@ -254,14 +260,20 @@ static void __init setup(void)
>>> XEN_LEGACY_MAX_VCPUS);
>>> }
>>>
>>> -init_evtchn();
>>> +
flight 146735 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146735/
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
On Wed, Feb 05, 2020 at 12:12:30PM +0100, Jan Beulich wrote:
> On 04.02.2020 16:36, Wei Liu wrote:
> > @@ -215,18 +220,19 @@ static void init_evtchn(void)
> > rc = xen_hypercall_set_evtchn_upcall_vector(this_cpu(vcpu_id),
> >
flight 146733 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
On Wed, Feb 05, 2020 at 11:11:37AM +0100, Juergen Gross wrote:
> Add the new library libxenhypfs for access to the hypervisor filesystem.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Tue, Feb 04, 2020 at 08:29:38PM +, Andrew Cooper wrote:
> It turns out that a bug (since forever) in Xen causes XSAVE records to have
> non-architectural behaviour on xsave-capable hardware, when a PV guest has not
> touched the state.
>
> In such a case, the data record returned from Xen
flight 146737 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146737/
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 Wed, Feb 05, 2020 at 09:12:50AM +0100, Jan Beulich wrote:
> On 04.02.2020 18:19, Wei Liu wrote:
> > On Tue, Feb 04, 2020 at 06:07:00PM +0100, Jan Beulich wrote:
> >> On 04.02.2020 17:55, Wei Liu wrote:
> >>> Signed-off-by: Wei Liu
> >>> ---
> >>> xen/arch/x86/e820.c | 2 +-
> >>> 1 file
On Wed, Feb 05, 2020 at 11:29:30AM +, Anthony PERARD wrote:
> On Wed, Feb 05, 2020 at 11:24:12AM +, Paul Durrant wrote:
> > NOTE: The comment for XEN_DOMCTL_createdomain in domctl.h is changed to
> > reflect reality.
>
> Surely, this change deserve to be in its own patch, isn't it?
On 03.02.2020 17:12, Tamas K Lengyel wrote:
> @@ -4414,6 +4424,40 @@ static int hvm_allow_get_param(struct domain *d,
> return rc;
> }
>
> +static int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value)
> +{
> +int rc;
> +
> +rc = hvm_allow_get_param(d, index);
> +
On Wed, 2020-02-05 at 10:22 +, Julien Grall wrote:
> However, I don't like the idea of relying on count_info == 0. Indeed,
> there are valid case where count_info == 0 because it means the page is
> inuse (PCC_state_inuse).
>
> It might be best if we introduce a new page state that would be
On Wed, Feb 05, 2020 at 11:24:12AM +, Paul Durrant wrote:
> NOTE: The comment for XEN_DOMCTL_createdomain in domctl.h is changed to
> reflect reality.
Surely, this change deserve to be in its own patch, isn't it?
--
Anthony PERARD
___
On 05.02.2020 12:24, Paul Durrant wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -42,7 +42,8 @@
>
> /*
> * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> - * If it is specified as zero, an id is auto-allocated and returned.
> + * If it
On Wed, Feb 05, 2020 at 11:24:12AM +, Paul Durrant wrote:
> An assertion in libxl__domain_make():
>
> 'soft_reset || *domid == INVALID_DOMID'
>
> does not hold true for stub domain creation, where soft_reset is false
> but the passed in domid == 0. This is easily fixed by changing the
>
On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
> Yet, as you say elsewhere, whether an MFN has an
> entry in frame_table[] is entirely unclear, so permitting boot-
> allocator pages to be freed via alloc_domheap_pages() nevertheless
> still doesn't look any better an idea to me.
Hm, I
An assertion in libxl__domain_make():
'soft_reset || *domid == INVALID_DOMID'
does not hold true for stub domain creation, where soft_reset is false
but the passed in domid == 0. This is easily fixed by changing the
initializer in libxl__spawn_stub_dm().
NOTE: The comment for
On Wed, Feb 05, 2020 at 10:50:46AM +, Durrant, Paul wrote:
> > From: Anthony PERARD
> > On Wed, Feb 05, 2020 at 09:37:24AM +, Paul Durrant wrote:
> > >
> > > -sdss->pvqemu.guest_domid = 0;
> > > +sdss->pvqemu.guest_domid = INVALID_DOMID;
> >
> > How this works? INVALID_DOMID
Hi Jan,
On 04/02/2020 15:13, Jan Beulich wrote:
On 04.02.2020 14:51, Julien Grall wrote:
On 04/02/2020 13:40, Jan Beulich wrote:
On 04.02.2020 14:33, Julien Grall wrote:
At the moment, assign_pages() relies on PG_state_inuse to be 0. This
makes the code slightly more difficult to
On Wed, Feb 05, 2020 at 12:03:00PM +0100, Sander Eikelenboom wrote:
> Hi Roger,
>
> Sorry, I haven't been able to follow up on testing yet.
> (I have some longer running task for which I need some services on the box,
> so testing and rebooting is needed.)
> Could be tomorrow, but could also be
On 04.02.2020 16:37, Wei Liu wrote:
> These functions will be used later to make hypercalls to Hyper-V.
>
> Signed-off-by: Wei Liu
> Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 04.02.2020 16:36, Wei Liu wrote:
> 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.
>
>
On 04.02.2020 16:36, Wei Liu wrote:
> @@ -215,18 +220,19 @@ static void init_evtchn(void)
> rc = xen_hypercall_set_evtchn_upcall_vector(this_cpu(vcpu_id),
> evtchn_upcall_vector);
> if ( rc )
> -panic("Unable to set evtchn upcall
Hi Roger,
Sorry, I haven't been able to follow up on testing yet.
(I have some longer running task for which I need some services on the box,
so testing and rebooting is needed.)
Could be tomorrow, but could also be this weekend before I will come around to
the testing and reporting back.
--
flight 146738 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146738/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On 23.01.2020 12:36, Jan Beulich wrote:
> With non-empty CONFIG_DOM0_MEM clang5 produces
>
> dom0_build.c:344:24: error: use of logical '&&' with constant operand
> [-Werror,-Wconstant-logical-operand]
> if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
>^
On 05.02.2020 11:11, Juergen Gross wrote:
> Add a new script xen/tools/binfile for including a binary file at build
> time being usable via a pointer and a size variable in the hypervisor.
>
> Make use of that generic tool in xsm.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
> -Original Message-
> From: Anthony PERARD
> Sent: 05 February 2020 10:47
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Ian Jackson
> ; Wei Liu ; Roger Pau Monné
>
> Subject: Re: [PATCH] libxl: fix assertion failure in stub domain creation
>
> On Wed, Feb 05, 2020 at
On 05.02.2020 11:24, David Woodhouse wrote:
> On Wed, 2020-02-05 at 11:02 +0100, Jan Beulich wrote:
>>> +/* Pages from the boot allocator need to pass through
>>> init_heap_pages() */
>>> +if ( unlikely(!pg->count_info) )
>>
>> ... while I think this check may be fine here, no similar one
On Wed, Feb 05, 2020 at 09:37:24AM +, Paul Durrant wrote:
> An assertion in libxl__domain_make():
>
> 'soft_reset || *domid == INVALID_DOMID'
>
> does not hold true for stub domain creation, where soft_reset is false
> but the passed in domid == 0. This is easily fixed by changing the
>
flight 146732 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146732/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs.
On 03.02.2020 15:43, Andrew Cooper wrote:
> --- a/xen/drivers/passthrough/amd/iommu_cmd.c
> +++ b/xen/drivers/passthrough/amd/iommu_cmd.c
> @@ -24,16 +24,14 @@ static int queue_iommu_command(struct amd_iommu *iommu,
> u32 cmd[])
> {
> uint32_t tail, head;
>
> -tail =
On Wed, 2020-02-05 at 10:22 +, Julien Grall wrote:
> Hi,
>
> On 05/02/2020 09:50, David Woodhouse wrote:
> > On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
> > > At very least it's more robust this way; the algorithm is also less
> > > "magic". We just had a long discussion this
Ping?
On Mon, Feb 03, 2020 at 02:21:08PM +0100, Roger Pau Monné wrote:
> On Mon, Feb 03, 2020 at 01:44:06PM +0100, Sander Eikelenboom wrote:
> > On 03/02/2020 13:41, Roger Pau Monné wrote:
> > > On Mon, Feb 03, 2020 at 01:30:55PM +0100, Sander Eikelenboom wrote:
> > >> On 03/02/2020 13:23, Roger
On Wed, 2020-02-05 at 11:02 +0100, Jan Beulich wrote:
> > +/* Pages from the boot allocator need to pass through
> > init_heap_pages() */
> > +if ( unlikely(!pg->count_info) )
>
> ... while I think this check may be fine here, no similar one
> can be used in free_domheap_pages(), yet
Hi,
On 05/02/2020 09:50, David Woodhouse wrote:
On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
At very least it's more robust this way; the algorithm is also less
"magic". We just had a long discussion this morning trying to re-create
the logic for why "Remove MFN 0" was sufficient
On 03.02.2020 15:43, Andrew Cooper wrote:
> The MMIO registers as already byte offsets. By masking out the reserved bits
> suitably in guest_iommu_mmio_write64(), we can use the values directly,
> instead of masking/shifting on every use.
I guess it's unclear whether such masking matches real
flight 146739 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146739/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen f7fb9a0aa9fbb81292e1626ce40340d3f6d8d505
baseline version:
xen
Add a new script xen/tools/binfile for including a binary file at build
time being usable via a pointer and a size variable in the hypervisor.
Make use of that generic tool in xsm.
Signed-off-by: Juergen Gross
---
V3:
- new patch
V4:
- add alignment parameter (Jan Beulich)
- use .Lend instead
Add support to read and modify values of hypervisor runtime parameters
via the hypervisor file system.
As runtime parameters can be modified via a sysctl, too, this path has
to take the hypfs rw_lock as writer.
For custom runtime parameters the resulting parameter value needs to
be stored in a
Add the infrastructure for the hypervisor filesystem.
This includes the hypercall interface and the base functions for
entry creation, deletion and modification.
In order not to have to repeat the same pattern multiple times in case
adding a new node should BUG_ON() failure, the helpers for
On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
In the beginning there should only be basic support: entries can be
added from the hypervisor itself only, there is a simple
Add the xenfs tool for accessing the hypervisor filesystem.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
V1:
- rename to xenhypfs
- don't use "--" for subcommands
- add write support
V2:
- escape non-printable characters per default with cat subcommand
(Ian Jackson)
- add -b option to
On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
This is a first implementation of that idea adding the basic
functionality to hypervisor and tools side. The interface to any
1 - 100 of 121 matches
Mail list logo
