Hi Roman,
On 19/12/2019 00:28, Roman Shaposhnik wrote:
On Wed, Dec 18, 2019 at 2:17 PM Julien Grall wrote:
Hi Roman,
On 18/12/2019 17:03, Roman Shaposhnik wrote:
On Wed, Dec 18, 2019 at 3:50 AM Julien Grall wrote:
So -- nothing boots directly by UEFI -- everything goes through GRUB.
Hi Tamas,
On 19/12/2019 00:15, Tamas K Lengyel wrote:
On Wed, Dec 18, 2019 at 4:02 PM Julien Grall wrote:
Hi,
On 18/12/2019 22:33, Tamas K Lengyel wrote:
On Wed, Dec 18, 2019 at 3:00 PM Julien Grall wrote:
Hi Tamas,
On 18/12/2019 19:40, Tamas K Lengyel wrote:
Implement hypercall that
Some code is not needed with CONFIG_CRASH_DEBUG, so only include it if
CONFIG_CRASH_DEBUG is defined.
While at it remove CONFIG_HAS_GDBSX as it can easily be replaced by
CONFIG_CRASH_DEBUG.
Signed-off-by: Juergen Gross
---
V3:
- move domain_pause_for_debugger() into arch/x86/domain.c (Andrew
Support for debugging the hypervisor of guests via gdb/gdbsx should be
configurable.
Changes in V3:
- remove possibility to access hypervisor memory via gdbsx domctl
- default gdbsx support to on
- some code moving
Changes in V2:
- split support for gdbstub and gdbsx (Andrew Cooper)
Juergen
flight 144940 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144940/
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
flight 144957 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144957/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c7a0aca0ed0e9b51efe0c437ff77b30cf1457f8a
baseline version:
ovmf
flight 144936 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144936/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 144905
test-armhf-armhf-xl-rtds
On Tue, Dec 03, 2019 at 04:17:33PM +0100, Roger Pau Monné wrote:
> On Tue, Dec 03, 2019 at 06:41:56AM +0100, Marek Marczykowski-Górecki wrote:
> > QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
> > MSI(-X) enable flags in the PCI config space. This adds an attribute
> >
QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
MSI(-X) enable flags in the PCI config space. This adds an attribute
'allow_interrupt_control' which when set for a PCI device allows writes
to this flag(s). The toolstack will need to set this for stubdoms.
When enabled,
On 2019-12-19 02:42, Ian Jackson wrote:
Steven Haigh writes ("[PATCH] [tools/hotplug] Use ip on systems where
brctl is not available"):
Newer distros like CentOS 8 do not have brctl available. As such, we
can't use it to configure networking anymore.
This patch will fall back to 'ip' or
Hi Julien! First of all -- thank you so much for detailed explanations
-- this is very much appreciated.
A few questions still (if you don't mind):
On Wed, Dec 18, 2019 at 2:17 PM Julien Grall wrote:
>
> Hi Roman,
>
> On 18/12/2019 17:03, Roman Shaposhnik wrote:
> > On Wed, Dec 18, 2019 at 3:50
On Wed, Dec 18, 2019 at 4:02 PM Julien Grall wrote:
>
> Hi,
>
> On 18/12/2019 22:33, Tamas K Lengyel wrote:
> > On Wed, Dec 18, 2019 at 3:00 PM Julien Grall wrote:
> >>
> >> Hi Tamas,
> >>
> >> On 18/12/2019 19:40, Tamas K Lengyel wrote:
> >>> Implement hypercall that allows a fork to shed all
On Wed, 18 Dec 2019, Mark Brown wrote:
> In an effort to clarify and simplify the annotation of assembly functions
> in the kernel new macros have been introduced. These replace ENTRY and
> ENDPROC. Update the annotations in the xen code to the new macros.
>
> Signed-off-by: Mark Brown
> ---
>
Hi,
On 18/12/2019 22:33, Tamas K Lengyel wrote:
On Wed, Dec 18, 2019 at 3:00 PM Julien Grall wrote:
Hi Tamas,
On 18/12/2019 19:40, 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
On Wed, Dec 18, 2019 at 10:32:47PM +, Andrew Cooper wrote:
> On 18/12/2019 22:26, Marek Marczykowski-Górecki wrote:
> >> @@ -70,7 +73,7 @@ class VM(object):
> >>
> >> # libxl
> >> self.libxl = fmt == "libxl"
> >> -self.emu_xenstore = "" # NUL terminated key pairs
Hi,
On 18/12/2019 17:09, Roman Shaposhnik wrote:
Hi,
On Wed, Dec 18, 2019 at 4:56 AM Julien Grall wrote:
So that is, in fact, my first question -- why is Xen not showing
available memory in xl info?
I am not entirely sure what exact information you want.
The output you dumped above
On Wed, Dec 18, 2019 at 3:00 PM Julien Grall wrote:
>
> Hi Tamas,
>
> On 18/12/2019 19:40, 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
On 18/12/2019 22:26, Marek Marczykowski-Górecki wrote:
>> @@ -70,7 +73,7 @@ class VM(object):
>>
>> # libxl
>> self.libxl = fmt == "libxl"
>> -self.emu_xenstore = "" # NUL terminated key pairs from
>> "toolstack" records
>> +self.emu_xenstore = b"" # NUL
On Wed, Dec 18, 2019 at 03:05:22PM +, Andrew Cooper wrote:
> convert-legacy-stream is only used for incomming migration from pre Xen 4.7,
> and verify-stream-v2 appears to only be used by me during migration
> development - it is little surprise that they missed the main converstion
> effort
On Wed, 18 Dec 2019 at 20:24, Michael Kelley wrote:
>
> From: Durrant, Paul Sent: Wednesday, December 18, 2019
> 7:24 AM
>
> > > From: Wei Liu On Behalf Of Wei Liu
> > > Sent: 18 December 2019 14:43
>
> [snip]
>
> > > +
> > > +static inline uint64_t read_hyperv_timer(void)
> > > +{
> > > +
On Wed, Dec 18, 2019 at 2:29 PM Julien Grall wrote:
>
> Hi Tamas,
>
> On 18/12/2019 19:40, Tamas K Lengyel wrote:
> > 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.
> >
>
On Wed, 18 Dec 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 17/12/2019 18:28, Stefano Stabellini wrote:
> > > Then I tried to passthrough the eMMC, but I got the following
> > > error:
> > > (XEN) DOM1: [0.879151] sdhci-esdhc-imx 4005d000.usdhc: can't request
> > > region for resource [mem
Hi Roman,
On 18/12/2019 17:03, Roman Shaposhnik wrote:
On Wed, Dec 18, 2019 at 3:50 AM Julien Grall wrote:
So -- nothing boots directly by UEFI -- everything goes through GRUB.
However, my understanding is that GRUB will detect devicetree
information provided by UEFI (even though devicetree
Hi Tamas,
On 18/12/2019 19:40, 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 a
faster way
Hi Tamas,
On 18/12/2019 19:40, Tamas K Lengyel wrote:
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
---
xen/arch/x86/mm/mem_sharing.c | 7
> > /*
> > - * Whenever we re-enter userspace, the domains should always be
> > + * Whenever we re-enter kernel, the domains should always be
>
> This feels unrelated from the rest of the patch and probably want an
> explanation. So I think this want to be in a separate patch.
I
On Mon, Dec 16, 2019 at 3:41 PM Julien Grall wrote:
>
> Hello,
>
> On 04/12/2019 23:20, Pavel Tatashin wrote:
> > privcmd_call requires to enable access to userspace for the
> > duration of the hypercall.
> >
> > Currently, this is done via assembly macros. Change it to C
> > inlines instead.
> >
flight 144932 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144932/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 144774
Tests which did not
From: Durrant, Paul Sent: Wednesday, December 18, 2019
7:24 AM
> > From: Wei Liu On Behalf Of Wei Liu
> > Sent: 18 December 2019 14:43
[snip]
> > +
> > +static inline uint64_t read_hyperv_timer(void)
> > +{
> > +uint64_t scale, offset, ret, tsc;
> > +uint32_t seq;
> > +const
On 18/12/2019 16:09, Paul Durrant wrote:
> ...for patches not (yet) upstream.
>
> This patch is simply reserving save record number space to avoid the
> risk of clashes between existent downstream changes made by Amazon and
> future upstream changes which may be incompatible.
>
> Signed-off-by:
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 | 39
Trying to share these would fail anyway, better to skip them early.
Signed-off-by: Tamas K Lengyel
---
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
index
Add necessary bits to implement "xl fork-vm", "xl fork-launch-dm" and
"xl fork-reset" commands. The process is split in two to allow tools needing
access to the new VM as fast as possible after it was forked. It is expected
that under certain use-cases the second command that launches QEMU will be
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
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
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 46 +--
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 90b6371e2f..e5c1424f9b 100644
---
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
---
xen/arch/x86/mm/mem_sharing.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c
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
---
xen/arch/x86/hvm/hvm.c | 26 +-
1
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
---
xen/arch/x86/mm/mem_sharing.c | 7 +++
xen/arch/x86/mm/p2m.c | 1 +
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
During VM forking the client lock will already be taken.
Signed-off-by: Tamas K Lengyel
---
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/mem_sharing.c
Using XENLOG_ERR level since this is only used in debug paths (ie. it's
expected the user already has loglvl=all set).
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 81 ++-
1 file changed, 41 insertions(+), 40 deletions(-)
diff --git
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index b3607b1bce..c44e7f2299 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++
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
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:
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/include/asm-x86/mem_sharing.h | 8 +++-
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git
No functional changes.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/hvm/hvm.c| 11 +-
xen/arch/x86/mm/mem_sharing.c | 342 +-
xen/arch/x86/mm/p2m.c | 17 +-
xen/include/asm-x86/mem_sharing.h | 51 +++--
4 files changed, 236
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 main design goal with this
No functional changes.
Signed-off-by: Tamas K Lengyel
Acked-by: Wei Liu
---
tools/libxc/include/xenctrl.h | 24
tools/libxc/xc_memshr.c | 12 ++--
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h
It's not being called from outside mem_sharing.c
Signed-off-by: Tamas K Lengyel
---
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 1b7b520ccf..fc1d8be1eb 100644
---
Currently the hvm parameters are only accessible via the HVMOP hypercalls. By
exposing hvm_{get/set}_param it will be possible for VM forking to copy the
parameters directly into the clone domain.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/hvm/hvm.c| 169
On Wed, Dec 18, 2019 at 04:09:25PM +, Paul Durrant wrote:
> ...for patches not (yet) upstream.
>
> This patch is simply reserving save record number space to avoid the
> risk of clashes between existent downstream changes made by Amazon and
> future upstream changes which may be incompatible.
On 18/12/2019 18:00, Juergen Gross wrote:
> Dear community members,
>
> I'm pleased to announce that Xen 4.13.0 is released.
>
> Thanks everyone who contributed to this release. This release would
> not have happened without all the awesome contributions from around
> the globe.
>
> Regards,
>
From: SeongJae Park
The number of empty lines between functions in the xenbus.c is
inconsistent. This trivial style cleanup commit fixes the file to
consistently place only one empty line.
Acked-by: Roger Pau Monné
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/xenbus.c | 7
From: SeongJae Park
A few of static variables in blkback have 'xen_blkif_' prefix, though it
is unnecessary for static variables. This commit removes such prefixes.
Reviewed-by: Roger Pau Monné
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/blkback.c | 37
Granting pages consumes backend system memory. In systems configured
with insufficient spare memory for those pages, it can cause a memory
pressure situation. However, finding the optimal amount of the spare
memory is challenging for large systems having dynamic resource
utilization patterns.
From: SeongJae Park
Granting pages consumes backend system memory. In systems configured
with insufficient spare memory for those pages, it can cause a memory
pressure situation. However, finding the optimal amount of the spare
memory is challenging for large systems having dynamic resource
From: SeongJae Park
A few of static variables in blkback have 'xen_blkif_' prefix, though it
is unnecessary for static variables. This commit removes such prefixes.
Reviewed-by: Roger Pau Monné
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/blkback.c | 37
From: SeongJae Park
Each `blkif` has a free pages pool for the grant mapping. The size of
the pool starts from zero and is increased on demand while processing
the I/O requests. If current I/O requests handling is finished or 100
milliseconds has passed since last I/O requests handling, it
From: SeongJae Park
A driver's 'reclaim_memory' callback can race with 'probe' or 'remove'
because it will be called whenever memory pressure is detected. To
avoid such race, this commit embeds a spinlock in each 'xenbus_device'
and make 'xenbus' to hold the lock while the corresponded
flight 144934 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144934/
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 144925 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144925/
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
On Wed, 18 Dec 2019 16:11:51 +0100 "Jürgen Groß" wrote:
> On 18.12.19 15:40, SeongJae Park wrote:
> > On Wed, 18 Dec 2019 14:30:44 +0100 "Jürgen Groß" wrote:
> >
> >> On 18.12.19 13:42, SeongJae Park wrote:
> >>> On Wed, 18 Dec 2019 13:27:37 +0100 "Jürgen Groß" wrote:
> >>>
> On 18.12.19
Hi,
On Wed, Dec 18, 2019 at 4:56 AM Julien Grall wrote:
> > So that is, in fact, my first question -- why is Xen not showing
> > available memory in xl info?
>
> I am not entirely sure what exact information you want.
>
> The output you dumped above contain the available memory for the memory
>
On 18/12/2019, 14:29, "Julien Grall" wrote:
Hi Lars,
On 12/12/2019 21:14, Lars Kurth wrote:
> +### Workflow from an Author's Perspective
> +
> +When code authors receive feedback on their patches, they typically
first try
> +to clarify feedback they do not
On Wed, Dec 18, 2019 at 3:50 AM Julien Grall wrote:
>
> Hi,
>
> On 18/12/2019 07:36, Roman Shaposhnik wrote:
> > On Tue, Dec 17, 2019 at 6:56 PM Roman Shaposhnik wrote:
> >> Exactly! That's the other surprising bit -- I noticed that too -- its not
> >> like
> >> Xen doesn't see any of the
Dear community members,
I'm pleased to announce that Xen 4.13.0 is released.
Please find the tarball and its signature at:
https://downloads.xenproject.org/release/xen/4.13.0/
You can also check out the tag in xen.git:
https://xenbits.xen.org/git-http/xen.git RELEASE-4.13.0
Git checkout
On 12/18/19 12:36 AM, Roman Shaposhnik wrote:
On Wed, Dec 11, 2019 at 12:41 AM Jan Beulich wrote:
On 11.12.2019 09:16, Jürgen Groß wrote:
On 11.12.19 08:28, Jan Beulich wrote:
Jürgen, Boris,
I've noticed
<6>clocksource: Switched to clocksource tsc
as the final clocksource related boot
...for patches not (yet) upstream.
This patch is simply reserving save record number space to avoid the
risk of clashes between existent downstream changes made by Amazon and
future upstream changes which may be incompatible.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
flight 144924 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144924/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 144905
Steven Haigh writes ("[PATCH] [tools/hotplug] Use ip on systems where brctl is
not available"):
> Newer distros like CentOS 8 do not have brctl available. As such, we
> can't use it to configure networking anymore.
>
> This patch will fall back to 'ip' or 'bridge' commands if brctl is not
>
On 18/12/2019, 13:50, "Andrew Cooper" wrote:
This file hasn't been touched since it was introduced in 2005 (c/s
0c6f36628)
and has a wildly obsolete shebang for Python 2.3. Most importantly for us
is
that it isn't Python 3 compatible.
Drop the file entirely. Since the
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 18 December 2019 14:43
> To: Xen Development List
> Cc: Michael Kelley ; Durrant, Paul
> ; Wei Liu ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Roger Pau Monné
> Subject: [PATCH v2 6/6] x86: implement Hyper-V clock
On 18.12.19 15:40, SeongJae Park wrote:
On Wed, 18 Dec 2019 14:30:44 +0100 "Jürgen Groß" wrote:
On 18.12.19 13:42, SeongJae Park wrote:
On Wed, 18 Dec 2019 13:27:37 +0100 "Jürgen Groß" wrote:
On 18.12.19 11:42, SeongJae Park wrote:
From: SeongJae Park
'reclaim_memory' callback can race
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 18 December 2019 14:43
> To: Xen Development List
> Cc: Michael Kelley ; Durrant, Paul
> ; Wei Liu ; Paul Durrant
> ; Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: [PATCH v2 4/6] x86/viridian:
convert-legacy-stream is only used for incomming migration from pre Xen 4.7,
and verify-stream-v2 appears to only be used by me during migration
development - it is little surprise that they missed the main converstion
effort in Xen 4.13.
Fix it all up.
Move open_file_or_fd() into a new util.py
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 18 December 2019 14:43
> To: Xen Development List
> Cc: Michael Kelley ; Durrant, Paul
> ; Wei Liu ; Paul Durrant
> ; Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: [PATCH v2 3/6] x86/viridian:
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 18 December 2019 14:42
> To: Xen Development List
> Cc: Michael Kelley ; Durrant, Paul
> ; Wei Liu ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Roger Pau Monné
> Subject: [PATCH v2 1/6] x86: import hyperv-tlfs.h from
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 18 December 2019 14:42
> To: Xen Development List
> Cc: Michael Kelley ; Durrant, Paul
> ; Wei Liu ; Paul Durrant
> ; Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: [PATCH v2 2/6] x86/viridian:
On Wed, Dec 18, 2019 at 01:50:06PM +, Andrew Cooper wrote:
> This file hasn't been touched since it was introduced in 2005 (c/s 0c6f36628)
> and has a wildly obsolete shebang for Python 2.3. Most importantly for us is
> that it isn't Python 3 compatible.
>
> Drop the file entirely. Since
Use hyperv-tlfs.h instead. No functional change intended.
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/viridian/synic.c | 68 ---
1 file changed, 16 insertions(+), 52 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
Implement a clock source using Hyper-V's reference TSC page.
Signed-off-by: Wei Liu
---
v2:
1. Address Jan's comments.
Relevant spec:
https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/live/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0C.pdf
Section 12.6.
---
Use the one defined in hyperv-tlfs.h instead. No functional change
intended.
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/viridian/time.c | 30 +++---
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/time.c
Hi all
This series adds a clock source based on Hyper-V's reference TSC. The
meat is in the last patch. I also put in some clean up patches to Xen's
viridian code per Paul's request.
With this series, Xen on Hyper-V no longer runs on emulated PIT.
(XEN) Platform timer is 2294.686MHz HYPER-V
Take a pristine copy from Linux commit b2d8b167e15bb5ec2691d1119c025630a247f649.
Do the following to fix it up for Xen:
1. include xen/types.h and xen/bitops.h
2. fix up invocations of BIT macro
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
xen/include/asm-x86/guest/hyperv-tlfs.h | 907
No functional change intended.
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/viridian/private.h | 66
xen/arch/x86/hvm/viridian/viridian.c | 23 +++---
2 files changed, 6 insertions(+), 83 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/private.h
Provide a structure to store that information. The structure will be
accessed from other places later so make it public.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
xen/arch/x86/guest/hyperv/hyperv.c | 17 +
xen/include/asm-x86/guest/hyperv.h | 12
2 files
The emulated RTC is synchronized with the PV wallclock; any write to the
RTC will update struct domain's 'time_offset_seconds' field and call
update_domain_wallclock().
However, the value of 'time_offset_seconds' is not preserved in any save
record and indeed, when the RTC save record is loaded,
flight 144927 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144927/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 01b6090b75922bc72604c334bd3dc331490af3bb
baseline version:
ovmf
On Wed, 18 Dec 2019 14:30:44 +0100 "Jürgen Groß" wrote:
> On 18.12.19 13:42, SeongJae Park wrote:
> > On Wed, 18 Dec 2019 13:27:37 +0100 "Jürgen Groß" wrote:
> >
> >> On 18.12.19 11:42, SeongJae Park wrote:
> >>> From: SeongJae Park
> >>>
> >>> 'reclaim_memory' callback can race with a driver
Hi Lars,
On 12/12/2019 21:14, Lars Kurth wrote:
+### Workflow from an Author's Perspective
+
+When code authors receive feedback on their patches, they typically first try
+to clarify feedback they do not understand. For smaller patches or patch series
+it makes sense to wait until receiving
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 the TimerValue view of the timers are
signed in standard two's complement form. When writing to the TimerValue
Do you mean CompareValue register
Hi Jeff,
On 11/12/2019 21:13, Jeff Kubascik wrote:
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"
flight 144931 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144931/
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
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index aa54c86325..cb577a7ba9 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -110,6 +110,11 @@
> * interrupt pending after resuming the VCPU.
> */
> #define
On Wed, 2019-12-18 at 08:48 +0100, Juergen Gross wrote:
> Make use of the const qualifier more often in scheduling code.
>
> Signed-off-by: Juergen Gross
>
Cool!
Reviewed-by: Dario Faggioli
Another thing that it may be worth checking is whether all the places
where 'int' is used for CPUs and
Hi all,
now that 4.13 is out of the way I wanted to get the CoC discussion closed - see
https://lists.xenproject.org/archives/html/xen-devel/2019-12/threads.html#00926,
which means I need ACKs or final suggestions. The next step would be to
publish it on the website.
However, I have also been
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, it is possible to receive multiple _pirq_guest_unbind
This file hasn't been touched since it was introduced in 2005 (c/s 0c6f36628)
and has a wildly obsolete shebang for Python 2.3. Most importantly for us is
that it isn't Python 3 compatible.
Drop the file entirely. Since the 2.3 days, automatic discovery of tests has
been included in standard
On Wed, Dec 18, 2019 at 02:24:33PM +0100, Jan Beulich wrote:
> On 18.12.2019 14:18, Wei Liu wrote:
> > On Wed, Dec 18, 2019 at 01:51:54PM +0100, Jan Beulich wrote:
> >> On 18.12.2019 13:38, Wei Liu wrote:
> >>> On Tue, Dec 10, 2019 at 05:59:04PM +0100, Jan Beulich wrote:
> On 25.10.2019
1 - 100 of 175 matches
Mail list logo
