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
---
.gitignore | 1 +
xen/tools/binfile
Add the xenfs tool for accessing the hypervisor filesystem.
Signed-off-by: Juergen Gross
---
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 cat subcommand (Ian
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 st
Move the parameter related definitions from init.h into a new header
file param.h. This will avoid include hell when new dependencies are
added to parameter definitions.
Signed-off-by: Juergen Gross
---
V3:
- new patch
---
xen/arch/arm/acpi/boot.c | 1 +
xen/arch/arm/cpuerrata.
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
---
.gitignore |
Add the infrastructure for the hypervisor filesystem.
This includes the hypercall interface and the base functions for
entry creation, deletion and modification.
Signed-off-by: Juergen Gross
---
V1:
- rename files from filesystem.* to hypfs.*
- add dummy write entry support
- rename hypercall fi
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
Add the new library libxenhypfs for access to the hypervisor filesystem.
Signed-off-by: Juergen Gross
---
V1:
- rename to libxenhypfs
- add xenhypfs_write()
V3:
- major rework due to new hypervisor interface
- add decompression capability
---
.gitignore | 2 +
tools/R
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
---
V3:
- new patch
---
docs/misc/hypfs-paths.pandoc | 45
On 20.01.2020 18:18, Roger Pau Monné wrote:
> On Mon, Jan 20, 2020 at 05:10:33PM +0100, Jan Beulich wrote:
>> On 17.01.2020 12:08, Roger Pau Monne wrote:
>>> When placing memory BARs with sizes smaller than 4K multiple memory
>>> BARs can end up mapped to the same guest physical address, and thus
>
On 21.01.2020 00:50, Eslam Elnikety wrote:
> On 20.01.20 09:42, Jan Beulich wrote:
>> On 17.01.2020 20:06, Eslam Elnikety wrote:
>>> On 20.12.19 10:53, Jan Beulich wrote:
On 19.12.2019 22:08, Eslam Elnikety wrote:
> On 18.12.19 12:49, Jan Beulich wrote:
>> On 18.12.2019 02:32, Eslam El
On Mon, Jan 20, 2020 at 01:20:47PM +0100, Thomas Zimmermann wrote:
> 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 implement
Add __acpi_unmap_table function for ARM and invoke it at acpi_os_unmap_memory
to make sure the related fixmap has been cleared before using it for a
different mapping.
Signed-off-by: Wei Xu
---
xen/arch/arm/acpi/lib.c | 25 +
xen/drivers/acpi/osl.c | 2 ++
xen/include/x
flight 146340 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146340/
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. 146058
> On Jan 20, 2020, at 11:41 PM, Nick Rosbrook wrote:
>
>> The other option would be to expose the XTL logging levels and let the
>> caller set them somehow.
> I think this is fine for now.
>
> For the future, I like using the "functional option" pattern for this
> sort of thing. That way, if a
On 21.01.2020 11:49, Wei Xu wrote:
> Add __acpi_unmap_table function for ARM and invoke it at acpi_os_unmap_memory
> to make sure the related fixmap has been cleared before using it for a
> different mapping.
>
> Signed-off-by: Wei Xu
> ---
> xen/arch/arm/acpi/lib.c | 25 ++
CONFIG_DEBUG_LOCKS is using ASSERT() for catching issues making it
depend on CONFIG_DEBUG.
This series fixes that by using BUG_ON() instead. In order not to lose
the rather nice debugging information which condition was hit add a
config option to include a message similar to the one ASSERT() is
pr
In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
as it is using ASSERT(), however.
Fix that by using BUG_ON() instead of ASSERT() in rel_lock().
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
xen/
Today a triggering BUG_ON() will only print source file and line
information. Add the possibility to print the triggering condition like
ASSERT().
Do that by introducing BUG_VERBOSE() and add a Kconfig option to make
BUG_ON use BUG_VERBOSE().
Signed-off-by: Juergen Gross
---
V3:
- move kconfig o
On Sun, Jan 19, 2020 at 03:17:13AM +, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
> testid debian-hvm-install
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xe
On Tue, Jan 21, 2020 at 10:18:16AM +0100, Jan Beulich wrote:
> On 20.01.2020 18:18, Roger Pau Monné wrote:
> > On Mon, Jan 20, 2020 at 05:10:33PM +0100, Jan Beulich wrote:
> >> On 17.01.2020 12:08, Roger Pau Monne wrote:
> >>> When placing memory BARs with sizes smaller than 4K multiple memory
> >>
Ping? I have acks from Lars and Wei but this doesn't appear to have been
committed. Are any more acks required?
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 13 January 2020 15:32
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Andrew Cooper
> ; George Dunlap ;
> I
Hi Paul,
On 21/01/2020 10:32, Durrant, Paul wrote:
Ping? I have acks from Lars and Wei but this doesn't appear to have been
committed. Are any more acks required?
You have two acks and no more comments for the past week. So I am going
to commit it.
Cheers,
Paul
-Original Messag
On 21.01.2020 11:29, Roger Pau Monné wrote:
> So I'm not sure how to progress with this patch, are we fine with
> those limitations?
I'm afraid this depends on ...
> As I said, Xen hasn't got enough knowledge to correctly isolate the
> BARs, and hence we have to rely on dom0 DTRT. We could add ch
On 21.01.2020 11:13, Juergen Gross wrote:
> Today a triggering BUG_ON() will only print source file and line
> information. Add the possibility to print the triggering condition like
> ASSERT().
>
> Do that by introducing BUG_VERBOSE() and add a Kconfig option to make
> BUG_ON use BUG_VERBOSE().
>
On 21.01.2020 10:49, Wei Xu wrote:
> Add __acpi_unmap_table function for ARM and invoke it at acpi_os_unmap_memory
> to make sure the related fixmap has been cleared before using it for a
> different mapping.
How can it possibly be that this is needed for Arm only?
> --- a/xen/arch/arm/acpi/lib.c
On 21.01.2020 04:44, Wei Xu wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -1620,6 +1620,66 @@ DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
> DT_DEVICE_END
>
> #endif /* HAS_DEVICE_TREE */
> +#if defined(CONFIG_ACPI) && defined(CONFIG_ARM)
Blank
On 21/01/2020 11:13, Jan Beulich wrote:
+if ( ACPI_FAILURE(status) )
+{
+printk("ns16550: Failed to get SPCR table\n");
Is such a message warranted? I.e. wouldn't it trigger on all
systems not having the table, which is hardly what you/we want?
+return -EINVAL;
A
Hi Jan,
On 21/01/2020 11:02, Jan Beulich wrote:
On 21.01.2020 10:49, Wei Xu wrote:
Add __acpi_unmap_table function for ARM and invoke it at acpi_os_unmap_memory
to make sure the related fixmap has been cleared before using it for a
different mapping.
How can it possibly be that this is needed
On 21.01.2020 12:16, Julien Grall wrote:
> On 21/01/2020 11:13, Jan Beulich wrote:
>>
>>> +if ( ACPI_FAILURE(status) )
>>> +{
>>> +printk("ns16550: Failed to get SPCR table\n");
>>
>> Is such a message warranted? I.e. wouldn't it trigger on all
>> systems not having the table, which
Hi Juergen,
On 21/01/2020 10:13, Juergen Gross wrote:
Today a triggering BUG_ON() will only print source file and line
information. Add the possibility to print the triggering condition like
ASSERT().
Any reason to only limit the change for BUG_ON? How about WARN_ON?
Do that by introducing
Hi Jan,
On 21/01/2020 11:25, Jan Beulich wrote:
On 21.01.2020 12:16, Julien Grall wrote:
On 21/01/2020 11:13, Jan Beulich wrote:
+if ( ACPI_FAILURE(status) )
+{
+printk("ns16550: Failed to get SPCR table\n");
Is such a message warranted? I.e. wouldn't it trigger on all
syst
Paul Durrant (3):
x86 / vmx: make apic_access_mfn type-safe
x86 / hvm: add domain_relinquish_resources() method
x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE
xen/arch/x86/hvm/hvm.c | 2 ++
xen/arch/x86/hvm/mtrr.c| 2 +-
xen/arch/x86/hvm/svm/svm.
There are two functions in hvm.c to deal with tear-down and a domain:
hvm_domain_relinquish_resources() and hvm_domain_destroy(). However, only
the latter has an associated method in 'hvm_funcs'. This patch adds
a method for the former and stub definitions for SVM and VMX.
The VMX method will be u
Use mfn_t rather than unsigned long and change previous tests against 0 to
tests against INVALID_MFN (also introducing initialization to that value).
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: Jun Nakajima
Cc: Kevin Tian
---
xen/
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
Hi,
On 21/01/2020 12:00, Paul Durrant wrote:
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 919a270587..ef327072ed 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2269,7 +2269,8 @@ int assign_pages(
if ( !(memflags & MEMF_no_refcount) )
> -Original Message-
> From: Xen-devel On Behalf Of
> Julien Grall
> Sent: 21 January 2020 12:29
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Stefano Stabellini
> ; Jun Nakajima ; Wei Liu
> ; Konrad Rzeszutek Wilk ; George
> Dunlap ; Andrew Cooper
> ; Ian Jackson
flight 146346 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146346/
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 146345 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146345/
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 Fri, 2020-01-17 at 15:31 +0200, Alexandru Stefan ISAILA wrote:
> This patch aims to sanitize indexes, potentially guest provided
> values, for altp2m_eptp[] and altp2m_p2m[] arrays.
>
> Requested-by: Jan Beulich
> Signed-off-by: Alexandru Isaila
> Acked-by: Tamas K Lengyel
>
Reviewed-by: Pe
On Fri, 2020-01-17 at 15:31 +0200, Alexandru Stefan ISAILA wrote:
> At this moment the default_access param from xc_altp2m_create_view is
> not used.
>
> This patch assigns default_access to p2m->default_access at the time
> of
> initializing a new altp2m view.
>
> Signed-off-by: Alexandru Isaila
On Fri, 2020-01-17 at 15:31 +0200, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not break in
> case
> of a error and it
Hi Juergen,
On 21/01/2020 08:43, Juergen Gross wrote:
Move the parameter related definitions from init.h into a new header
file param.h. This will avoid include hell when new dependencies are
added to parameter definitions.
How did you find out the list of places where the new files need to be
On Fri, 2020-01-17 at 13:31 +, Alexandru Stefan ISAILA wrote:
> No functional changes.
>
> Requested-by: Jan Beulich
> Signed-off-by: Alexandru Isaila
> Reviewed-by: Jan Beulich
>
Reviewed-by: Petre Pircalabu
___
Xen-devel mailing list
Xen-deve
Hi Juergen.
On 21/01/2020 08:43, Juergen Gross wrote:
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
add
flight 146349 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146349/
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 21.01.20 14:00, Julien Grall wrote:
Hi Juergen,
On 21/01/2020 08:43, Juergen Gross wrote:
Move the parameter related definitions from init.h into a new header
file param.h. This will avoid include hell when new dependencies are
added to parameter definitions.
How did you find out the list
On 21/01/2020 13:28, Jürgen Groß wrote:
On 21.01.20 14:00, Julien Grall wrote:
Hi Juergen,
On 21/01/2020 08:43, Juergen Gross wrote:
Move the parameter related definitions from init.h into a new header
file param.h. This will avoid include hell when new dependencies are
added to parameter de
The XEN_BUILD_EFI tests in arch/x86/Makefile was filtering out
CFLAGS-y, but according to dd40177c1bc8 ("x86-64/EFI: add CFLAGS to
check compile"), it was done to filter out -MF. XEN_CFLAGS doesn't
have those flags anymore, so no filtering is needed.
Signed-off-by: Anthony PERARD
---
xen/arch/x8
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
---
Makefile | 6 ++
xen/M
-DXEN_BUILD_EFI and -DBUILD_ID_EFI seems to only be used in xen.lds.S
which is build using the AFLAGS, so add those flags only to asflags-y.
Signed-off-by: Anthony PERARD
---
That fix build of xen.efi.
Should add asflags-y into the patch title.
---
xen/Rules.mk | 4 +++-
xen/arch/x86/M
(Actually CCing all that are CCed on patches)
On Fri, Jan 17, 2020 at 10:53:46AM +, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> br.build-system-xen-v2
>
> series is based on "[XEN PATCH v3 0/6] xen: K
On 21.01.20 14:14, Julien Grall wrote:
Hi Juergen.
On 21/01/2020 08:43, Juergen Gross wrote:
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 o
On 21.01.20 12:38, Julien Grall wrote:
Hi Juergen,
On 21/01/2020 10:13, Juergen Gross wrote:
Today a triggering BUG_ON() will only print source file and line
information. Add the possibility to print the triggering condition like
ASSERT().
Any reason to only limit the change for BUG_ON? How a
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 accesses when GICD_CTLR.DS = 0.
This implements the GICD_I
flight 146353 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146353/
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 1/18/2020 6:49 AM, Julien Grall wrote:
> On 17/01/2020 21:29, Jeff Kubascik wrote:
>> On 12/18/2019 9:24 AM, Julien Grall wrote:
>>> Hi Jeff,
>>>
>>> On 11/12/2019 21:13, Jeff Kubascik wrote:
Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4
specifies that the values in
Hi Sergey,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on tip/x86/mm tip/auto-latest linux/master linus/master
v5.5-rc7 next-20200117]
[if your patch is applied to the wrong git tree, please drop us a note to help
improv
This patch set improves the emulation of the physical timer by removing the
physical timer offset and sign extend the TimerValue to better match the
behavior described in the ARMv8 Reference Manual (ARM DDI 0487E.a), section
D11.2.4.
Changes in v2:
- Update commit message to specify reference manu
Xen will only store the CompareValue as it can be derived from the
TimerValue (ARM DDI 0487E.a section D11.2.4):
CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0]
While the TimerValue is a 32-bit signed value, our implementation
assumed it is a 32-bit unsigned value.
Signed-off-by:
The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section
D11.2.4 Timers, the "Offset" between the counter and timer should be
zero for a physical
Hi George,
This is a kind reminder, when you have the time, can you take a look at
this series?
Regards,
Alex
On 17.01.2020 15:31, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve b
On Tue, Jan 21, 2020 at 11:43:58AM +0100, Jan Beulich wrote:
> On 21.01.2020 11:29, Roger Pau Monné wrote:
> > So I'm not sure how to progress with this patch, are we fine with
> > those limitations?
>
> I'm afraid this depends on ...
>
> > As I said, Xen hasn't got enough knowledge to correctly
On 21.01.2020 16:57, Roger Pau Monné wrote:
> On Tue, Jan 21, 2020 at 11:43:58AM +0100, Jan Beulich wrote:
>> On 21.01.2020 11:29, Roger Pau Monné wrote:
>>> So I'm not sure how to progress with this patch, are we fine with
>>> those limitations?
>>
>> I'm afraid this depends on ...
>>
>>> As I sai
The define is only used in one other place. Move the code there
instead of keeping this xen-specific define in sysemu.h.
Signed-off-by: Thomas Huth
---
hw/xenpv/xen_machine_pv.c | 2 +-
include/sysemu/sysemu.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/xenpv/xen_ma
Hi Sergey,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on tip/x86/mm tip/auto-latest linux/master linus/master
v5.5-rc7 next-20200121]
[if your patch is applied to the wrong git tree, please drop us a note to help
On 1/21/20 5:17 PM, Thomas Huth wrote:
The define is only used in one other place. Move the code there
instead of keeping this xen-specific define in sysemu.h.
Signed-off-by: Thomas Huth
Reviewed-by: Philippe Mathieu-Daudé
---
hw/xenpv/xen_machine_pv.c | 2 +-
include/sysemu/sysemu.h
On Tue, Jan 21, 2020 at 03:34:13AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné
> > Sent: Monday, January 20, 2020 6:19 PM
> >
> > On Sun, Jan 19, 2020 at 04:15:04AM +, Tian, Kevin wrote:
> > > > From: Roger Pau Monne
> > > > Sent: Wednesday, January 8, 2020 6:39 PM
> > > >
> > > > Wh
Hi,
I looked around a bit and wasn't able to find a good answer to this, so
George suggested I ask here.
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 produces
this sort of output:
# xl sched-credit2 -d yw6hk7mo6
On Tue, Jan 21, 2020 at 05:15:20PM +0100, Jan Beulich wrote:
> On 21.01.2020 16:57, Roger Pau Monné wrote:
> > On Tue, Jan 21, 2020 at 11:43:58AM +0100, Jan Beulich wrote:
> >> On 21.01.2020 11:29, Roger Pau Monné wrote:
> >>> So I'm not sure how to progress with this patch, are we fine with
> >>>
On Tue, 21 Jan 2020 at 16:18, Thomas Huth wrote:
>
> The define is only used in one other place. Move the code there
> instead of keeping this xen-specific define in sysemu.h.
>
> Signed-off-by: Thomas Huth
Acked-by: Paul Durrant
___
Xen-devel mailin
On 21.01.20 17:56, Kevin Stange wrote:
Hi,
I looked around a bit and wasn't able to find a good answer to this, so
George suggested I ask here.
Cc-ing Jim.
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 produ
On 1/21/20 3:09 PM, Alexandru Stefan ISAILA wrote:
> Hi George,
>
> This is a kind reminder, when you have the time, can you take a look at
> this series?
It's on the top of my list of things to review. :-) I should be able to
get to it Thursday.
-George
_
On 1/20/20 11:39 PM, Nick Rosbrook wrote:
> Sorry I didn't catch this the first time around, but:
>
>> diff --git a/tools/golang/xenlight/helpers.gen.go
>> b/tools/golang/xenlight/helpers.gen.go
>> index b9a7e828a0..889807d928 100644
>> --- a/tools/golang/xenlight/helpers.gen.go
>> +++ b/tools/g
The owner domain of shared pages is dom_cow, use that for get_page
otherwise the function fails to return the correct page.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/p2m.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m
It's not being called from outside mem_sharing.c
Signed-off-by: Tamas K Lengyel
Reviewed-by: Jan Beulich
---
xen/arch/x86/mm/mem_sharing.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index cc3fc97618..5
The following series implements VM forking for Intel HVM guests to allow for
the fast creation of identical VMs without the assosciated high startup costs
of booting or restoring the VM from a savefile.
JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
The fork operation is implemented a
While using _mfn(0) is of no consequence during teardown, INVALID_MFN is the
correct value that should be used.
Signed-off-by: Tamas K Lengyel
Reviewed-by: Jan Beulich
---
xen/arch/x86/mm/mem_sharing.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/mm/mem_s
MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
However, the bitfield is not used for anything else, so just convert it to a
bool instead.
Signed-off-by: Tamas K Lengyel
Reviewed-by: Jan Beulich
---
xen/arch/x86/mm/mem_sharing.c | 9 -
xen/include/asm-x86/m
Create struct mem_sharing_domain under hvm_domain and move mem sharing
variables into it from p2m_domain and hvm_domain.
Expose the mem_sharing_enabled macro to be used consistently across Xen.
Remove some duplicate calls to mem_sharing_enabled in mem_sharing.c
Signed-off-by: Tamas K Lengyel
Ac
It is wasteful to require separate hypercalls to enable sharing on both the
parent and the client domain during VM forking. To speed things up we enable
sharing on the first memop in case it wasn't already enabled.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 52 +++
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 of the fork
operation (HVM params, hap allocation, etc).
Signed-off-by:
Currently the hvm parameters are only accessible via the HVMOP hypercalls. In
this patch we introduce a new function that can copy both the hvm context and
parameters directly into a target domain. No functional changes in existing
code.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/hvm/hvm.c
During VM forking the client lock will already be taken.
Signed-off-by: Tamas K Lengyel
Acked-by: Andrew Coopers
---
xen/arch/x86/mm/mem_sharing.c | 11 ++-
xen/include/asm-x86/p2m.h | 10 +-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/mm/me
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 to
spurious vm_events being sent out for access violations at unexpected
locations. Make use of p2m->default_access instead.
Signed-off-by: Tamas K Lengye
During VM forking we'll copy the parent domain's parameters to the client,
including the HAP shadow memory setting that is used for storing the domain's
EPT. We'll copy this in the hypervisor instead doing it during toolstack launch
to allow the domain to start executing and unsharing memory before
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.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_access.c | 5 ++---
1 file changed, 2 insertions(+), 3 delet
The page was already tried to be unshared in get_gfn_type_access. If that
didn't work, then trying again is pointless. Don't try to send vm_event again
either, simply check if there is a ring or not.
Signed-off-by: Tamas K Lengyel
Acked-by: Jan Beulich
---
xen/arch/x86/hvm/hvm.c | 25 ++
All callers pass 0 in.
Signed-off-by: Tamas K Lengyel
Reviewed-by: Wei Liu
---
xen/arch/x86/hvm/hvm.c| 2 +-
xen/arch/x86/mm/p2m.c | 5 ++---
xen/common/memory.c | 2 +-
xen/include/asm-x86/mem_sharing.h | 8 +++-
4 files changed, 7 insertions(+), 10 de
Using XENLOG_ERR level since this is only used in debug paths (ie. it's
expected the user already has loglvl=all set). Also use %pd to print the domain
ids.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 82 +--
1 file changed, 41 insertions(+)
Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
doc
Trying to share these would fail anyway, better to skip them early.
Signed-off-by: Tamas K Lengyel
Reviewed-by: Jan Beulich
---
xen/arch/x86/mm/mem_sharing.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
in
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 a
faster way then creating a new fork would be. Measurements show abou
flight 146356 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146356/
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 Fri, Dec 27, 2019 at 01:42:37PM +, Andrew Cooper wrote:
> our @msgs() is an array of $msginfo's where the first element is a
> unique number. The $msgnum_used check ensures they are unique. Instead
> if specifying them explicitly, generate msgnum locally. This reduces
> the diff necessary
On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki
wrote:
>
> Add a simple proxy for tunneling socket connection over vchan. This is
> based on existing vchan-node* applications, but extended with socket
> support. vchan-socket-proxy serves both as a client and as a server,
> depending on
flight 146350 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146350/
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. 146058
On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki
wrote:
>
> Access to QMP of QEMU in Linux stubdomain is possible over vchan
> connection. Handle the actual vchan connection in a separate process
> (vchan-socket-proxy). This simplified integration with QMP (already
> quite complex), but
1 - 100 of 159 matches
Mail list logo
