flight 146168 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146168/
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
Hi,
At 12:16 +0100 on 15 Jan (1579090561), Roger Pau Monné wrote:
> - Shadow: it's not clear to me exactly which parts of sh_update_cr3
>are needed in order to perform a guest TLB flush. I think calling:
>
> #if (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB)
> /* No longer safe to use
At 15:29 -0500 on 16 Jan (1579188566), Jason Andryuk wrote:
> This is the corresponding change to the shadow code as made by
> bf08a8a08a2e "x86/HVM: use single (atomic) MOV for aligned emulated
> writes" to the non-shadow HVM code.
>
> The bf08a8a08a2e commit message:
> Using memcpy() may result
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/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
flight 146160 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146160/
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
flight 146156 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146156/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
145969
Tests which did
flight 146139 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146139/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 144758
build-i386
Parse the ACPI SPCR table and initialize the 16550 compatible
serial port.
Signed-off-by: Wei Xu
---
xen/drivers/char/ns16550.c | 55 ++
1 file changed, 55 insertions(+)
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 146121 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146121/
Failures :-/ but
flight 146119 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146119/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 146058
build-i386
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/drivers/gpu/drm/drm_atomic_state_helper.c
> > > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > index 7cf3cf936547..23d2f51fc1d4 100644
> >
On Wed, 15 Jan 2020, Julien Grall wrote:
> On 14/01/2020 21:39, Jorge Pereira wrote:
> > Hi Guys,
>
> Hello,
>
> >
> > I’m currently using XEN in order to run side-by-side a DOM-0 with a DOM-U
> > guest. My use-case scenario requires in the DOM-U direct access to some
> > dma-capable devices
flight 146174 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146174/
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
Since commit c61c1b4943 "xen/page_alloc: statically allocate
bootmem_region_list", the boot allocator does not use the first page of
the first region passed for its own purpose.
This reverts commit ae84f55353475f569daddb9a81ac0a6bc7772c90.
Signed-off-by: Julien Grall
---
xen/arch/arm/setup.c |
Hello Julien,
On 1/16/2020 4:25 PM, Julien Grall wrote:
> Hi Jeff,
>
> Do you plan to resend the series? If not, I am happy to respin the
> series for you.
Feel free! Unfortunately, I currently don't have the bandwidth to keep this
patch moving along.
> Best regards,
>
> On 11/12/2019 21:13,
Hi Jeff,
Do you plan to resend the series? If not, I am happy to respin the
series for you.
Best regards,
On 11/12/2019 21:13, Jeff Kubascik wrote:
This patch set improves the emulation of the physical timer by removing the
physical timer offset and sign extend the TimerValue to better
This is the corresponding change to the shadow code as made by
bf08a8a08a2e "x86/HVM: use single (atomic) MOV for aligned emulated
writes" to the non-shadow HVM code.
The bf08a8a08a2e commit message:
Using memcpy() may result in multiple individual byte accesses
(depending how memcpy() is
On 13/01/2020 16:46, Jan Beulich wrote:
> On 13.01.2020 17:02, Andrew Cooper wrote:
>> My recent boot pagetable changes have caused me to work with the EFI
>> build of Xen rather more than previously.
>>
>> First, there is a dependency tracking bug in the build system. Edits to
>>
flight 146169 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146169/
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
On Tue, Jan 14, 2020 at 1:16 PM Roger Pau Monne wrote:
>
> When placing BARs with sizes smaller than 4K multiple BARs can end
> up mapped to the same guest physical address, and thus won't work
> correctly.
>
> Align all BARs placement to 4K in hvmloader to prevent such
> overlapping.
>
> Note
On 15/01/2020 09:23, Jan Beulich wrote:
> On 14.01.2020 20:31, Andrew Cooper wrote:
>> On 14/01/2020 16:45, Jan Beulich wrote:
>>> On 13.01.2020 18:50, Andrew Cooper wrote:
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -668,6 +668,20 @@ trampoline_setup:
On 1/16/20 12:00 PM, Juergen Gross wrote:
Commit 3aa6c19d2f38be ("xen/balloon: Support xend-based toolstack")
tried to fix a regression with running on rather ancient Xen versions.
Unfortunately the fix was based on the assumption that xend would
just use another Xenstore node, but in reality
On 07/01/2020 16:17, Wei Liu wrote:
> On Sun, Jan 05, 2020 at 10:06:08PM +, Andrew Cooper wrote:
>> On 05/01/2020 21:22, Wei Liu wrote:
>>> On Sun, Jan 05, 2020 at 07:08:28PM +, Andrew Cooper wrote:
> +static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t input,
>
On 14/01/2020 16:12, Jan Beulich wrote:
> On 14.01.2020 17:00, Jürgen Groß wrote:
>> On 14.01.20 16:47, Jan Beulich wrote:
>>> On 09.01.2020 14:48, Juergen Gross wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -81,6 +81,12 @@ config PERF_ARRAYS
---help---
xl is maintained in practice by the libxl maintainers. The effect is
simply to grant maintainership to Anthony.
CC: Wei Liu
CC: Anthony PERARD
Signed-off-by: Ian Jackson
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d5edfc142a..952bcd387a
Paul Durrant writes ("[PATCH v3 0/6] xl/libxl: domid allocation/preservation
changes"):
> This series was previously named "xl/libxl: allow creation of domains with
> a specified domid".
Thanks. I think Anthony ought to have been made a maintainer of
tools/xl at the same time as of tools/libxl.
Paul Durrant writes ("[PATCH v3 6/6] xl: allow domid to be preserved on
save/restore or migrate"):
> 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.
I wonder if this should be
Paul Durrant writes ("[PATCH v3 5/6] xl.conf: introduce 'domid_policy'"):
> 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
Hi. This broadly contains what I expected, but:
Paul Durrant writes ("[PATCH v3 4/6] libxl: allow creation of domains with a
specified or random domid"):
> +for (;;) {
> +if (info->domid == RANDOM_DOMID) {
> +uint16_t v;
> +
> +/* Randomize
Thanks. I think this is the algorithm as we discussed, thanks.
I have some comments about the implementation...
Paul Durrant writes ("[PATCH v3 3/6] libxl: add infrastructure to track and
query 'retired' domids"):
> A domid is considered retired if the domain it represents was destroyed
> less
From: Dan Carpenter
[ Upstream commit 201676095dda7e5b31a5e1d116d10fc22985075e ]
The "cpu" variable comes from the sscanf() so Smatch marks it as
untrusted data. We can't pass a higher value than "nr_cpu_ids" to
cpu_possible() or it results in an out of bounds access.
Fixes: d68d82afd4c8
From: Dan Carpenter
[ Upstream commit 201676095dda7e5b31a5e1d116d10fc22985075e ]
The "cpu" variable comes from the sscanf() so Smatch marks it as
untrusted data. We can't pass a higher value than "nr_cpu_ids" to
cpu_possible() or it results in an out of bounds access.
Fixes: d68d82afd4c8
From: Eric Dumazet
[ Upstream commit 60b173ca3d1cd1782bd0096dc17298ec242f6fb1 ]
reqsk_queue_empty() is called from inet_csk_listen_poll() while
other cpus might write ->rskq_accept_head value.
Use {READ|WRITE}_ONCE() to avoid compiler tricks
and potential KCSAN splats.
Fixes: fff1f3001cc5
flight 146106 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146106/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-build fail in 146079 REGR. vs. 145145
From: Dan Carpenter
[ Upstream commit 201676095dda7e5b31a5e1d116d10fc22985075e ]
The "cpu" variable comes from the sscanf() so Smatch marks it as
untrusted data. We can't pass a higher value than "nr_cpu_ids" to
cpu_possible() or it results in an out of bounds access.
Fixes: d68d82afd4c8
Hi all,
On Thu, 16 Jan 2020 at 07:37, Thomas Zimmermann wrote:
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 7cf3cf936547..23d2f51fc1d4 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++
From: Eric Dumazet
[ Upstream commit 60b173ca3d1cd1782bd0096dc17298ec242f6fb1 ]
reqsk_queue_empty() is called from inet_csk_listen_poll() while
other cpus might write ->rskq_accept_head value.
Use {READ|WRITE}_ONCE() to avoid compiler tricks
and potential KCSAN splats.
Fixes: fff1f3001cc5
On Wed, Jan 15, 2020 at 12:02:42PM +0100, Jan Beulich wrote:
> On 15.01.2020 03:39, Marek Marczykowski-Górecki wrote:
> > .gitignore | 1 +-
>
> I guess this is why various non-tool-stack maintainers have
> been Cc-ed. It would have been nice if you had stripped the
>
From: Dan Carpenter
[ Upstream commit 201676095dda7e5b31a5e1d116d10fc22985075e ]
The "cpu" variable comes from the sscanf() so Smatch marks it as
untrusted data. We can't pass a higher value than "nr_cpu_ids" to
cpu_possible() or it results in an out of bounds access.
Fixes: d68d82afd4c8
From: Oleksandr Andrushchenko
[ Upstream commit 24ded292a5c2ed476f01c77fee65f8320552cd27 ]
When GEM backing storage is allocated those are normal pages,
so there is no point using pgprot_writecombine while mmaping.
This fixes mismatch of buffer pages' memory attributes between
the frontend and
Commit 3aa6c19d2f38be ("xen/balloon: Support xend-based toolstack")
tried to fix a regression with running on rather ancient Xen versions.
Unfortunately the fix was based on the assumption that xend would
just use another Xenstore node, but in reality only some downstream
versions of xend are
On 1/4/20 7:27 PM, Nick Rosbrook wrote:
> On Fri, Dec 27, 2019 at 11:33 AM George Dunlap
> wrote:
>>
>> Commit 871e51d2d4 changed the sign on the xenlight error types (making
>> the values negative, same as the C-generated constants), but failed to
>> flip the sign in the Error() string
flight 146110 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146110/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
On 1/16/20 4:50 PM, Nick Rosbrook wrote:
>> Looks good! Only one question:
>>
>>> +if not is_castable:
>>> +s += 'if err := x.{}.toC({}); err != nil
>>> {{\n'.format(goname,cname)
>>
>> Err should be defined function-wide at this point. Are you using `:=`
>> on purpose for some
> Looks good! Only one question:
>
> > +if not is_castable:
> > +s += 'if err := x.{}.toC({}); err != nil
> > {{\n'.format(goname,cname)
>
> Err should be defined function-wide at this point. Are you using `:=`
> on purpose for some reason? Would it make sense to make this `=`
On 1/4/20 7:06 PM, Nick Rosbrook wrote:
> On Fri, Dec 27, 2019 at 11:33 AM George Dunlap
> wrote:
>>
>> If an error is encountered deep in a complicated data structure, it's
>> often difficult to tell where the error actually is. Make the error
>> message from the generated toC() and fromC()
On Thu, Jan 16, 2020 at 9:18 AM Jan Beulich wrote:
>
> On 08.01.2020 18:14, 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
On Thu, Jan 16, 2020 at 8:47 AM Jan Beulich wrote:
>
> On 08.01.2020 18:13, Tamas K Lengyel wrote:
> > Tamas K Lengyel (18):
> > x86/hvm: introduce hvm_copy_context_and_params
> > xen/x86: Make hap_get_allocation accessible
> > x86/mem_sharing: make get_two_gfns take locks conditionally
> >
flight 146161 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146161/
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
On 1/4/20 9:00 PM, Nick Rosbrook wrote:
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 08.01.2020 18:14, 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
On 1/4/20 9:00 PM, Nick Rosbrook wrote:
> Since the C union cannot be directly populated, populate the fields of the
> corresponding C struct defined in the cgo preamble, and then copy that
> struct as bytes into the byte slice that Go uses as the union.
>
> Signed-off-by: Nick Rosbrook
On 16/01/2020 16:00, Igor Druzhinin wrote:
> Due to AMD and Hygon being unable to selectively trap CR4 bit modifications
> running 32-bit PV guest inside PV shim comes with significant performance
> hit. Moreover, for SMEP in particular every time CR4.SMEP changes on context
> switch to/from
On Thu, Jan 16, 2020 at 9:07 AM Jan Beulich wrote:
>
> On 08.01.2020 18:14, Tamas K Lengyel wrote:
> > Signed-off-by: Tamas K Lengyel
> > ---
> > xen/arch/x86/mm/mem_sharing.c | 42 +--
> > 1 file changed, 21 insertions(+), 21 deletions(-)
> >
> > diff --git
On 16.01.2020 17:05, Tamas K Lengyel wrote:
> On Thu, Jan 16, 2020 at 8:23 AM Jan Beulich wrote:
>>
>> On 08.01.2020 18:14, Tamas K Lengyel wrote:
>>> Create struct mem_sharing_domain under hvm_domain and move mem sharing
>>> variables into it from p2m_domain and hvm_domain.
>>>
>>> Expose the
On 08.01.2020 18:14, Tamas K Lengyel wrote:
> Signed-off-by: Tamas K Lengyel
> ---
> xen/arch/x86/mm/mem_sharing.c | 42 +--
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index
On Thu, Jan 16, 2020 at 8:23 AM Jan Beulich wrote:
>
> On 08.01.2020 18:14, Tamas K Lengyel wrote:
> > 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
Hi Lars,
On 15/01/2020 18:11, Lars Kurth wrote:
I should have added more people to this change. The issue without this fix is
that entries such as
L: xen-devel
break get_maintainer.pl and thus add_maintainers.pl
Lars
On 10/01/2020, 21:19, "Lars Kurth" wrote:
From: Lars Kurth
On 16.01.2020 16:59, Tamas K Lengyel wrote:
> On Thu, Jan 16, 2020 at 7:55 AM Jan Beulich wrote:
>>
>> On 08.01.2020 18:14, Tamas K Lengyel wrote:
>>> @@ -1702,11 +1703,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
>>> long gla,
>>> struct domain *currd = curr->domain;
>>>
On 08.01.2020 18:14, Tamas K Lengyel wrote:
> @@ -494,19 +491,19 @@ static int audit(void)
> /* If we can't lock it, it's definitely not a shared page */
> if ( !mem_sharing_page_lock(pg) )
> {
> -MEM_SHARING_DEBUG(
> -"mfn %lx in audit list,
On 1/4/20 9:00 PM, Nick Rosbrook wrote:
> Implement conversions for basic types such as strings and integer
> types in toC functions.
>
> Modify function signatures of toC implementations for builtin
> types to be consistent with the signature of the generated toC
> functions.
>
> Signed-off-by:
Due to AMD and Hygon being unable to selectively trap CR4 bit modifications
running 32-bit PV guest inside PV shim comes with significant performance
hit. Moreover, for SMEP in particular every time CR4.SMEP changes on context
switch to/from 32-bit PV guest, it gets trapped by L0 Xen which then
On Thu, Jan 16, 2020 at 7:55 AM Jan Beulich wrote:
>
> On 08.01.2020 18:14, Tamas K Lengyel wrote:
> > @@ -1702,11 +1703,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
> > long gla,
> > struct domain *currd = curr->domain;
> > struct p2m_domain *p2m, *hostp2m;
> > int
On Thu, Jan 16, 2020 at 4:36 AM Paul Durrant wrote:
>
> This patch adds a 'domid' field to libxl_domain_create_info and then
> modifies do_domain_create() to use that value if it is valid. Any valid
> domid will be checked against the retired domid list before being passed
> to
On 08.01.2020 18:13, Tamas K Lengyel wrote:
> Tamas K Lengyel (18):
> x86/hvm: introduce hvm_copy_context_and_params
> xen/x86: Make hap_get_allocation accessible
> x86/mem_sharing: make get_two_gfns take locks conditionally
> x86/mem_sharing: drop flags from mem_sharing_unshare_page
>
On 08.01.2020 18:14, 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
Reviewed-by: Jan Beulich
On 08.01.2020 18:14, Tamas K Lengyel wrote:
> It's not being called from outside mem_sharing.c
>
> Signed-off-by: Tamas K Lengyel
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 08.01.2020 18:14, Tamas K Lengyel wrote:
> 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-devel mailing list
On 08.01.2020 18:14, Tamas K Lengyel wrote:
> 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
On 16.01.2020 16:05, Roger Pau Monné wrote:
> On Thu, Jan 16, 2020 at 11:44:51AM +0100, Jan Beulich wrote:
>> Thinking about it, what about the period of time between a CPU having
>> got physically hot-added (and hence known at the hardware level) and
>> it actually getting brought up for the
On Thu, Jan 16, 2020 at 11:44:51AM +0100, Jan Beulich wrote:
> On 09.01.2020 17:22, Roger Pau Monne wrote:
> > If the IPI destination mask matches the mask of online CPUs use the
> > APIC ALLBUT destination shorthand in order to send an IPI to all CPUs
> > on the system except the current one.
On Sun, Jan 05, 2020 at 07:08:28PM +, Andrew Cooper wrote:
>
> > +static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t input,
> > paddr_t output)
> > +{
> > +uint64_t status;
> > +
> > +asm volatile ("mov %[output], %%r8\n"
> > + "call hv_hypercall_page"
On 08.01.2020 18:14, Tamas K Lengyel wrote:
> @@ -1702,11 +1703,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
> long gla,
> struct domain *currd = curr->domain;
> struct p2m_domain *p2m, *hostp2m;
> int rc, fall_through = 0, paged = 0;
> -int sharing_enomem = 0;
>
On Thu, Jan 16, 2020 at 5:28 AM Jan Beulich wrote:
>
> On 08.01.2020 18:13, Tamas K Lengyel wrote:
> > @@ -4129,49 +4130,32 @@ static int hvm_allow_set_param(struct domain *d,
> > return rc;
> > }
> >
> > -static int hvmop_set_param(
> > -XEN_GUEST_HANDLE_PARAM(xen_hvm_param_t) arg)
> >
On 16/01/2020 09:01, Jan Beulich wrote:
> As of commit 93249f7fc17c ("x86/efi: split compiler vs linker support"),
> EFI support in xen.gz may be available even if no xen.efi gets
> generated. Distinguish the cases when emitting the message.
>
> Also drop the pointlessly (afaict) left use of
On 16/01/2020 09:00, Jan Beulich wrote:
> While it has been me to introduce this, the use of | there has become
> (and perhaps was from the very beginning) misleading. Rather than
> avoiding the right side of it when linking the xen.efi intermediate file
> at a different base address, make the
On 16.01.2020 13:29, Anthony PERARD wrote:
> On Thu, Jan 16, 2020 at 12:30:49PM +0100, Jan Beulich wrote:
>> On 15.01.2020 18:00, Anthony PERARD wrote:
>>> --- a/xen/Kconfig
>>> +++ b/xen/Kconfig
>>> @@ -4,9 +4,25 @@
>>> #
>>> mainmenu "Xen/$(SRCARCH) $(XEN_FULLVERSION) Configuration"
>>>
>>>
flight 146109 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146109/
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 Thu, Jan 16, 2020 at 12:30:49PM +0100, Jan Beulich wrote:
> On 15.01.2020 18:00, Anthony PERARD wrote:
> > --- a/xen/Kconfig
> > +++ b/xen/Kconfig
> > @@ -4,9 +4,25 @@
> > #
> > mainmenu "Xen/$(SRCARCH) $(XEN_FULLVERSION) Configuration"
> >
> > +source "scripts/Kconfig.include"
> > +
> >
On 08.01.2020 18:13, Tamas K Lengyel wrote:
> @@ -4129,49 +4130,32 @@ static int hvm_allow_set_param(struct domain *d,
> return rc;
> }
>
> -static int hvmop_set_param(
> -XEN_GUEST_HANDLE_PARAM(xen_hvm_param_t) arg)
> +static int hvm_set_param(struct domain *d, uint32_t index,
On Thu, Jan 16, 2020 at 12:09:12PM +, Igor Druzhinin wrote:
> On 16/01/2020 09:38, Jan Beulich wrote:
> > On 16.01.2020 10:33, Roger Pau Monné wrote:
> >> On Wed, Jan 15, 2020 at 05:21:16PM +0100, Jan Beulich wrote:
> >>> On 15.01.2020 14:44, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020
On 16/01/2020 09:38, Jan Beulich wrote:
> On 16.01.2020 10:33, Roger Pau Monné wrote:
>> On Wed, Jan 15, 2020 at 05:21:16PM +0100, Jan Beulich wrote:
>>> On 15.01.2020 14:44, Roger Pau Monné wrote:
On Wed, Jan 15, 2020 at 01:49:22PM +0100, Jan Beulich wrote:
> What I'm then worried about
flight 146104 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146104/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
On 07.01.2020 13:06, Hongyan Xia wrote:
> @@ -4992,22 +4993,55 @@ int mmcfg_intercept_write(
> }
>
> void *alloc_xen_pagetable(void)
> +{
> +mfn_t mfn = alloc_xen_pagetable_new();
> +
> +return mfn_eq(mfn, INVALID_MFN) ? NULL : mfn_to_virt(mfn_x(mfn));
> +}
Isn't it more dangerous to
On 15.01.2020 18:00, Anthony PERARD wrote:
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -4,9 +4,25 @@
> #
> mainmenu "Xen/$(SRCARCH) $(XEN_FULLVERSION) Configuration"
>
> +source "scripts/Kconfig.include"
> +
> config BROKEN
> bool
>
> +config CC_IS_GCC
> + def_bool
On 14.01.2020 19:13, Roger Pau Monne wrote:
> When placing BARs with sizes smaller than 4K multiple BARs can end
> up mapped to the same guest physical address, and thus won't work
> correctly.
BARs of the same device can very well share a page in the common
case, can't they? (There may be
On 09.01.2020 17:22, Roger Pau Monne wrote:
> If the IPI destination mask matches the mask of online CPUs use the
> APIC ALLBUT destination shorthand in order to send an IPI to all CPUs
> on the system except the current one. This can only be safely used
> when no CPU hotplug or unplug operations
Hi,
On 16/01/2020 09:55, Jan Beulich wrote:
On 15.01.2020 19:44, Andrew Cooper wrote:
The BUG_ON() is confusing to follow. The (!is_idle_domain(d) || vcpu_id) part
is a vestigial remnant of architectures poisioning idle_vcpu[0] with non-NULL
pointers.
Now that idle_vcpu[0] is NULL on all
On 16.01.2020 10:46, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 16 January 2020 10:40
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org; Ian Jackson
>> ; Wei Liu ; Anthony PERARD
>> ; Andrew Cooper ;
>> George Dunlap ; Julien Grall
>> ; Konrad
On 15.01.2020 19:44, Andrew Cooper wrote:
> The BUG_ON() is confusing to follow. The (!is_idle_domain(d) || vcpu_id) part
> is a vestigial remnant of architectures poisioning idle_vcpu[0] with non-NULL
> pointers.
>
> Now that idle_vcpu[0] is NULL on all architectures, and d->max_vcpus specified
> -Original Message-
> From: Jan Beulich
> Sent: 16 January 2020 10:40
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Ian Jackson
> ; Wei Liu ; Anthony PERARD
> ; Andrew Cooper ;
> George Dunlap ; Julien Grall
> ; Konrad Rzeszutek Wilk ; Stefano
> Stabellini ;
On 15.01.2020 15:08, Andrew Cooper wrote:
> Despite being vaguely aware, the difference between PAGE_HYPERVISOR in ASM and
> C code has nevertheless caused several bugs I should have known better about,
> and contributed to review confusion.
>
> There are exactly 4 uses of these constants in asm
On 16.01.2020 10:36, Paul Durrant wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -614,6 +614,9 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
> /* Idle domain. */
> #define DOMID_IDLE xen_mk_uint(0x7FFF)
>
> +/* Mask for valid domain id values */
> +#define
On 16.01.2020 10:33, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 05:21:16PM +0100, Jan Beulich wrote:
>> On 15.01.2020 14:44, Roger Pau Monné wrote:
>>> On Wed, Jan 15, 2020 at 01:49:22PM +0100, Jan Beulich wrote:
What I'm then worried about is too
little progress observable by
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
This patch adds a 'domid' field to libxl_domain_create_info and then
modifies do_domain_create() to use that value if it is valid. Any valid
domid will be checked against the retired domid list before being passed
to libxl__domain_make().
If the domid value is invalid then Xen will choose the
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
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
v2:
- Heavily re-worked based on new libxl_domain_create_info
---
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
A domid is considered retired 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_MAX_RETIREMENT. If the variable does
not exist then a default value of 60s is used.
Whenever a domain is destroyed,
1 - 100 of 105 matches
Mail list logo
