Hi,
On 25/02/2020 09:53, Paul Durrant wrote:
... and save the MFN.
This patch modifies the 'shared_info' field of struct domain to be
a structure comprising an MFN and a virtual address. Allocations are
still done from xenheap, so the virtual address still equates to
virt_to_mfn() called on the
flight 147536 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147536/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx 16 guest-start/debian.repeat fail REGR. vs. 147410
test-armhf-armhf-ex
On 26.02.2020 08:13, Julien Grall wrote:
> On 25/02/2020 12:34, Jan Beulich wrote:
>> Further, even if all current implementations obeyed by the more
>> strict rule, this still wouldn't mean callers are actually permitted
>> to assume such. The more strict rule would then also need to be
>> written
On Thu, 2020-02-20 at 14:39 +0100, Juergen Gross wrote:
> Currently the memory for each run-queue of the credit2 scheduler is
> allocated at the scheduler's init function: for each cpu in the
> system
> a struct csched2_runqueue_data is being allocated, even if the
> current scheduler only handles
Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
be consulted first.
Reported-by: Farrah Chen
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -900,7 +900,6 @@ int vmx_vpmu_initialise(struct vcpu *v)
int __init core2_
On 25.02.2020 18:31, Andrew Cooper wrote:
> Policy objects aren't tiny, and the derivation logic isn't trivial. We are
> about to increase the number of policy objects, so take this opportunity to
> drop logic and storage space based on CONFIG_{PV,HVM}.
It doesn't look as if you were dropping eit
On 24.02.2020 11:06, Alexandru Stefan ISAILA wrote:
>
>
> On 21.02.2020 18:39, Jan Beulich wrote:
>> On 21.02.2020 09:30, Alexandru Stefan ISAILA wrote:
>>> @@ -4835,6 +4836,26 @@ static int do_altp2m_op(
>>>break;
>>>}
>>>
>>> +case HVMOP_altp2m_set_visibility:
>>>
On 26/02/2020 09:32, Jan Beulich wrote:
> On 25.02.2020 18:31, Andrew Cooper wrote:
>> Policy objects aren't tiny, and the derivation logic isn't trivial. We are
>> about to increase the number of policy objects, so take this opportunity to
>> drop logic and storage space based on CONFIG_{PV,HVM}.
flight 147631 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147631/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen d90bcb5f10995c52d080274d66bfdc362b22598e
baseline version:
xen 4cdd
On 24.02.2020 11:46, Roger Pau Monne wrote:
> Using scratch_cpumask in send_IPI_mask is not safe because it can be
> called from interrupt context, and hence Xen would have to make sure
> all the users of the scratch cpumask disable interrupts while using
> it.
>
> Instead introduce a new cpumask
On 26/02/2020 09:19, Jan Beulich wrote:
> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
> be consulted first.
>
> Reported-by: Farrah Chen
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-de
On Wed, Feb 26, 2020 at 10:19:19AM +0100, Jan Beulich wrote:
> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
> be consulted first.
>
> Reported-by: Farrah Chen
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @
On Wed, Feb 26, 2020 at 11:07:44AM +0100, Jan Beulich wrote:
> On 24.02.2020 11:46, Roger Pau Monne wrote:
> > Using scratch_cpumask in send_IPI_mask is not safe because it can be
> > called from interrupt context, and hence Xen would have to make sure
> > all the users of the scratch cpumask disab
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
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-install/l1/l2
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.or
On 24.02.2020 11:46, Roger Pau Monne wrote:
> Current usage of the per-CPU scratch cpumask is dangerous since
> there's no way to figure out if the mask is already being used except
> for manual code inspection of all the callers and possible call paths.
>
> This is unsafe and not reliable, so int
On 26.02.2020 11:09, Roger Pau Monné wrote:
> On Wed, Feb 26, 2020 at 10:19:19AM +0100, Jan Beulich wrote:
>> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
>> be consulted first.
>>
>> Reported-by: Farrah Chen
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/cpu/vpm
On 26.02.2020 10:58, Andrew Cooper wrote:
> On 26/02/2020 09:32, Jan Beulich wrote:
>> On 25.02.2020 18:31, Andrew Cooper wrote:
>>> Policy objects aren't tiny, and the derivation logic isn't trivial. We are
>>> about to increase the number of policy objects, so take this opportunity to
>>> drop l
On 26.02.2020 11:18, Roger Pau Monné wrote:
> On Wed, Feb 26, 2020 at 11:07:44AM +0100, Jan Beulich wrote:
>> On 24.02.2020 11:46, Roger Pau Monne wrote:
>>> Using scratch_cpumask in send_IPI_mask is not safe because it can be
>>> called from interrupt context, and hence Xen would have to make sure
On Wed, Feb 26, 2020 at 11:45:40AM +0100, Jan Beulich wrote:
> On 26.02.2020 11:18, Roger Pau Monné wrote:
> > On Wed, Feb 26, 2020 at 11:07:44AM +0100, Jan Beulich wrote:
> >> On 24.02.2020 11:46, Roger Pau Monne wrote:
> >>> Using scratch_cpumask in send_IPI_mask is not safe because it can be
> >
On 26/02/2020 10:39, Jan Beulich wrote:
> On 26.02.2020 11:09, Roger Pau Monné wrote:
>> On Wed, Feb 26, 2020 at 10:19:19AM +0100, Jan Beulich wrote:
>>> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
>>> be consulted first.
>>>
>>> Reported-by: Farrah Chen
>>> Signed-off-b
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 included in the final binary.
To allow the new syntax, the
Hi Paul,
On 25/02/2020 09:53, Paul Durrant wrote:
There's no particular reason shared_info need use a xenheap page.
AFAICT, a side-effect of this change is the shared_info is now going to
be part of the migration stream. One issue with this is on the restore
side, they will be accounted in n
From: Anthony PERARD
Most of the code executed by Rules.mk isn't necessary for the clean
target, especially not the CFLAGS. This patch makes running make clean
much faster.
The patch extract the clean target into a different Makefile,
Makefile.clean.
Since Makefile.clean, doesn't want to includ
The clang test for "asm()-s support .include." needs to be modified
because the symbolic link asm -> asm-x86 may not exist when the test
is runned. Since it's an x86 test, we don't need the link.
This will be an issue with the following patch "xen/build: have the
root Makefile generates the CFLAGS
That comment was introduce by 3943db776371 ("[XEN] Can be built
-std=gnu99 (except for .S files).") to explain why CFLAGS was removed
from the command line. The comment is already written where the
-std=gnu flags gets remove from AFLAGS, no need to repeat it.
Signed-off-by: Anthony PERARD
---
No
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-by: Anthony PERARD
Reviewed-by: Jan Beulich
---
Note
And simply add directly to AFLAGS.
Signed-off-by: Anthony PERARD
---
Notes:
v3:
- new patch
xen/Rules.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c21203351a9f..154269bfd96c 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@
In common/libelf/Makefile, when SECTIONS gets defined
SPECIAL_DATA_SECTIONS doesn't exist, so only "text data" sections are
been renamed. This was different before 48115d14743e ("Move more
kernel decompression bits to .init.* sections").
Move SPECIAL_DATA_SECTIONS in Rules.mk before including "Mak
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 include Kbuild.include.
Signed-off-by: Anthony PERARD
Reviewe
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-v3
v3:
- new patches that do some cleanup or fix issues
- have rework most patches, to have better commit message or change the coding
style, or fix issues that I've s
It isn't necessary to include Config.mk here because this Makefile is
only used by xen/Rules.mk which already includes Config.mk.
Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
---
xen/include/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/include/Makefile b/xen/inclu
In Arm and X86 makefile, generating the linker script is the same, so
we can simply have both call the same macro.
We need to add *.lds files into extra-y so that Rules.mk can find the
.*.cmd dependency file and load it.
Signed-off-by: Anthony PERARD
---
xen/Rules.mk | 8
xen/
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/Makefile | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index 10bc4bf3646c..8267ace51b0d
In the case where $(obj-y) is empty, we also replace $(c_flags) by
$(XEN_CFLAGS) to avoid generating an .%.d dependency file. This avoid
make trying to include %.h file in the ld command if $(obj-y) isn't
empty anymore on a second run.
Signed-off-by: Anthony PERARD
---
xen/Rules.mk | 13
Rework symbols so it prefer file symbols that names an object file to
file symbols that have a directory component.
But have symbols still prefer the first file symbol if one of the above
is true, or prefer the second file symbols if it names a source file
without directory component.
In a future
From: Anthony PERARD
In a later patch ("xen/build: have the root Makefile generates the
CFLAGS), we want to generate the CFLAGS in xen/Makefile, then export
it and have Rules.mk use a CFLAGS from the environment variables. That
changes the flavor of the CFLAGS and flags intended for one target
(l
Use $(dot-target) to have the target name prefix with a dot.
Now, when the CC command has run, it is recorded in .*.cmd
file, then if_changed_rules will compare it on subsequent runs.
Signed-off-by: Anthony PERARD
---
xen/Rules.mk | 26 +-
1 file changed, 17 insertions(+
Only xen/ uses as-option-add and as-insn, so there aren't needed in
Config.mk.
Signed-off-by: Anthony PERARD
---
Notes:
v3:
- new patch
Config.mk | 17 -
xen/scripts/Kbuild.include | 17 +
2 files changed, 17 insertions(+), 17 deletions(
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 either. Set them
once and for all in the Xen root Makefile
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 one that depends on the targets,
but the variable
The if_changed macro from Linux can record the command used to build a
target then compare it on rebuild. Thus if a command has changed, for
example due to introducing new flags in CFLAGS or due to using a
different compiler, the target will be rebuilt.
if_changed_rule checks dependencies like if_
This patch start to use if_changed introduced in a previous commit.
Whenever if_changed is called, the target must have FORCE as
dependency so that if_changed can check if the command line to be
run as changed, so the macro $(real-prereqs) must be use to
discover the dependencies without "FORCE".
We are going to generate the CFLAGS early from "xen/Makefile" instead
of in "Rules.mk", but we need to include "config/auto.conf", so
include it in "Makefile".
Before including "config/auto.conf" we check which make target a user
is calling, as some targets don't need "auto.conf". For targets that
Use if_changed for building all guest_%.o objects, and make use of
command that already exist.
This patch also introduces CFLAGS_$@, it is used so that flags are
applied to all .o .i and .s targets.
This patch make a change to the way guest_%.o files are built, and now
run the same commands that
We change the dependencies of prelink-efi.o so that we can use the
same command line. The dependency on efi/built_in.o isn't needed
because, we already have:
efi/*.o: efi/built_in.o
to build efi/*.o files that prelink-efi.o needs.
Signed-off-by: Anthony PERARD
---
xen/arch/x86/Makefile | 8 +
On 26.02.2020 12:33, Julien Grall wrote:
> On 25/02/2020 09:53, Paul Durrant wrote:
>> --- a/xen/common/time.c
>> +++ b/xen/common/time.c
>> @@ -99,6 +99,9 @@ void update_domain_wallclock_time(struct domain *d)
>> uint32_t *wc_version;
>> uint64_t sec;
>>
>> +if ( d->is_dying )
>
On 25/02/2020 09:53, Paul Durrant wrote:
> There's no particular reason shared_info need use a xenheap page.
?
There are a number of ABI-critical reasons, not least the evtchn_pending
field which Xen needs to write.
I can see what you're trying to do, and it looks fine in principle, but
the comm
On Wed, Feb 26, 2020 at 11:33:35AM +, Anthony PERARD wrote:
> That comment was introduce by 3943db776371 ("[XEN] Can be built
> -std=gnu99 (except for .S files).") to explain why CFLAGS was removed
> from the command line. The comment is already written where the
> -std=gnu flags gets remove fr
On 21.02.2020 11:42, Hongyan Xia wrote:
> From: Wei Liu
>
> Since we now map and unmap Xen PTE pages, we would like to track the
> lifetime of mappings so that 1) we do not dereference memory through a
> variable after it is unmapped, 2) we do not unmap more than once.
> Therefore, we introduce t
Andrew Cooper writes ("[PATCH v2.1 15/17] tools/libx[cl]: Plumb 'missing'
through static_data_done() up into libxl"):
> Pre Xen-4.14 streams will not contain any CPUID/MSR information. There is
> nothing libxc can do about this, and will have to rely on the higher level
> toolstack to provide bac
> -Original Message-
> From: Andrew Cooper
> Sent: 26 February 2020 11:46
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Volodymyr Babchuk ; George
> Dunlap ; Ian Jackson
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Wei Liu
> Subject: Re: [
> -Original Message-
> From: Julien Grall
> Sent: 26 February 2020 11:33
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Volodymyr Babchuk
> ; Andrew Cooper ;
> George Dunlap ; Ian Jackson
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Wei Liu
> Subject: Re: [
This is modeled after the irq_count variable, and is used to account
for all the NMIs handled by the system.
This will allow to repurpose the nmi_count() helper so it can be used
in a similar manner as local_irq_count(): account for the NMIs
currently in service.
Signed-off-by: Roger Pau Monné
-
Add helpers to track when executing in #MC handler context. This is
modeled after the in_irq helpers.
Note that there are no users of in_mce_handler() introduced by the
change, further users will be added by followup changes.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- Rename to in_m
Hello,
Commit:
5500d265a2a8fa63d60c08beb549de8ec82ff7a5
x86/smp: use APIC ALLBUT destination shorthand when possible
Introduced a bogus usage of the scratch cpumask: it was used in a
function that could be called from interrupt context, and hence using
the scratch cpumask there is not safe. Patc
Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
context because it can nest, and hence send_IPI_mask could be
overwriting another user scratch cpumask data when used in such
contexts.
Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while u
Add helpers to track when running in NMI handler context. This is
modeled after the in_irq helpers.
The SDM states that no NMI can be delivered while handling a NMI
until the processor has executed an iret instruction. It's possible
however that another fault is received while handling the NMI (a
On Wed, Feb 26, 2020 at 01:19:21PM +0100, Roger Pau Monne wrote:
> Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
> context because it can nest, and hence send_IPI_mask could be
> overwriting another user scratch cpumask data when used in such
> contexts.
>
> Instead introd
Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
context because it can nest, and hence send_IPI_mask could be
overwriting another user scratch cpumask data when used in such
contexts.
Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while u
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
Reviewed-by: Wei Liu
---
V3:
- new patch
V4:
- add alignme
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 c
Add the /buildinfo/config entry to the hypervisor filesystem. This
entry contains the .config file used to build the hypervisor.
Signed-off-by: Juergen Gross
---
V3:
- store data in gzip format
- use binfile mechanism to create data file
- move code to kernel.c
V6:
- add config item for the /bui
Instead of xc_set_parameters() use xenhypfs_write() for setting
parameters of the hypervisor.
Signed-off-by: Juergen Gross
---
V6:
- new patch
---
tools/Rules.mk | 2 +-
tools/libxl/Makefile | 3 ++-
tools/libxl/libxl.c | 53 ++
Support of other variable sizes than that of normal bool ones for
boolean_parameter() don't make sense, so catch any other sized
variables at build time.
Fix the one parameter using a plain int instead of bool.
Signed-off-by: Juergen Gross
---
V6:
- new patch
---
xen/arch/x86/hvm/asid.c | 2 +-
Add the new library libxenhypfs for access to the hypervisor filesystem.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
V1:
- rename to libxenhypfs
- add xenhypfs_write()
V3:
- major rework due to new hypervisor interface
- add decompression capability
V4:
- add dependency to libz in pkgco
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 hyp
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
us
There is no user of xc_set_parameters() left, so remove it.
Signed-off-by: Juergen Gross
---
V6:
- new patch
---
tools/libxc/include/xenctrl.h | 1 -
tools/libxc/xc_misc.c | 21 -
2 files changed, 22 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/li
Provide version and compile information in /buildinfo/ node of the
Xen hypervisor file system. As this information is accessible by dom0
only no additional security problem arises.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V3:
- new patch
V4:
- add __read_mostly annotations (Jan
I applied this patch to Xen and retested, Xen on KVM booted up successfully,
thanks a lot.
Thanks,
Fan
-Original Message-
From: Andrew Cooper
Sent: Wednesday, February 26, 2020 6:56 PM
To: Jan Beulich ; Roger Pau Monné
Cc: xen-devel@lists.xenproject.org; Chen, Farrah ; Hao,
Xudong ;
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 addin
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 connection between the parameter
value and the file
The functionality of XEN_SYSCTL_set_parameter is available via hypfs
now, so it can be removed.
This allows to remove the kernel_param structure for runtime parameters
by putting the now only used structure element into the hypfs node
structure of the runtime parameters.
Signed-off-by: Juergen Gr
On 26.02.2020 12:33, Anthony PERARD wrote:
> And simply add directly to AFLAGS.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 26.02.2020 13:19, Roger Pau Monne wrote:
> This is modeled after the irq_count variable, and is used to account
> for all the NMIs handled by the system.
>
> This will allow to repurpose the nmi_count() helper so it can be used
> in a similar manner as local_irq_count(): account for the NMIs
>
On 26.02.2020 13:19, Roger Pau Monne wrote:
> Add helpers to track when running in NMI handler context. This is
> modeled after the in_irq helpers.
>
> The SDM states that no NMI can be delivered while handling a NMI
> until the processor has executed an iret instruction. It's possible
> however t
On 26.02.2020 13:19, Roger Pau Monne wrote:
> Add helpers to track when executing in #MC handler context. This is
> modeled after the in_irq helpers.
>
> Note that there are no users of in_mce_handler() introduced by the
> change, further users will be added by followup changes.
>
> Signed-off-by
On 26.02.2020 13:38, Roger Pau Monne wrote:
> Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
> context because it can nest, and hence send_IPI_mask could be
> overwriting another user scratch cpumask data when used in such
> contexts.
>
> Instead introduce a new cpumask to
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
This patch fixes Coverity issue CID 1459006 (Insecure data handling
(INTEGER_OVERFLOW)).
The problem is that the error paths for libxl__mark_domid_recent() and
libxl__is_domid_recent() check the 'f' field in struct libxl__domid_history
when it may not have been initialized.
Signed-off-by: Paul Du
flight 147541 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147541/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 133580
test-amd64-amd64-xl
flight 147633 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147633/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 147546 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147546/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
test-amd64-i386-f
On 25.02.2020 10:53, Paul Durrant wrote:
> There's no particular reason shared_info need use a xenheap page. It's
> only purpose is to be mapped by the guest so use a PGC_extra domheap page
> instead.
Since the cover letter also doesn't give any background - is there a
problem with the current arr
On Wed, Feb 26, 2020 at 02:10:44PM +0100, Jan Beulich wrote:
> On 26.02.2020 13:38, Roger Pau Monne wrote:
> > Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
> > context because it can nest, and hence send_IPI_mask could be
> > overwriting another user scratch cpumask data w
On 24.02.20 23:25, Julien Grall wrote:
Hi Juergen,
On 11/02/2020 09:31, Juergen Gross wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6f9bec22d3..30c4c1830b 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -23,7 +23,6 @@
#include
#include
#include
-
> -Original Message-
> From: Jan Beulich
> Sent: 26 February 2020 13:58
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Julien Grall ; Volodymyr Babchuk
> ; Andrew Cooper ;
> George Dunlap ; Ian Jackson
> ; Konrad Rzeszutek Wilk
> ; Wei Liu
> Subject: Re:
On 26/02/2020 12:03, Durrant, Paul wrote:
-Original Message-
From: Julien Grall
Sent: 26 February 2020 11:33
To: Durrant, Paul ; xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ; Volodymyr Babchuk
; Andrew Cooper ;
George Dunlap ; Ian Jackson
; Jan Beulich ; Konrad
Rzeszutek Wilk
On 26.02.2020 15:22, Julien Grall wrote:
> On 26/02/2020 12:03, Durrant, Paul wrote:
>>> From: Julien Grall
>>> Sent: 26 February 2020 11:33
>>>
>>> On 25/02/2020 09:53, Paul Durrant wrote:
For Arm, the call to free_shared_info() in arch_domain_destroy() is left
in place since it called
On Tue, Feb 25, 2020 at 11:17:55AM -0800, Tamas K Lengyel wrote:
> VM forking is the process of creating a domain with an empty memory space and
> a
> parent domain specified from which to populate the memory when necessary. For
> the new domain to be functional the VM state is copied over as part
Replace perl with cmp-fd-file-inode when checking that the lock file
descriptor and lockfile inodes match.
Signed-off-by: Jason Andryuk
---
tools/hotplug/Linux/locking.sh | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/tools/hotplug/Linux/locking.sh b/tools/hotplug
Perl is a large dependency for locking.sh's single use of comparing a
file descriptor's and a file's inodes. Many systems don't otherwise
require perl, so dropping this use eliminates the dependency.
Replace the open-coded perl with an equivalent C implementation.
Jason Andryuk (2):
tools/help
This is a C implementation of the perl code inside of locking.sh to
check that the locked file descriptor and lock file share the same inode
and therefore match. One change from the perl version is replacing
printing "y" on success with exit values of 0 (shell True) and 1 (shell
False).
Requiring
> > +if ( (ret = cpupool_move_domain(cd, d->cpupool)) )
> > +return ret;
>
> You can join both ifs into a single one, since both return ret.
Sure.
> > +
> > +for ( i = 0; i < cd->max_vcpus; i++ )
> > +{
> > +mfn_t vcpu_info_mfn;
> > +
> > +if ( !d->vcpu[i] || c
On 26.02.2020 15:05, Durrant, Paul wrote:
>> From: Jan Beulich
>> Sent: 26 February 2020 13:58
>>
>> On 25.02.2020 10:53, Paul Durrant wrote:
>>> There's no particular reason shared_info need use a xenheap page. It's
>>> only purpose is to be mapped by the guest so use a PGC_extra domheap
>> page
On Tue, Feb 25, 2020 at 11:17:56AM -0800, Tamas K Lengyel wrote:
> Implement hypercall that allows a fork to shed all memory that got allocated
> for it during its execution and re-load its vCPU context from the parent VM.
> This allows the forked VM to reset into the same state the parent VM is in
> You also need to reset the contents of the special pages, the
> vcpu_info pages and the shared_info page in order to match the state
> the VM was in when forking.
Ack.
>
> PV timers should also be reset to parent's state AFAICT, or else you
> will get spurious timer interrupts.
Could you point
On Wed, Feb 26, 2020 at 08:20:30AM -0700, Tamas K Lengyel wrote:
> > > +static int populate_special_pages(struct domain *cd)
> > > +{
> > > +struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> > > +static const unsigned int params[] =
> > > +{
> > > +HVM_PARAM_STORE_PFN,
> > > +
On Wed, Feb 26, 2020 at 08:28:31AM -0700, Tamas K Lengyel wrote:
> > You also need to reset the contents of the special pages, the
> > vcpu_info pages and the shared_info page in order to match the state
> > the VM was in when forking.
>
> Ack.
>
> >
> > PV timers should also be reset to parent's
1 - 100 of 143 matches
Mail list logo
