flight 146453 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146453/
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 146455 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146455/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On 24.01.20 01:01, Dario Faggioli wrote:
On Thu, 2020-01-23 at 10:03 +0100, Juergen Gross wrote:
There are still several instances of cpumask_t on the stack in
scheduling code. Avoid them as far as possible.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
Just curious...
---
flight 146457 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146457/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146401
build-armhf
Hi Vincenzo,
On Thu, Jan 23, 2020 at 10:48:07AM +, Vincenzo Frascino wrote:
> Hi Boqun Feng,
>
> sorry for the late reply.
>
That's OK, thanks for your review ;-)
> On 16/12/2019 00:19, Boqun Feng wrote:
> > Hi,
> >
> > This is the RFC patchset for vDSO support in ARM64 Hyper-V guest. To
flight 146423 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146423/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
146121
flight 146454 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146454/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146401
build-armhf
flight 146448 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146448/
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 146447 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146447/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146401
build-armhf
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug
On Thu, 2020-01-23 at 10:03 +0100, Juergen Gross wrote:
> There are still several instances of cpumask_t on the stack in
> scheduling code. Avoid them as far as possible.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Just curious...
> --- a/xen/common/sched/core.c
> +++
flight 146439 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146439/
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 146438 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146438/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146401
build-armhf
> On 23 Jan 2020, at 05:31, Bobby Eshleman wrote:
>
> On Wed, Jan 22, 2020 at 04:27:39PM +, Lars Kurth wrote:
>>
>> You should also leverage the developer summit: see
>> https://events.linuxfoundation.org/xen-summit/program/cfp/
>>
flight 146424 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146424/
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
flight 146419 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146419/
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.
On Thu, Jan 23, 2020 at 10:36:34PM +, tosher 1 wrote:
>
>
> I wasn't able to make the HVM driver domain work even with the latest Xen
> version which is 4.14. I see the 'xendriverdomain' executable in the
> /etc/init.d/ directory, but it doesn't seem to be running in the background.
>
>
I wasn't able to make the HVM driver domain work even with the latest Xen
version which is 4.14. I see the 'xendriverdomain' executable in the
/etc/init.d/ directory, but it doesn't seem to be running in the background.
On the other hand, I see the official "Qubes OS Architecture" document
flight 146435 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146435/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146401
build-armhf
flight 146432 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146432/
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 146421 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146421/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
examine-elbling1 2 hosts-allocate starved n/a
examine-pinot02
flight 146427 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146427/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146401
build-armhf
Hello,
The series contain some improvements to disconnect_bsp_APIC, which
started as a way to fix the "APIC error on CPU0: 40(00)" error printed
by some Intel boxes on reboot or shutdown. First patch is the fix for
the error, second patch is a cleanup.
Roger Pau Monne (2):
x86/apic: fix
On Thu, Jan 23, 2020 at 11:45 AM Andrew Cooper
wrote:
>
> On 17/01/2020 13:31, 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
flight 146422 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146422/
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 17/01/2020 13:31, 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
Something in this series broke
There's no need to read the current values of LVT{0/1} for the
purposes of the function, which seem to be to save the currently
selected vector: in the destination modes used (ExtINT and NMI) the
vector field is ignored and hence can be set to 0.
Signed-off-by: Roger Pau Monné
---
On 23/01/2020 18:15, Anthony PERARD wrote:
> On Thu, Jan 23, 2020 at 06:17:06PM +0100, Roger Pau Monné wrote:
>> On Thu, Jan 23, 2020 at 03:34:25PM +, Anthony PERARD wrote:
>>> On Tue, Jan 21, 2020 at 10:21:09AM +, Roger Pau Monné wrote:
The issue is that this change is passing the
On Thu, Jan 23, 2020 at 06:17:06PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 23, 2020 at 03:34:25PM +, Anthony PERARD wrote:
> > On Tue, Jan 21, 2020 at 10:21:09AM +, Roger Pau Monné wrote:
> > > The issue is that this change is passing the guest domain_create_state
> > > to
The Intel SDM states:
"When an illegal vector value (0 to 15) is written to a LVT entry and
the delivery mode is Fixed (bits 8-11 equal 0), the APIC may signal an
illegal vector error, without regard to whether the mask bit is set or
whether an interrupt is actually seen on the input."
And
On 23/01/2020 17:45, Tamas K Lengyel wrote:
> Hi all,
> I just wanted to bring it to the community's attention that I've upped
> Valgrind's Xen support to include everything up to Xen 4.13. It's now
> merged and will be part of the next Valgrind release:
>
Hi all,
I just wanted to bring it to the community's attention that I've upped
Valgrind's Xen support to include everything up to Xen 4.13. It's now
merged and will be part of the next Valgrind release:
https://sourceware.org/git/?p=valgrind.git;a=commit;h=c88133141a354d65568fb85037abc5e1f74ce46b
On Thu, Jan 23, 2020 at 10:21 AM George Dunlap wrote:
>
> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> > VM forking is the process of creating a domain with an empty memory space
> > and a
> > parent domain specified from which to populate the memory when necessary.
> > For
> > the new domain
On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> VM forking is the process of creating a domain with an empty memory space and
> a
> parent domain specified from which to populate the memory when necessary. For
> the new domain to be functional the VM state is copied over as part of the
> fork
>
On Thu, Jan 23, 2020 at 9:44 AM George Dunlap wrote:
>
> On 1/22/20 5:08 PM, Tamas K Lengyel wrote:
> > On Wed, Jan 22, 2020 at 8:35 AM Jan Beulich wrote:
> >>
> >> On 21.01.2020 18:49, Tamas K Lengyel wrote:
> >>> When plugging a hole in the target physmap don't use the access permission
> >>>
On Thu, Jan 23, 2020 at 03:34:25PM +, Anthony PERARD wrote:
> On Tue, Jan 21, 2020 at 10:21:09AM +, Roger Pau Monné wrote:
> > The issue is that this change is passing the guest domain_create_state
> > to libxl__domain_build in libxl__spawn_stub_dm, and hence the
> > stubdomain doesn't get
flight 146420 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146420/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146401
build-armhf
flight 146414 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146414/
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
The field 'sdss' was named 'dmss' before, commit 3148bebbf0ab did the
renamed but didn't update the comment.
Fixes: 3148bebbf0ab ("libxl: rename a field in libxl__domain_create_state")
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 2 +-
1 file changed, 1 insertion(+), 1
On 23.01.2020 17:42, George Dunlap wrote:
> On 1/23/20 4:37 PM, Jan Beulich wrote:
>> On 23.01.2020 17:32, George Dunlap wrote:
>>> On 1/23/20 4:23 PM, Tamas K Lengyel wrote:
On Thu, Jan 23, 2020 at 9:14 AM George Dunlap
wrote:
>
> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
flight 146417 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146417/
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/22/20 5:08 PM, Tamas K Lengyel wrote:
> On Wed, Jan 22, 2020 at 8:35 AM Jan Beulich wrote:
>>
>> 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,
>>
>>
On 1/23/20 4:37 PM, Jan Beulich wrote:
> On 23.01.2020 17:32, George Dunlap wrote:
>> On 1/23/20 4:23 PM, Tamas K Lengyel wrote:
>>> On Thu, Jan 23, 2020 at 9:14 AM George Dunlap
>>> wrote:
On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> MEM_SHARING_DESTROY_GFN is used on the 'flags'
On 23.01.2020 17:32, George Dunlap wrote:
> On 1/23/20 4:23 PM, Tamas K Lengyel wrote:
>> On Thu, Jan 23, 2020 at 9:14 AM George Dunlap
>> wrote:
>>>
>>> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
However, the
On 1/23/20 4:23 PM, Tamas K Lengyel wrote:
> On Thu, Jan 23, 2020 at 9:14 AM George Dunlap
> wrote:
>>
>> On 1/21/20 5:49 PM, 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
On 1/22/20 3:07 PM, Anchal Agarwal wrote:
>> In this case tsc_verify_tsc_adjust(true) this does nothing as
>> feature bit X86_FEATURE_TSC_ADJUST is not available to guest.
Is it not available to your specific guest? Because AFAICT it is
available in general (to HVM/PVH guests).
> 4. Also,
On Thu, Jan 23, 2020 at 9:14 AM George Dunlap wrote:
>
> On 1/21/20 5:49 PM, 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 23/01/2020 11:42, Jan Beulich wrote:
> In order to avoid permanently having to ask that no new command line
> options using underscores be introduced (albeit I'm likely to still make
> remarks), and in order to also allow extending the use of hyphens to
> pre-existing ones, introduce custom
On 1/21/20 5:49 PM, 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
But is there a
flight 146418 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146418/
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 23.01.2020 16:56, Durrant, Paul wrote:
>> From: Jan Beulich
>> Sent: 23 January 2020 15:32
>>
>> On 23.01.2020 15:03, 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
>>
On 23/01/2020 05:19, Bobby Eshleman wrote:
> On Wed, Jan 22, 2020 at 02:57:47PM +, Andrew Cooper wrote:
>> How much time do you have to put towards the port? Is this something in
>> your free time, or something you are doing as part of work? Ultimately,
>> we are going to need to increase
On 1/21/20 5:49 PM, 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 23.01.2020 16:43, Roger Pau Monné wrote:
> On Fri, Jan 17, 2020 at 05:25:12PM +0100, Jan Beulich wrote:
>> On 17.01.2020 17:08, Roger Pau Monné wrote:
>>> On Fri, Jan 17, 2020 at 04:56:00PM +0100, Jan Beulich wrote:
On 17.01.2020 16:09, Roger Pau Monne wrote:
> The Intel SDM states:
> -Original Message-
> From: Jan Beulich
> Sent: 23 January 2020 15:32
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George Dunlap ; Ian
> Jackson ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Jun Nakajima ;
On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> All callers pass 0 in.
>
> Signed-off-by: Tamas K Lengyel
> Reviewed-by: Wei Liu
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 22.01.2020 21:23, Wei Liu wrote:
> @@ -142,15 +143,40 @@ static void setup_hypercall_pcpu_arg(void)
> this_cpu(hv_vp_index) = vp_index_msr;
> }
>
> +static void setup_vp_assist(void)
> +{
> +void *mapping;
> +uint64_t val;
> +
> +mapping = this_cpu(hv_vp_assist);
> +
> +
On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> During VM forking the client lock will already be taken.
>
> Signed-off-by: Tamas K Lengyel
> Acked-by: Andrew Coopers
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 1/23/20 3:46 PM, Durrant, Paul wrote:
>> -Original Message-
>> From: Julien Grall
>> Sent: 23 January 2020 15:26
>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>> Cc: Jan Beulich ; Andrew Cooper
>> ; Wei Liu ; Roger Pau Monné
>> ; George Dunlap ; Ian
>> Jackson ; Konrad
On 22.01.2020 21:23, Wei Liu wrote:
> This will be useful when invoking hypercall that targets specific
> vcpu(s).
>
> Signed-off-by: Wei Liu
> Reviewed-by: Paul Durrant
For formal reasons
Acked-by: Jan Beulich
However I wonder whether the Viridian entry in MAINTAINERS shouldn't
be extended
On Thu, Jan 23, 2020 at 8:32 AM George Dunlap wrote:
>
> On 1/22/20 4:55 PM, Jan Beulich wrote:
> > On 22.01.2020 17:51, Tamas K Lengyel wrote:
> >> On Wed, Jan 22, 2020 at 8:23 AM Jan Beulich wrote:
> >>>
> >>> On 21.01.2020 18:49, Tamas K Lengyel wrote:
> The owner domain of shared pages
On 23/01/2020 15:46, Durrant, Paul wrote:
-Original Message-
From: Julien Grall
Sent: 23 January 2020 15:26
To: Durrant, Paul ; xen-devel@lists.xenproject.org
Cc: Jan Beulich ; Andrew Cooper
; Wei Liu ; Roger Pau Monné
; George Dunlap ; Ian
Jackson ; Konrad Rzeszutek Wilk
; Stefano
> -Original Message-
> From: Julien Grall
> Sent: 23 January 2020 15:26
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George Dunlap ; Ian
> Jackson ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Jun
> Nakajima ;
On 22.01.2020 21:23, Wei Liu wrote:
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -27,7 +27,10 @@
> #include
> #include
>
> +#include "private.h"
> +
> struct ms_hyperv_info __read_mostly ms_hyperv;
> +DEFINE_PER_CPU_READ_MOSTLY(void *,
On Fri, Jan 17, 2020 at 05:25:12PM +0100, Jan Beulich wrote:
> On 17.01.2020 17:08, Roger Pau Monné wrote:
> > On Fri, Jan 17, 2020 at 04:56:00PM +0100, Jan Beulich wrote:
> >> On 17.01.2020 16:09, Roger Pau Monne wrote:
> >>> The Intel SDM states:
> >>>
> >>> "When an illegal vector value (0 to
On 1/23/20 3:32 PM, Jan Beulich wrote:
> On 23.01.2020 15:03, 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
On Tue, Jan 21, 2020 at 10:21:09AM +, Roger Pau Monné wrote:
> The issue is that this change is passing the guest domain_create_state
> to libxl__domain_build in libxl__spawn_stub_dm, and hence the
> stubdomain doesn't get created. I have the following patch that fixes
> it, but it's kind of
On 1/22/20 4:55 PM, Jan Beulich wrote:
> On 22.01.2020 17:51, Tamas K Lengyel wrote:
>> On Wed, Jan 22, 2020 at 8:23 AM Jan Beulich wrote:
>>>
>>> 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
On 23/01/2020 14:03, 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
> Acked-by: Kevin Tian
> Reviewed-by: Jan Beulich
> ---
> Cc: Andrew
On 23.01.2020 15:03, 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
On 23/01/2020 14:03, Paul Durrant wrote:
diff --git a/xen/common/domain.c b/xen/common/domain.c
index ee3f9ffd3e..30c777acb8 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -339,6 +339,8 @@ static int sanitise_domain_config(struct
xen_domctl_createdomain *config)
return
From: Jan Beulich Sent: Thursday, January 23, 2020 3:19 AM
>
> On 22.01.2020 21:23, Wei Liu wrote:
> > --- a/xen/arch/x86/e820.c
> > +++ b/xen/arch/x86/e820.c
> > @@ -36,6 +36,22 @@ boolean_param("e820-verbose", e820_verbose);
> > struct e820map e820;
> > struct e820map __initdata e820_raw;
>
On 23.01.2020 15:03, 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.
>
> A
On 23.01.2020 15:52, Julien Grall wrote:
> Therefore, they will have to accept whatever string is reported by
> HVMLoader (or Xen). As you already allow Xen to configure it, why would
> that be a problem to change the one in Kconfig? Why do you need to fix
> it up in hvmloader as well?
On 1/23/20 2:52 PM, Julien Grall wrote:
> Hi,
>
> On 23/01/2020 14:45, George Dunlap wrote:
>> On 1/23/20 2:42 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 23/01/2020 11:32, Sergey Dyasli wrote:
On 22/01/2020 11:25, Julien Grall wrote:
>
>
> On 22/01/2020 11:19, Sergey Dyasli
Hi,
On 23/01/2020 14:45, George Dunlap wrote:
On 1/23/20 2:42 PM, Julien Grall wrote:
Hi,
On 23/01/2020 11:32, Sergey Dyasli wrote:
On 22/01/2020 11:25, Julien Grall wrote:
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
On 1/23/20 2:03 PM, 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
On 1/23/20 2:42 PM, Julien Grall wrote:
> Hi,
>
> On 23/01/2020 11:32, Sergey Dyasli wrote:
>> On 22/01/2020 11:25, Julien Grall wrote:
>>>
>>>
>>> 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:
Hi,
On 23/01/2020 11:32, Sergey Dyasli wrote:
On 22/01/2020 11:25, Julien Grall wrote:
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
On 1/22/20 11:44 AM, Sergey Dyasli wrote:
> 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:
On 1/17/20 1:31 PM, 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
> Acked-by:
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
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 | 7 +-
xen/arch/x86/hvm/mtrr.c| 2 +-
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.
A subsequent patch will define a VMX implementation.
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
Acked-by: Kevin Tian
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: Jun
flight 146408 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146408/
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.
> -Original Message-
> From: Jan Beulich
> Sent: 23 January 2020 13:30
> To: Durrant, Paul
> Cc: Kevin Tian ; Wei Liu ; Andrew Cooper
> ; Jun Nakajima ; xen-
> de...@lists.xenproject.org; Roger Pau Monné
> Subject: Re: [PATCH v2 1/3] x86 / vmx: make apic_access_mfn type-safe
>
> On
flight 146416 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146416/
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 23.01.2020 14:09, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 23 January 2020 12:45
>> To: Durrant, Paul
>> Cc: Kevin Tian ; Wei Liu ; Andrew Cooper
>> ; Jun Nakajima ; xen-
>> de...@lists.xenproject.org; Roger Pau Monné
>>
On 23.01.2020 13:11, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 23 January 2020 11:43
>> To: xen-devel@lists.xenproject.org
>> Cc: Stefano Stabellini ; Julien Grall
>> ; Wei Liu ; Konrad Wilk
>> ; George Dunlap ;
>> Andrew Cooper ;
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 23 January 2020 12:45
> To: Durrant, Paul
> Cc: Kevin Tian ; Wei Liu ; Andrew Cooper
> ; Jun Nakajima ; xen-
> de...@lists.xenproject.org; Roger Pau Monné
> Subject: Re: [Xen-devel] [PATCH v2 1/3] x86 / vmx: make
On 23.01.2020 13:21, 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
> Acked-by: Kevin Tian
> Reviewed-by: Jan Beulich
No, this isn't
On 1/17/20 1:31 PM, Alexandru Stefan ISAILA wrote:
> No functional changes.
>
> Requested-by: Jan Beulich
> Signed-off-by: Alexandru Isaila
> Reviewed-by: Jan Beulich
Acked-by: George Dunlap
___
Xen-devel mailing list
On 1/17/20 1:31 PM, 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 is doing a best
Hi,
On 21/01/2020 15:07, 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" between
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
> > > >
> > > >
Hi,
On 21/01/2020 15:07, Jeff Kubascik wrote:
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
Hi,
On 17/01/2020 21:24, Jeff Kubascik wrote:
On 12/18/2019 9:20 AM, Julien Grall wrote:
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.
On 1/17/20 1:31 PM, 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
Acked-by: George Dunlap
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
1 - 100 of 143 matches
Mail list logo
