On Fri, Jan 17, 2020 at 08:17:10AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 17.01.20 um 00:59 schrieb Daniel Vetter:
> > On Thu, Jan 16, 2020 at 05:22:34PM +, Emil Velikov wrote:
> >> Hi all,
> >>
> >> On Thu, 16 Jan 2020 at 07:37, Thomas Zimmermann
> >> wrote:
> >>
> diff --git a/dr
Hi
Am 22.01.20 um 09:11 schrieb Daniel Vetter:
> On Fri, Jan 17, 2020 at 08:17:10AM +0100, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 17.01.20 um 00:59 schrieb Daniel Vetter:
>>> On Thu, Jan 16, 2020 at 05:22:34PM +, Emil Velikov wrote:
Hi all,
On Thu, 16 Jan 2020 at 07:37, Thomas
On 22.01.2020 06:57, Wei Xu wrote:
> On 2020/1/21 19:02, Jan Beulich wrote:
>> On 21.01.2020 10:49, Wei Xu wrote:
>>> --- a/xen/drivers/acpi/osl.c
>>> +++ b/xen/drivers/acpi/osl.c
>>> @@ -114,6 +114,8 @@ void acpi_os_unmap_memory(void __iomem * virt,
>>> acpi_size size)
>>> return;
>>>
On Mon, Jan 20, 2020 at 01:20:48PM +0100, Thomas Zimmermann wrote:
> The new interface drm_crtc_has_vblank() return true if vblanking has
> been initialized for a certain CRTC, or false otherwise. This function
> will be useful for initializing CRTC state.
>
> Signed-off-by: Thomas Zimmermann
> -
On Mon, Jan 20, 2020 at 01:20:49PM +0100, Thomas Zimmermann wrote:
> At the end of a commit, atomic helpers can generate a VBLANK event
> automatically. Originally implemented for writeback connectors, the
> functionality can be used by any driver and/or hardware without proper
> VBLANK interrupt.
Hi
Am 22.01.20 um 09:31 schrieb Daniel Vetter:
> On Mon, Jan 20, 2020 at 01:20:48PM +0100, Thomas Zimmermann wrote:
>> The new interface drm_crtc_has_vblank() return true if vblanking has
>> been initialized for a certain CRTC, or false otherwise. This function
>> will be useful for initializing C
Expanding on the previous WIP patch set.
As before, reserve a contiguous region of memory which can be safely
used by the boot allocator in the new Xen, before the live update data
stream has been processed and thus before the locations of all the
other pages which contain live domain data are kno
From: David Woodhouse
---
xen/common/lu/restore.c | 7 +++
xen/common/lu/stream.c | 2 ++
xen/common/page_alloc.c | 6 ++
3 files changed, 15 insertions(+)
diff --git a/xen/common/lu/restore.c b/xen/common/lu/restore.c
index 7f40513ef9..fa168bdac1 100644
--- a/xen/common/lu/restore.c
+
From: David Woodhouse
This allows kexec userspace to tell the next Xen where the range is,
on its command line.
Signed-off-by: David Woodhouse
---
xen/arch/x86/machine_kexec.c | 13 ++---
xen/arch/x86/setup.c | 2 +-
xen/include/public/kexec.h | 1 +
3 files changed, 12 ins
From: David Woodhouse
Set 'e' correctly to reflect the location that Xen is actually relocated
to from its default 2MiB location. Not 2MiB below that.
This is only vaguely a bug fix. The "missing" 2MiB would have been used
in the end, and fed to the allocator. It's just that other things don't
g
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/page_alloc.c | 83 +++--
1 file changed, 80 insertions(+), 3 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 20ef25d45a..2a20c12abb 100644
--- a/xen/common/
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/lu/save.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/lu/save.c b/xen/common/lu/save.c
index c767abd8f4..24d727ff47 100644
--- a/xen/common/lu/save.c
+++ b/xen/common/lu/save.c
@@ -7,7 +7,7 @@
From: David Woodhouse
This is identical to the default case... for now.
Signed-off-by: David Woodhouse
---
xen/common/kexec.c | 18 ++
xen/include/public/kexec.h | 12
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/xen/common/kexec.c b/xen/
From: David Woodhouse
This allows a single page-aligned physical address to be written to
the current destination, intended to pass the location of the live
update data stream from one Xen to the next.
Signed-off-by: David Woodhouse
---
xen/arch/x86/x86_64/kexec_reloc.S | 9 -
xen/incl
From: David Woodhouse
We need to promise that we won't use it for anything that will need to
persist across live update. Until we can achieve that (which will build
on of some of the work Hongyan is doing for secret hiding), the easy
answer is just not to add that region to the main heap at all.
From: David Woodhouse
---
xen/common/kexec.c | 6 ++
xen/common/lu/Makefile | 2 +-
xen/common/lu/save.c | 45 ++
xen/include/xen/lu.h | 3 +++
4 files changed, 55 insertions(+), 1 deletion(-)
create mode 100644 xen/common/lu/save.c
diff -
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/kimage.c | 33 +
xen/include/asm-x86/config.h | 2 ++
xen/include/xen/kimage.h | 3 +++
3 files changed, 38 insertions(+)
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
in
From: David Woodhouse
For live update to work, it will need a region of memory that can be
given to the boot allocator while it parses the state information from
the previous Xen and works out which of the other pages of memory it
can consume.
Reserve that like the crashdump region, and accept i
From: David Woodhouse
This mostly just reserves pages, hence the name. The rest of the actual
restoration will happen later, after the heap allocator works.
Signed-off-by: David Woodhouse
---
xen/arch/x86/setup.c| 20 +++
xen/common/lu/Makefile | 2 +-
xen/common/lu/resto
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/Makefile| 1 +
xen/common/lu/Makefile | 1 +
xen/common/lu/stream.c | 108 +
xen/include/xen/lu.h | 12 +
4 files changed, 122 insertions(+)
create mode 100644 xen/common/
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/arch/x86/setup.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 521946dc27..bd65d6bf5d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@
On 21/01/2020, 21:29, "Rich Persaud" wrote:
On Jan 21, 2020, at 15:58, Marek Marczykowski-Górecki
wrote:
>
> On Wed, Jan 15, 2020 at 04:57:29PM -0500, Rich Persaud wrote:
On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki
wrote:
>>> Since we have those generate
On Wed, Jan 22, 2020 at 09:53:42AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 22.01.20 um 09:31 schrieb Daniel Vetter:
> > On Mon, Jan 20, 2020 at 01:20:48PM +0100, Thomas Zimmermann wrote:
> >> The new interface drm_crtc_has_vblank() return true if vblanking has
> >> been initialized for a certa
Hi Jan,
On 2020/1/22 16:24, Jan Beulich wrote:
> On 22.01.2020 06:57, Wei Xu wrote:
>> On 2020/1/21 19:02, Jan Beulich wrote:
>>> On 21.01.2020 10:49, Wei Xu wrote:
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -114,6 +114,8 @@ void acpi_os_unmap_memory(void __iomem *
flight 146375 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146375/
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
Hi
Am 22.01.20 um 10:04 schrieb Daniel Vetter:
> On Wed, Jan 22, 2020 at 09:53:42AM +0100, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 22.01.20 um 09:31 schrieb Daniel Vetter:
>>> On Mon, Jan 20, 2020 at 01:20:48PM +0100, Thomas Zimmermann wrote:
The new interface drm_crtc_has_vblank() return tru
flight 146381 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146381/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen f44a192d22a37dcb9171b95978b43637bc09718d
baseline version:
xen 1eee
On 20/01/2020 10:01, Jan Beulich wrote:
> On 17.01.2020 17:44, Sergey Dyasli wrote:
>> v2 --> v3:
>> - Remove hvmloader filtering
>
> Why? Seeing the prior discussion, how about adding XENVER_denied to
> return the "denied" string, allowing components which want to filter
> to know exactly what to
On 22.01.2020 11:01, Sergey Dyasli wrote:
> On 20/01/2020 10:01, Jan Beulich wrote:
>> On 17.01.2020 17:44, Sergey Dyasli wrote:
>>> v2 --> v3:
>>> - Remove hvmloader filtering
>>
>> Why? Seeing the prior discussion, how about adding XENVER_denied to
>> return the "denied" string, allowing componen
flight 146369 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146369/
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 20/01/2020 08:58, Paul Durrant wrote:
> On Fri, 17 Jan 2020 at 12:59, Sergey Dyasli wrote:
>>
>> From: Ross Lagerwall
>>
>> When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
>> non-power-of-two allocations are not aligned to the next power of 2 of
>> the size. Therefore, h
On 22/01/2020 10:01, Sergey Dyasli wrote:
On 20/01/2020 10:01, Jan Beulich wrote:
On 17.01.2020 17:44, Sergey Dyasli wrote:
v2 --> v3:
- Remove hvmloader filtering
Why? Seeing the prior discussion, how about adding XENVER_denied to
return the "denied" string, allowing components which want
flight 146376 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146376/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
On 21.01.2020 17:57, Roger Pau Monné wrote:
> 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 pr
On 1/17/20 3:57 PM, George Dunlap wrote:
> This is a sketch of functionality suitable for creating a basic
> domain, with a disk and a vif. DomainConfig, DeviceDisk, and
> DeviceNic types are all created using constructor functions, which
> initialize them with libxl's defaults.
>
> DomainCreateN
On Wed, Jan 22, 2020 at 11:27:24AM +0100, Jan Beulich wrote:
> On 21.01.2020 17:57, Roger Pau Monné wrote:
> > 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 2
On 1/22/20 10:14 AM, Julien Grall wrote:
>
>
> On 22/01/2020 10:01, Sergey Dyasli wrote:
>> On 20/01/2020 10:01, Jan Beulich wrote:
>>> On 17.01.2020 17:44, Sergey Dyasli wrote:
v2 --> v3:
- Remove hvmloader filtering
>>>
>>> Why? Seeing the prior discussion, how about adding XENVER_den
On 17/01/2020 14:56, Boris Ostrovsky wrote:
>
>
> On 1/17/20 7:58 AM, Sergey Dyasli wrote:
>> --- a/arch/x86/mm/kasan_init_64.c
>> +++ b/arch/x86/mm/kasan_init_64.c
>> @@ -13,6 +13,9 @@
>> #include
>> #include
>> +#include
>> +#include
>> +
>> #include
>> #include
>> #include
>>
On 22/01/2020 10:14, Julien Grall wrote:
>
>
> On 22/01/2020 10:01, Sergey Dyasli wrote:
>> On 20/01/2020 10:01, Jan Beulich wrote:
>>> On 17.01.2020 17:44, Sergey Dyasli wrote:
v2 --> v3:
- Remove hvmloader filtering
>>>
>>> Why? Seeing the prior discussion, how about adding XENVER_denie
On 22/01/2020 11:19, Sergey Dyasli wrote:
On 22/01/2020 10:14, Julien Grall wrote:
On 22/01/2020 10:01, Sergey Dyasli wrote:
On 20/01/2020 10:01, Jan Beulich wrote:
On 17.01.2020 17:44, Sergey Dyasli wrote:
v2 --> v3:
- Remove hvmloader filtering
Why? Seeing the prior discussion, how ab
> -Original Message-
> From: Tian, Kevin
> Sent: 22 January 2020 03:19
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Nakajima, Jun ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Roger Pau Monné ; George Dunlap
> ; Ian Jackson ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano
> -Original Message-
> From: Juergen Gross
> Sent: 21 January 2020 08:43
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall ; Volodymyr Babchuk
> ; Andrew Cooper ;
> George Dunlap ; Ian Jackson
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Wei Liu
flight 146382 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146382/
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 22/01/2020 10:57, George Dunlap wrote:
> On 1/22/20 10:14 AM, Julien Grall wrote:
>>
>>
>> On 22/01/2020 10:01, Sergey Dyasli wrote:
>>> On 20/01/2020 10:01, Jan Beulich wrote:
On 17.01.2020 17:44, Sergey Dyasli wrote:
> v2 --> v3:
> - Remove hvmloader filtering
Why? Seein
Hi George,
On 22/01/2020 10:57, George Dunlap wrote:
On 1/22/20 10:14 AM, Julien Grall wrote:
On 22/01/2020 10:01, Sergey Dyasli wrote:
On 20/01/2020 10:01, Jan Beulich wrote:
On 17.01.2020 17:44, Sergey Dyasli wrote:
v2 --> v3:
- Remove hvmloader filtering
Why? Seeing the prior discussi
On 22.01.2020 13:05, Julien Grall wrote:
> Hi George,
>
> On 22/01/2020 10:57, George Dunlap wrote:
>> On 1/22/20 10:14 AM, Julien Grall wrote:
>>>
>>>
>>> On 22/01/2020 10:01, Sergey Dyasli wrote:
On 20/01/2020 10:01, Jan Beulich wrote:
> On 17.01.2020 17:44, Sergey Dyasli wrote:
>>
On 19/01/2020 06:17, Kevin Buckley wrote:
> Any clues then, as to whether this is another Python3 hangover for Xen ?
Xen 4.13 (now released) is the first version of Xen with any serious
form Python 3 compatibility (and even then, we missed a few corner cases).
Earlier versions of Xen are simply n
On 19/01/2020 02:09, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Friday, December 20, 2019 11:02 PM
>>
>> On 20.12.2019 15:58, George Dunlap wrote:
>>> On 12/20/19 2:41 PM, Jan Beulich wrote:
On 20.12.2019 15:26, George Dunlap wrote:
> On 12/20/19 2:21 PM, Jan Beulich wrote:
>> I
On 22/01/2020 12:32, Jan Beulich wrote:
On 22.01.2020 13:05, Julien Grall wrote:
Hi George,
On 22/01/2020 10:57, George Dunlap wrote:
On 1/22/20 10:14 AM, Julien Grall wrote:
On 22/01/2020 10:01, Sergey Dyasli wrote:
On 20/01/2020 10:01, Jan Beulich wrote:
On 17.01.2020 17:44, Sergey Dy
On 20/01/2020 14:31, Julien Grall wrote:
> From: Julien Grall
>
> The structure domain may be bigger than a page size when lock profiling
> is enabled. However, the function free_domheap_struct will only free the
> first page.
>
> This is not a security issue because struct domain can only be bigg
On Wed, 2020-01-08 at 16:23 +0100, Juergen Gross wrote:
> Scheduling code has several places using int or bool_t instead of
> bool.
> Switch those.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - rename bool "pos" to "first" (Dario Faggioli)
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
On Wed, 2020-01-08 at 16:23 +0100, Juergen Gross wrote:
> Move sched*c and cpupool.c to a new directory common/sched.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - renamed sources (Dario Faggioli, Andrew Cooper)
>
Reviewed-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/d
On Wed, 2020-01-08 at 16:23 +0100, Juergen Gross wrote:
> Instead of having an own percpu-variable for private data per cpu the
> generic scheduler interface for that purpose should be used.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://a
On Wed, 2020-01-08 at 16:23 +0100, Juergen Gross wrote:
> With the idle scheduler now taking care of all cpus not in any
> cpupool
> the special cases in the other schedulers for no cpupool associated
> can be removed.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Regards
--
D
On Wed, 2020-01-08 at 16:23 +0100, Juergen Gross wrote:
> Move all scheduler related hypervisor code to xen/common/sched/ and
> do a lot of cleanups.
>
> Juergen Gross (9):
> xen/sched: move schedulers and cpupool coding to dedicated
> directory
> xen/sched: make sched-if.h really scheduler pr
Hi Andrew,
On 22/01/2020 12:52, Andrew Cooper wrote:
On 20/01/2020 14:31, Julien Grall wrote:
From: Julien Grall
The structure domain may be bigger than a page size when lock profiling
is enabled. However, the function free_domheap_struct will only free the
first page.
This is not a security
On 22/01/2020 13:13, Julien Grall wrote:
> Hi Andrew,
>
> On 22/01/2020 12:52, Andrew Cooper wrote:
>> On 20/01/2020 14:31, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> The structure domain may be bigger than a page size when lock profiling
>>> is enabled. However, the function free_domheap_
On Wed, 2020-01-22 at 13:15 +, Andrew Cooper wrote:
> > > I'd much rather see the original patch reverted. The current size of
> > > struct domain with lockprofile enabled is 3200 bytes.
> >
> > Let me have a look first to see when/why struct domain is less than 4K
> > with lockprofile.
>
>
On Tue, Jan 21, 2020 at 4:08 PM Marek Marczykowski-Górecki
wrote:
>
> On Mon, Jan 20, 2020 at 01:54:04PM -0500, Jason Andryuk wrote:
> > On Tue, Jan 14, 2020 at 9:41 PM Marek Marczykowski-Górecki
> > wrote:
> >
> >
> >
> > > +
> > > +Limitations:
> > > + - PCI passthrough require permissive mode
On Wed, Jan 22, 2020 at 5:52 AM Roger Pau Monné wrote:
>
> On Wed, Jan 22, 2020 at 11:27:24AM +0100, Jan Beulich wrote:
> > On 21.01.2020 17:57, Roger Pau Monné wrote:
> > > On Tue, Jan 21, 2020 at 05:15:20PM +0100, Jan Beulich wrote:
> > >> On 21.01.2020 16:57, Roger Pau Monné wrote:
> > >>> On T
On Wed, Jan 22, 2020 at 10:07:35AM +, Sergey Dyasli wrote:
> On 20/01/2020 08:58, Paul Durrant wrote:
> > On Fri, 17 Jan 2020 at 12:59, Sergey Dyasli
> > wrote:
> >>
> >> From: Ross Lagerwall
> >>
> >> When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
> >> non-power-of-t
On 21/01/2020 12:00, Paul Durrant wrote:
> 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
I'm afraid this breaks the idempotency of vmx_free_vlapic_mapping(),
w
On Tue, Jan 07, 2020 at 12:19:36PM +, Wei Liu wrote:
> On Mon, Jan 06, 2020 at 05:03:52PM +, Andrew Cooper wrote:
> > XCFLAGS_CHECKPOINT_COMPRESS has been unused since c/s b15bc4345 (2015),
> > XCFLAGS_HVM since c/s 9e8672f1c (2013), and XCFLAGS_STDVGA since c/s
> > 087d43326 (2007). Drop
On 22.01.2020 11:51, Roger Pau Monné wrote:
> On Wed, Jan 22, 2020 at 11:27:24AM +0100, Jan Beulich wrote:
>> On 21.01.2020 17:57, Roger Pau Monné wrote:
>>> The PCI spec actually recommends memory BARs to be at least of page
>>> size, but that's not a strict requirement. I would hope there aren't
On 22/01/2020 14:08, Wei Liu wrote:
> On Tue, Jan 07, 2020 at 12:19:36PM +, Wei Liu wrote:
>> On Mon, Jan 06, 2020 at 05:03:52PM +, Andrew Cooper wrote:
>>> XCFLAGS_CHECKPOINT_COMPRESS has been unused since c/s b15bc4345 (2015),
>>> XCFLAGS_HVM since c/s 9e8672f1c (2013), and XCFLAGS_STDVGA
On 22.01.2020 15:04, Jason Andryuk wrote:
> On Wed, Jan 22, 2020 at 5:52 AM Roger Pau Monné wrote:
>> On Wed, Jan 22, 2020 at 11:27:24AM +0100, Jan Beulich wrote:
>>> On 21.01.2020 17:57, Roger Pau Monné wrote:
Ie: Xen should refuse to pass through any memory BAR that's not page
aligned.
flight 146387 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146387/
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
Hi David,
On 22/01/2020 13:50, Woodhouse, David wrote:
On Wed, 2020-01-22 at 13:15 +, Andrew Cooper wrote:
I'd much rather see the original patch reverted. The current size of
struct domain with lockprofile enabled is 3200 bytes.
Let me have a look first to see when/why struct domain is
On Tue, Jan 21, 2020 at 4:18 PM Marek Marczykowski-Górecki
wrote:
>
> On Mon, Jan 20, 2020 at 02:24:18PM -0500, Jason Andryuk wrote:
> > On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki
> > wrote:
> > >
> > > From: Eric Shelton
> > >
> > > This patch creates an appropriate command line
On Tue, Jan 21, 2020 at 4:19 PM Marek Marczykowski-Górecki
wrote:
>
> On Mon, Jan 20, 2020 at 02:36:08PM -0500, Jason Andryuk wrote:
> > On Tue, Jan 14, 2020 at 9:41 PM Marek Marczykowski-Górecki
> > wrote:
> > >
> > > This allows using arguments with spaces, like -append, without
> > > nominatin
On Tue, Jan 21, 2020 at 4:22 PM Marek Marczykowski-Górecki
wrote:
>
> On Mon, Jan 20, 2020 at 02:41:07PM -0500, Jason Andryuk wrote:
> > On Tue, Jan 14, 2020 at 9:40 PM Marek Marczykowski-Górecki
> > wrote:
> > >
> > > Signed-off-by: Marek Marczykowski-Górecki
> > >
> > > Reviewed-by: Jason And
All callers set the respective fields in the entry being updated before
the call.
Take the opportunity and also constify the first parameter as well as
make a few style adjustments.
Signed-off-by: Jan Beulich
---
v2: Drop redundant function parameters instead.
--- a/xen/arch/x86/mm/p2m-ept.c
++
On Tue, Jan 21, 2020 at 4:28 PM Marek Marczykowski-Górecki
wrote:
>
> On Mon, Jan 20, 2020 at 02:44:58PM -0500, Jason Andryuk wrote:
> > On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki
> > wrote:
> > >
> > > Let the server know when the client is connected. Otherwise server will
> > >
This function implements a file-based lock with a file name generated
from a domid.
This patch splits it into two, generalising the core of the locking code
into a new libxl__lock_file() function which operates on a specified file,
leaving just the file name generation in libxl__domain_userdata_lo
Currently both xl and libxl have internal definitions of INVALID_DOMID
which happen to be identical. However, for the purposes of describing the
behaviour of libxl_domain_create_new/restore() it is useful to have a
specified invalid value for a domain id.
This patch therefore moves the libxl defin
A domid is considered recent if the domain it represents was destroyed
less than a specified number of seconds ago. The number can be set using
the environment variable LIBXL_DOMID_REUSE_TIMEOUT. If the variable does
not exist then a default value of 60s is used.
Whenever a domain is destroyed, a
The 'soft reset' code path in libxl__domain_make() is currently taken if a
valid domid is passed into the function. A subsequent patch will enable
higher levels of the toolstack to determine the domid of newly created or
restored domains and therefore this criteria for choosing 'soft reset'
will no
This series was previously named "xl/libxl: allow creation of domains with
a specified domid".
Paul Durrant (7):
libxl: add definition of INVALID_DOMID to the API
libxl_create: make 'soft reset' explicit
libxl: generalise libxl__domain_userdata_lock()
libxl: add infrastructure to track and
This patch adds a '-D' command line option to save and migrate to allow
the domain id to be incorporated into the saved domain configuration and
hence be preserved.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Anthony PERARD
v2:
- Heavily re-worked based on new libxl_domai
This patch adds a new global 'domid_policy' configuration option to decide
how domain id values are allocated for new domains. It may be set to one of
two values:
"xen", the default value, will cause an invalid domid value to be passed
to do_domain_create() preserving the existing behaviour of hav
This patch adds a 'domid' field to libxl_domain_create_info and then
modifies libxl__domain_make() to have Xen use that value if it is valid.
If the domid value is invalid then Xen will choose the domid, as before,
unless the value is the new special RANDOM_DOMID value added to the API.
This value
On Wed, Jan 22, 2020 at 02:44:40PM +, Paul Durrant wrote:
> Currently both xl and libxl have internal definitions of INVALID_DOMID
> which happen to be identical. However, for the purposes of describing the
> behaviour of libxl_domain_create_new/restore() it is useful to have a
> specified inva
On 22/01/2020 01:58, Bobby Eshleman wrote:
> Hey everybody,
>
> This is an RFC patchset for the very beginnings of adding RISC-V support
> to Xen. This RFC is really just to start a dialogue about supporting
> RISC-V and align with the Xen project and community before going
> further. For that re
On 21.01.2020 18:49, Tamas K Lengyel wrote:
> 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.
>
> Sign
On 21.01.2020 18:49, Tamas K Lengyel wrote:
> The owner domain of shared pages is dom_cow, use that for get_page
> otherwise the function fails to return the correct page.
I think this description needs improvement: The function does the
special shared page dance in one place (on the "fast path")
On 21.01.2020 18:49, Tamas K Lengyel wrote:
> @@ -538,24 +535,26 @@ static int audit(void)
> d = get_domain_by_id(g->domain);
> if ( d == NULL )
> {
> -MEM_SHARING_DEBUG("Unknown dom: %hu, for PFN=%lx, MFN=%lx\n",
> -
On 21.01.2020 18:49, Tamas K Lengyel wrote:
> 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 Lengye
On 21.01.2020 18:49, Tamas K Lengyel wrote:
> When plugging a hole in the target physmap don't use the access permission
> returned by __get_gfn_type_access as it can be non-sensical,
"can be" is too vague for my taste - it suggests there may also be cases
where a sensible value is returned, and h
On 20/01/2020 10:46, Jan Beulich wrote:
> On 17.01.2020 21:42, Andrew Cooper wrote:
>> For __page_tables_{start,end} and L3 bootmap initialisation, the logic is
>> unnecesserily complicated owing to its attempt to use the LOOP instruction,
>> which results in an off-by-8 memory address owing to LOO
On 22.01.2020 15:05, Andrew Cooper wrote:
> On 21/01/2020 12:00, Paul Durrant wrote:
>> 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
>
> I'm afraid this br
On 21.01.2020 13:00, Paul Durrant wrote:
> 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 defin
> -Original Message-
> From: Jan Beulich
> Sent: 22 January 2020 15:51
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; Jun Nakajima ; Kevin Tian
>
> Subject: Re: [PATCH 2/3] x86 / hvm: add domain_relinquish_resources()
> method
>
On 22.01.2020 16:56, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 22 January 2020 15:51
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Wei Liu ; Roger Pau Monné
>> ; Jun Nakajima ; Kevin Tian
>>
>> Subject: Re: [PATCH 2/3] x86 /
> -Original Message-
> From: Jan Beulich
> Sent: 22 January 2020 16:01
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; Jun Nakajima ; Kevin Tian
>
> Subject: Re: [PATCH 2/3] x86 / hvm: add domain_relinquish_resources()
> method
>
On 21.01.2020 13:00, Paul Durrant wrote:
> 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
> -Original Message-
> From: Jan Beulich
> Sent: 22 January 2020 16:17
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Jun Nakajima ;
> Kevin Tian ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George Dunlap ; Ian
> Jackson ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano S
> On 22 Jan 2020, at 14:57, Andrew Cooper wrote:
>
> On 22/01/2020 01:58, Bobby Eshleman wrote:
>> Hey everybody,
>>
>> This is an RFC patchset for the very beginnings of adding RISC-V support
>> to Xen. This RFC is really just to start a dialogue about supporting
>> RISC-V and align with the
flight 146379 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146379/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 146058
test-amd64-amd64-x
On Wed, Jan 22, 2020 at 8:01 AM Jan Beulich wrote:
>
> On 21.01.2020 18:49, Tamas K Lengyel wrote:
> > 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 i
On 21.01.2020 09: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.
>
> Signed-off-by: Juergen Gross
x86:
Acked-by: Jan Beulich
1 - 100 of 152 matches
Mail list logo
