Hi everyone,
We've been running into an issue with boot ordering when using OVMF
(specifically, with PXE booting). In particular, the issue is the "-boot
order=ABC" seems to have variable behavior depending on what it receives.
This is only an issue with UEFI; legacy handles this condition correct
flight 133750 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133750/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133703
test-armhf-armhf-libvirt 14 sav
flight 133743 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129313
test-amd64-i386-qemu
On Wed, Mar 13, 2019 at 04:36:50PM +, Sergey Dyasli wrote:
>On 11/03/2019 07:57, Chao Gao wrote:
>> to replace the current per-cpu cache 'uci->mc'.
>>
>> Compared to the current per-cpu cache, the benefits of the global
>> microcode cache are:
>> 1. It reduces the work that need to be done on
flight 133742 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133742/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 7 xen-boot fail REGR. vs. 133696
test-armhf-armhf-x
flight 133781 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133781/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 133776 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133776/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 16 guest-start/debian.repeat fail REGR. vs. 133771
Tests which
On Wed, Mar 13, 2019 at 7:33 PM Christoph Hellwig wrote:
> On Fri, Mar 08, 2019 at 05:25:57PM +, Julien Grall wrote:
> > In the common case, Dom0 also contains the PV backend drivers. Those
> > drivers may directly use the guest buffer in the DMA request (so a copy is
> > avoided). To avoid us
flight 133738 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133738/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 12 guest-start fail REGR. vs. 133580
test-arm64-arm64-li
Just SGX Launch Configuration is missing for one of my test boxes.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
tools/misc/xen-cpuid.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index d87a72e..2
On 13/03/2019 17:42, Julien Grall wrote:
> Hi Andrew,
>
> On 13/03/2019 17:34, Andrew Cooper wrote:
>> On 13/03/2019 15:59, Jan Beulich wrote:
>> On 13.03.19 at 16:48, wrote:
Hi,
On 13/03/2019 15:40, Jan Beulich wrote:
On 13.03.19 at 16:24, wrote:
>> On 13/03/2019
On Fri, Mar 08, 2019 at 05:25:57PM +, Julien Grall wrote:
> In the common case, Dom0 also contains the PV backend drivers. Those
> drivers may directly use the guest buffer in the DMA request (so a copy is
> avoided). To avoid using a bounce buffer too much, xen-swiotlb will find
> the host
On 3/13/19 12:44 PM, Markus Armbruster wrote:
> Patch created mechanically by rerunning:
>
> $ spatch --sp-file scripts/coccinelle/qobject.cocci \
> --macro-file scripts/cocci-macro-file.h \
> --dir hw/block --in-place
>
> Signed-off-by: Markus Armbruster
> ---
> h
On Wed, Mar 13, 2019 at 11:01 AM Paul Durrant wrote:
>
> > -Original Message-
> > From: Jason Andryuk [mailto:jandr...@gmail.com]
> > Sent: 11 March 2019 18:02
> > To: qemu-de...@nongnu.org
> > Cc: xen-devel@lists.xenproject.org; marma...@invisiblethingslab.com; Jason
> > Andryuk
> > ; St
Patch created mechanically by rerunning:
$ spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-file scripts/cocci-macro-file.h \
--dir hw/block --in-place
Signed-off-by: Markus Armbruster
---
hw/block/xen-block.c | 4 ++--
1 file changed, 2 insertions(+), 2
On 13/03/2019 15:59, Jan Beulich wrote:
On 13.03.19 at 16:48, wrote:
>> Hi,
>>
>> On 13/03/2019 15:40, Jan Beulich wrote:
>> On 13.03.19 at 16:24, wrote:
On 13/03/2019 15:22, Jan Beulich wrote:
On 18.02.19 at 12:36, wrote:
>> --- a/xen/include/asm-arm/mm.h
>> +++ b
Hi Andrew,
On 13/03/2019 17:34, Andrew Cooper wrote:
On 13/03/2019 15:59, Jan Beulich wrote:
On 13.03.19 at 16:48, wrote:
Hi,
On 13/03/2019 15:40, Jan Beulich wrote:
On 13.03.19 at 16:24, wrote:
On 13/03/2019 15:22, Jan Beulich wrote:
On 18.02.19 at 12:36, wrote:
--- a/xen/include/asm-
Hi Jan,
On 13/03/2019 15:20, Jan Beulich wrote:
On 18.02.19 at 12:35, wrote:
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -205,7 +205,7 @@ void getdomaininfo(struct domain *d, struct
xen_domctl_getdomaininfo *info)
info->outstanding_pages = d->outstanding_pages;
info->sh
Hi,
On 13/03/2019 15:04, Jan Beulich wrote:
On 18.02.19 at 12:35, wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4300,7 +4300,8 @@ int xenmem_add_to_physmap_one(
{
struct page_info *page = NULL;
unsigned long gfn = 0; /* gcc ... */
-unsigned long prev_mfn, old_gpf
On 13/03/2019 10:30, Andrew Cooper wrote:
> On 13/03/2019 07:39, Jan Beulich wrote:
> On 12.03.19 at 17:53, wrote:
>>> IIRC we agreed that systems with mixed CPU versions are not supported,
>>> hence the same microcode blob should be used to update all the
>>> possible CPUs on the system, so a
flight 133771 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133771/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 133736 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133736/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 128858
test-amd64-amd64-xl-
On 11/03/2019 07:57, Chao Gao wrote:
> to replace the current per-cpu cache 'uci->mc'.
>
> Compared to the current per-cpu cache, the benefits of the global
> microcode cache are:
> 1. It reduces the work that need to be done on each CPU. Parsing ucode
> file is done once on one CPU. Other CPUs ne
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
> Sent: 13 March 2019 13:15
> To: Paul Durrant
> Cc: Stefano Stabellini ; Wei Liu
> ; Konrad Rzeszutek Wilk
> ; George Dunlap ; Andrew
> Cooper
> ; Ian Jackson ; Tim
> (Xen
>>> On 06.03.19 at 13:58, wrote:
> +static int get_params(const char *cmdline, char *values,
> + const struct kernel_param *start,
> + const struct kernel_param *end)
> +{
> +char opt[128], *optkey, *q;
> +const char *p = cmdline, *val = values;
W
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
> Sent: 13 March 2019 15:55
> To: Andrew Cooper ; Paul Durrant
>
> Cc: xen-devel ; Kevin Tian
> ; Wei Liu
> ; Jun Nakajima ; Roger Pau Monne
>
> Subject: Re: [Xen-devel] [
Hi,
On 13/03/2019 14:57, Jan Beulich wrote:
On 18.02.19 at 12:35, wrote:
Convert online_page, offline_page and query_page_offline to use
typesafe MFN.
No functional changes.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
But ...
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_al
Am Wed, 13 Mar 2019 08:36:52 -0600
schrieb "Jan Beulich" :
> Why is there this big step between 199 and 200? And why does an
> initial value of 200 get handled the same as an initial value of 0, but
> then 400 doesn't get handled this same way again? And (seeing the
> last row I've added now) how
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 March 2019 15:37
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Wei Liu ; Stefano Stabellini
> ;
> xen-devel ; Konrad Rzeszutek Wilk
> ; Tim
>
>>> On 13.03.19 at 16:48, wrote:
> Hi,
>
> On 13/03/2019 15:40, Jan Beulich wrote:
> On 13.03.19 at 16:24, wrote:
>>> On 13/03/2019 15:22, Jan Beulich wrote:
>>> On 18.02.19 at 12:36, wrote:
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -321,10 +321,
>>> On 11.03.19 at 19:09, wrote:
> These hvm_funcs are no longer required since no MSR values are saved or
> restored by implementation-specific code.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@li
>>> On 11.03.19 at 19:09, wrote:
> v2:
> - Addressed comments from Jan by largely removing hunks
I think you've removed more than I was expecting, but I'm fine
this way.
> @@ -158,6 +158,13 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
> uint64_t *val)
> ret = guest_rdmsr_x2a
Hi,
On 13/03/2019 15:40, Jan Beulich wrote:
On 13.03.19 at 16:24, wrote:
On 13/03/2019 15:22, Jan Beulich wrote:
On 18.02.19 at 12:36, wrote:
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -321,10 +321,8 @@ struct page_info *get_page_from_gva(struct vcpu *v,
vaddr_t va,
>>> On 13.03.19 at 16:24, wrote:
> On 13/03/2019 15:22, Jan Beulich wrote:
> On 18.02.19 at 12:36, wrote:
>>> --- a/xen/include/asm-arm/mm.h
>>> +++ b/xen/include/asm-arm/mm.h
>>> @@ -321,10 +321,8 @@ struct page_info *get_page_from_gva(struct vcpu *v,
>>> vaddr_t va,
>>> #define SHARED_M2
>>> On 13.03.19 at 15:37, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 13 March 2019 14:06
>>
>> >>> On 11.03.19 at 14:41, wrote:
>> > +bool viridian_synic_deliver_timer_msg(struct vcpu *v, unsigned int sintx,
>> > + unsigned int index,
>>
Hi,
I think I found a small issue today in Xen's build system.
When you configure the build with --enable-systemd, and generate
a debian package with make debball, the xencommons init script
will be installed alongside the new systemd service units.
The problem is that it is not supposed to be e
> -Original Message-
> From: Jason Andryuk [mailto:jandr...@gmail.com]
> Sent: 11 March 2019 18:02
> To: qemu-de...@nongnu.org
> Cc: xen-devel@lists.xenproject.org; marma...@invisiblethingslab.com; Simon
> Gaiser
> ; Jason Andryuk ; Stefano
> Stabellini
> ; Anthony Perard ; Paul
> Durran
Hi Jan,
On 13/03/2019 15:22, Jan Beulich wrote:
On 18.02.19 at 12:36, wrote:
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -321,10 +321,8 @@ struct page_info *get_page_from_gva(struct vcpu *v,
vaddr_t va,
#define SHARED_M2P_ENTRY (~0UL - 1UL)
#define SHARED_M2P(
>>> On 18.02.19 at 12:36, wrote:
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -321,10 +321,8 @@ struct page_info *get_page_from_gva(struct vcpu *v,
> vaddr_t va,
> #define SHARED_M2P_ENTRY (~0UL - 1UL)
> #define SHARED_M2P(_e) ((_e) == SHARED_M2P_ENTR
>>> On 18.02.19 at 12:35, wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -205,7 +205,7 @@ void getdomaininfo(struct domain *d, struct
> xen_domctl_getdomaininfo *info)
> info->outstanding_pages = d->outstanding_pages;
> info->shr_pages = atomic_read(&d->shr_
> -Original Message-
> From: Jason Andryuk [mailto:jandr...@gmail.com]
> Sent: 11 March 2019 18:02
> To: qemu-de...@nongnu.org
> Cc: xen-devel@lists.xenproject.org; marma...@invisiblethingslab.com; Jason
> Andryuk
> ; Stefano Stabellini ; Anthony
> Perard
> ; Paul Durrant ; Paolo
> Bonzi
> -Original Message-
> From: Jason Andryuk [mailto:jandr...@gmail.com]
> Sent: 11 March 2019 18:02
> To: qemu-de...@nongnu.org
> Cc: xen-devel@lists.xenproject.org; marma...@invisiblethingslab.com; Jason
> Andryuk
> ; Stefano Stabellini ; Anthony
> Perard
> ; Paul Durrant ; Paolo
> Bonzi
Hi Jan,
On 13/03/2019 14:45, Jan Beulich wrote:
On 18.02.19 at 12:35, wrote:
mfn_to_gfn and mfn_to_gmfn are doing exactly the same except the former
is using mfn_t.
Furthermore, the naming of the former is more consistent with the
current naming scheme (GFN/MFN). So use replace mfn_to_gmfn wi
On 3/13/19 5:02 PM, Wei Liu wrote:
On Wed, Mar 13, 2019 at 01:31:22PM +0200, Razvan Cojocaru wrote:
On 3/13/19 1:28 PM, Wei Liu wrote:
On Wed, Mar 13, 2019 at 01:24:06PM +0200, Razvan Cojocaru wrote:
Hello,
Commit "build/m4: make python_devel.m4 work with both python 2 and 3" makes
my configu
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
> Sent: 13 March 2019 14:30
> To: Igor Druzhinin ; Paul Durrant
>
> Cc: Andrew Cooper ; Wei Liu ;
> xen-devel de...@lists.xenproject.org>; Roger Pau Monne
> Subject: Re: [
>>> On 18.02.19 at 12:35, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4300,7 +4300,8 @@ int xenmem_add_to_physmap_one(
> {
> struct page_info *page = NULL;
> unsigned long gfn = 0; /* gcc ... */
> -unsigned long prev_mfn, old_gpfn;
> +mfn_t prev_mfn;
> +
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 March 2019 14:23
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Wei Liu ; Stefano Stabellini
> ;
> xen-devel ; Konrad Rzeszutek Wilk
> ; Tim
>
On Wed, Mar 13, 2019 at 01:31:22PM +0200, Razvan Cojocaru wrote:
> On 3/13/19 1:28 PM, Wei Liu wrote:
> > On Wed, Mar 13, 2019 at 01:24:06PM +0200, Razvan Cojocaru wrote:
> > > Hello,
> > >
> > > Commit "build/m4: make python_devel.m4 work with both python 2 and 3"
> > > makes
> > > my configure
>>> On 18.02.19 at 12:35, wrote:
> No functional changes.
>
> Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 18.02.19 at 12:35, wrote:
> Convert online_page, offline_page and query_page_offline to use
> typesafe MFN.
>
> No functional changes.
>
> Signed-off-by: Julien Grall
Acked-by: Jan Beulich
But ...
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1568,23 +1568,23 @
>>> On 18.02.19 at 12:35, wrote:
> --- a/xen/include/asm-arm/grant_table.h
> +++ b/xen/include/asm-arm/grant_table.h
> @@ -67,15 +67,15 @@ void gnttab_mark_dirty(struct domain *d, mfn_t mfn);
> } while ( 0 )
>
> #define gnttab_get_frame_gfn(gt, st, idx) ({ \
> -
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 March 2019 14:06
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Roger Pau Monne
> ; Wei Liu ; George Dunlap
> ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel de...@lists.xenproject.org>; Konrad
>>> On 18.02.19 at 12:35, wrote:
> mfn_to_gfn and mfn_to_gmfn are doing exactly the same except the former
> is using mfn_t.
>
> Furthermore, the naming of the former is more consistent with the
> current naming scheme (GFN/MFN). So use replace mfn_to_gmfn with
> mfn_to_gfn in x86 code.
>
> No f
>>> On 18.02.19 at 12:35, wrote:
> The parameter "d" holds the domain and is not modified by the function.
> So constify it.
>
> Signed-off-by: Julien Grall
With the subject suitably corrected to name the actual function
Reviewed-by: Jan Beulich
Jan
>>> On 13.03.19 at 14:51, wrote:
> Am Wed, 13 Mar 2019 03:18:39 -0600
> schrieb "Jan Beulich" :
>
>> > +if ( tmp >= VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ )
>> > +tmp -= VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ;
>> The discontinuity is still there, and so far you've failed to explain
>>
>>> On 13.03.19 at 14:35, wrote:
> Am Wed, 13 Mar 2019 04:38:06 -0600
> schrieb "Jan Beulich" :
>
>> But this affects a guest even ahead of migration. What if one
>> uses migration really just for emergencies? Why would they
>> run their guests in always-emulate mode?
>
> Because this is what th
>>> On 13.03.19 at 13:47, wrote:
> On 13/03/2019 08:53, Jan Beulich wrote:
> On 12.03.19 at 17:23, wrote:
>>> Since the introduction of linear_{read,write}() helpers in 3bdec530a5
>>> (x86/HVM: split page straddling emulated accesses in more cases) the
>>> completion path for IOREQs has been
>>> On 13.03.19 at 14:25, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
>> Jan Beulich
>> Sent: 13 March 2019 13:15
>>
>> > +case HV_X64_MSR_SINT0 ... HV_X64_MSR_SINT15:
>> > +{
>> > +unsigned int sintx = array_index_nospec(idx - HV_X64_MS
>>> On 13.03.19 at 14:06, wrote:
>> From: Paul Durrant [mailto:paul.durr...@citrix.com]
>> Sent: 11 March 2019 13:42
>>
>> --- a/xen/include/asm-x86/hvm/viridian.h
>> +++ b/xen/include/asm-x86/hvm/viridian.h
>> @@ -40,6 +40,33 @@ union viridian_sint_msr
>> };
>> };
>>
>> +union viridian_st
>>> On 11.03.19 at 14:41, wrote:
> This patch adds an implementation of the hypercall as documented in the
> specification [1], section 10.5.2. This enlightenment, as with others, is
> advertised by CPUID leaf 0x4004 and is under control of a new
> 'hcall_ipi' option in libxl.
>
> If used, th
>>> On 11.03.19 at 14:41, wrote:
> +bool viridian_synic_deliver_timer_msg(struct vcpu *v, unsigned int sintx,
> + unsigned int index,
> + uint64_t expiration,
> + uint64_t delivery)
> +{
On 13/03/2019 13:54, Wei Liu wrote:
> Wei Liu (3):
> automation: use python-dev python2.7-dev in Debian and Ubuntu
> travis: use python-dev instead of python2.7-dev
> build/m4: fix python library detection on Ubuntu systems
Acked-by: Andrew Cooper
__
16cc3362aed doesn't work on Ubuntu with gcc (but it does work with
clang). Work around it by manipulating LIBS.
Signed-off-by: Wei Liu
---
m4/python_devel.m4 | 7 +++
tools/configure| 7 +++
2 files changed, 14 insertions(+)
diff --git a/m4/python_devel.m4 b/m4/python_devel.m4
index
... instead of python2.7-dev.
We installed python2.7-dev because xen only worked with 2.7.
Installing python2.7-dev only gives python2.7-config, which causes
configure to fail because it wants python-config by default. Now xen
should work with 2.6 and above, we can install python-dev and let
dist
Wei Liu (3):
automation: use python-dev python2.7-dev in Debian and Ubuntu
travis: use python-dev instead of python2.7-dev
build/m4: fix python library detection on Ubuntu systems
.travis.yml | 2 +-
automation/build/debian/jessie-i386.dockerfile
Xen build should be using default python now.
Signed-off-by: Wei Liu
---
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index 2266b4d22f..15ca9e9047 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -44,7 +44,7 @@ addons:
- zlib
Am Wed, 13 Mar 2019 03:18:39 -0600
schrieb "Jan Beulich" :
> > +if ( tmp >= VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ )
> > +tmp -= VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ;
> The discontinuity is still there, and so far you've failed to explain
> why a discontinuity is what you want here.
Am Wed, 13 Mar 2019 04:38:06 -0600
schrieb "Jan Beulich" :
> But this affects a guest even ahead of migration. What if one
> uses migration really just for emergencies? Why would they
> run their guests in always-emulate mode?
Because this is what they will end up for the lifetime of the domU aft
flight 133767 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133767/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
> Sent: 13 March 2019 13:15
> To: Paul Durrant
> Cc: Stefano Stabellini ; Wei Liu
> ; Konrad Rzeszutek Wilk
> ; George Dunlap ; Andrew
> Cooper
> ; Ian Jackson ; Tim
> (Xen
>>> On 11.03.19 at 14:41, wrote:
> @@ -28,6 +29,32 @@ typedef union _HV_VP_ASSIST_PAGE
> uint8_t ReservedZBytePadding[PAGE_SIZE];
> } HV_VP_ASSIST_PAGE;
>
> +typedef enum HV_MESSAGE_TYPE {
> +HvMessageTypeNone,
> +HvMessageTimerExpired = 0x8010,
> +} HV_MESSAGE_TYPE;
> +
> +typ
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 11 March 2019 13:42
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Wei Liu ;
> Ian Jackson
> ; Andrew Cooper ; George
> Dunlap
> ; Jan Beulich ; Julien Grall
> ;
> Konrad Rzeszutek Wilk ; Stef
On 13/03/2019 08:53, Jan Beulich wrote:
On 12.03.19 at 17:23, wrote:
>> Since the introduction of linear_{read,write}() helpers in 3bdec530a5
>> (x86/HVM: split page straddling emulated accesses in more cases) the
>> completion path for IOREQs has been broken: if there is an IOREQ in
>> progr
Hi,
>
> Starting kernel ...
>
> - UART enabled -
> - CPU booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Zero BSS -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) Initrd 7640-77a23
While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
expensive (but still needed only for the toggle_guest_mode() path), the
effect of the latter on the exit-to-guest path is not insignificant.
Move the logic into toggle_guest_mode().
Signed-off-by: Jan Beulich
--- a/xen/arch
Instead of the separate iommu_ret, the general rc can be used even for
the IOMMU operations.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2814,7 +2814,7 @@ static int _get_page_type(struct page_in
bool preemptible)
{
unsigned lon
In a few cases only a query is intended, i.e. without populating a
possible PoD or paged out entry, when the intention is to replace the
current entry anyway. Use get_gfn_query() there instead.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/grant_table.c
+++ b/xen/arch/x86/hvm/grant_table.c
@
When there's no XPTI-enabled PV domain at all, there's no need to issue
respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
record the creation of PV domains by bumping opt_xpti_* accordingly.
Signed-off-by: Jan Beulich
---
TBD: The hardwiring to false could be extended to opt_pv_l
>>> On 11.03.19 at 14:41, wrote:
> ...from arch_domain_shutdown/pause/unpause().
>
> A subsequent patch will introduce an implementaion of synthetic timers
> which will also need freeze/thaw hooks, so make the exported hooks more
> generic and call through to (re-named and static) time_ref_count_
>>> On 11.03.19 at 14:41, wrote:
> ...where there is more than one dereference inside a function.
>
> This shortens the code and makes it more readable. No functional change.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
___
Xen-devel
>>> On 11.03.19 at 14:41, wrote:
> ...inside viridian_page_msr and viridian_guest_os_id_msr unions.
>
> There's no need to name it and the code is shortened by not doing so.
> No functional change.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
___
>>> On 11.03.19 at 14:41, wrote:
> Currently the viridian_domain and viridian_vcpu structures are inline in
> the hvm_domain and hvm_vcpu structures respectively. Subsequent patches
> will need to add sizable extra fields to the viridian structures which
> will cause the PAGE_SIZE limit of the ove
>>> On 11.03.19 at 14:41, wrote:
> This patch adds domain and vcpu init hooks for viridian features. The init
> hooks do not yet do anything; the functionality will be added to by
> subsequent patches.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Wei Liu
Non-Viridian parts
Acked-by: Jan Beul
The patches here are really independent of one another, it's
just that they all result from work on the recently published
XSAs.
1: suppress XPTI-related TLB flushes when possible
2: relax a few get_gfn() invocations
3: mm: drop redundant local variable from _get_page_type()
4: PV: remove unnecess
On 3/13/19 1:28 PM, Wei Liu wrote:
On Wed, Mar 13, 2019 at 01:24:06PM +0200, Razvan Cojocaru wrote:
Hello,
Commit "build/m4: make python_devel.m4 work with both python 2 and 3" makes
my configure run fail, at least on my Ubuntu 16.04.6 LTS machine.
http://xenbits.xen.org/gitweb/?p=xen.git;a=co
On Wed, Mar 13, 2019 at 01:24:06PM +0200, Razvan Cojocaru wrote:
> Hello,
>
> Commit "build/m4: make python_devel.m4 work with both python 2 and 3" makes
> my configure run fail, at least on my Ubuntu 16.04.6 LTS machine.
>
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=16cc3362aed39e3
Hello,
Commit "build/m4: make python_devel.m4 work with both python 2 and 3"
makes my configure run fail, at least on my Ubuntu 16.04.6 LTS machine.
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=16cc3362aed39e3093419b9df6ec73269071d063
checking for python-config... /usr/bin/python-c
flight 133737 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133737/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fb94f83131f032cd5ce027ea706c45513c1a799e
baseline version:
ovmf 690d60c0ada5ff137c849
"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 133734 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133734/
Fa
>>> On 13.03.19 at 11:23, wrote:
> Am Wed, 13 Mar 2019 03:18:39 -0600
> schrieb "Jan Beulich" :
>
>> > +if ( tmp >= VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ )
>> > +tmp -= VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ;
>> The discontinuity is still there, and so far you've failed to explain
>>
On 13/03/2019 07:39, Jan Beulich wrote:
On 12.03.19 at 17:53, wrote:
>> IIRC we agreed that systems with mixed CPU versions are not supported,
>> hence the same microcode blob should be used to update all the
>> possible CPUs on the system, so a list should not be needed here.
> That's not wh
On 13/03/2019 10:21, Jan Beulich wrote:
On 11.03.19 at 19:08, wrote:
On 11/03/2019 16:49, Jan Beulich wrote:
The memory operand is an in/out one, and the auxiliary register gets
written to early.
Take the opportunity and also drop the redundant cast (the inline
functions' parameters are alr
Am Wed, 13 Mar 2019 03:18:39 -0600
schrieb "Jan Beulich" :
> > +if ( tmp >= VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ )
> > +tmp -= VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ;
> The discontinuity is still there, and so far you've failed to explain
> why a discontinuity is what you want here.
Hi,
On 13/03/2019 10:16, Jan Beulich wrote:
./CODING_STYLE mandates the asm ( "" ) form, even if it doesn't mention
asm() explicitly.
That's your interpretation of CODING_STYLE. Furthermore, as I pointed out in the
previous version, this current style for asm is consistent with the rest of Ar
>>> On 11.03.19 at 19:08, wrote:
> On 11/03/2019 16:49, Jan Beulich wrote:
>> The memory operand is an in/out one, and the auxiliary register gets
>> written to early.
>>
>> Take the opportunity and also drop the redundant cast (the inline
>> functions' parameters are already of the casted-to typ
Hi Jan,
On 13/03/2019 10:15, Jan Beulich wrote:
Drop redundant casts. Un-define no longer needed macros after use.
Signed-off-by: Jan Beulich
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenprojec
./CODING_STYLE mandates the asm ( "" ) form, even if it doesn't mention
asm() explicitly.
Signed-off-by: Jan Beulich
---
v2: Split off from previous patch.
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -9,29 +9,29 @@
static inline type name(const volatile type *addr)
Hi Jan,
On 13/03/2019 10:14, Jan Beulich wrote:
By adding another suitable abstracting macro the need for explicit
inline function definitions in the 32-bit case goes away.
Signed-off-by: Jan Beulich
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
__
Drop redundant casts. Un-define no longer needed macros after use.
Signed-off-by: Jan Beulich
---
v2: asm() style corrections split off to subsequent patch.
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -11,7 +11,7 @@ static inline type name(const volatile t
type
By adding another suitable abstracting macro the need for explicit
inline function definitions in the 32-bit case goes away.
Signed-off-by: Jan Beulich
---
v2: Drop change to align the right sides of #define-s.
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -37,40 +37,2
1 - 100 of 116 matches
Mail list logo
