flight 134289 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134289/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
On Wed, Apr 03, 2019 at 07:56:18PM +0100, Andrew Cooper wrote:
> These were made redundant by c/s 23058e7b3 "x86/shadow: put PV L1TF functions
> under CONFIG_PV" but makes the code read as if outside of the ifdef.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
__
>>> On 03.04.19 at 20:32, wrote:
> On 13/03/2019 12:39, Jan Beulich wrote:
>> 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.
>>> On 03.04.19 at 20:52, wrote:
> On 13/03/2019 12:38, Jan Beulich wrote:
>> 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.
>>
>>
>>> On 03.04.19 at 18:16, wrote:
> On Wed, Apr 3, 2019 at 10:06 AM Jan Beulich wrote:
>> Then I still don't see why you would want to force propagation
>> in these cases: If it's generally demand-populate, it can't be right
>> to _fully_ populate that slot. You ought to be setting the access
>> t
flight 83868 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/83868/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 03 April 2019 19:08
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu
> ; Roger Pau Monne ; Brian Woods
> ; Paul
> Durrant
> Subject: [PATCH] amd-iommu: Fix Guest CR3 Table following c/s 3a
On 04/04/2019 11:39, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 03 April 2019 19:08
>> To: Xen-devel
>> Cc: Andrew Cooper ; Jan Beulich
>> ; Wei Liu
>> ; Roger Pau Monne ; Brian Woods
>> ; Paul
>> Durrant
>> Subject: [PAT
>>> On 03.04.19 at 19:41, wrote:
> On 4/3/19 7:04 PM, Jan Beulich wrote:
> On 03.04.19 at 17:48, wrote:
>>> On 4/3/19 6:30 PM, Jan Beulich wrote:
>>> On 03.04.19 at 17:17, wrote:
> Changes to the hostp2m (also known as altp2m view 0) propagate to all
> existing altp2ms, but they
> -Original Message-
> From: Andrew Cooper
> Sent: 04 April 2019 11:46
> To: Paul Durrant ; Xen-devel
>
> Cc: Jan Beulich ; Wei Liu ; Roger Pau
> Monne
> ; Brian Woods
> Subject: Re: [PATCH] amd-iommu: Fix Guest CR3 Table following c/s 3a7947b6901
>
> On 04/04/2019 11:39, Paul Durrant
flight 134291 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134291/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvop
At the same time sort the list alphabetically.
Signed-off-by: Wei Liu
---
automation/scripts/containerize | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 01c44da93c..a7809b3010 100755
--- a/automatio
Although the image comes with clang, clang builds don't work yet.
Signed-off-by: Wei Liu
---
automation/gitlab-ci/build.yaml | 10 ++
1 file changed, 10 insertions(+)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index c29a76e9ff..dd5722a5bb 100644
--- a
Wei Liu (3):
automation: add a Fedora image
automation: add Fedora image to containerize script
gitlab-ci: add fedora gcc build jobs
automation/build/fedora/latest.dockerfile | 43 +++
automation/gitlab-ci/build.yaml | 10 ++
automation/scripts/containerize
Use the latest and greatest.
Signed-off-by: Wei Liu
---
automation/build/fedora/latest.dockerfile | 43 +++
1 file changed, 43 insertions(+)
create mode 100644 automation/build/fedora/latest.dockerfile
diff --git a/automation/build/fedora/latest.dockerfile
b/automation/bui
The semantics of sector based quantities, such as first_sect and last_sect
in blkif_request_segment, and the value of "sectors" in the backend info
in xenstore have become confused. Some comments in the header suggest they
should be supplied/interpreted strictly in terms of 512-byte units, others
s
>>> On 03.04.19 at 20:08, wrote:
> +static uint64_t dte_get_gcr3_table(const struct amd_iommu_dte *dte)
> {
> return ((dte->gcr3_trp_51_31 << 31) | (dte->gcr3_trp_30_15 << 15) |
I'm afraid there's another bug here: gcc, in its default mode at
least, doesn't promote bit field values to their
>>> On 04.04.19 at 10:25, wrote:
> On Wed, Apr 03, 2019 at 07:56:18PM +0100, Andrew Cooper wrote:
>> These were made redundant by c/s 23058e7b3 "x86/shadow: put PV L1TF functions
>> under CONFIG_PV" but makes the code read as if outside of the ifdef.
>>
>> Signed-off-by: Andrew Cooper
>
> Revie
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-multivcpu
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional
Hello Andrew
Minor note below.
On Wed, 2019-04-03 at 16:00 +0100, Andrew Cooper wrote:
[snip]
> + For ARM builds, while Xen will compile with ``CONFIG_COVERAGE``
> enabled, the
> + resulting binary will not successfully boot if it exceeds 2MB in
> size.
> + Xen's early memory management code
On Wed, Apr 03, 2019 at 03:59:59PM +0100, Andrew Cooper wrote:
> Include (and retrofit to the user guide) an introductory paragraph describing
> the intended audience.
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-
On Wed, Apr 03, 2019 at 04:00:00PM +0100, Andrew Cooper wrote:
> During a discussion in person, it was identified that Coverage doesn't
> currently work for ARM yet. Also, there are a number of errors with the
> existing coverage document.
>
> Take the opportunity to rewrite it in RST, making it
On Thu, Apr 04, 2019 at 12:40:02PM +0100, Paul Durrant wrote:
> The semantics of sector based quantities, such as first_sect and last_sect
> in blkif_request_segment, and the value of "sectors" in the backend info
> in xenstore have become confused. Some comments in the header suggest they
> should
On 04/04/2019 13:07, Artem Mygaiev wrote:
> Hello Andrew
Hi,
> Minor note below.
>
> On Wed, 2019-04-03 at 16:00 +0100, Andrew Cooper wrote:
>
> [snip]
>
>> + For ARM builds, while Xen will compile with ``CONFIG_COVERAGE``
>> enabled, the
>> + resulting binary will not successfully boot if
From: Oleksandr Andrushchenko
This fixes the regression introduced while moving to Xen shared
buffer implementation.
Fixes: 58f9d806d16a ("ALSA: xen-front: Use Xen common shared buffer
implementation")
Signed-off-by: Oleksandr Andrushchenko
---
sound/xen/xen_snd_front_alsa.c | 2 +-
1 file c
On 04/04/2019 14:38, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> This fixes the regression introduced while moving to Xen shared
> buffer implementation.
>
> Fixes: 58f9d806d16a ("ALSA: xen-front: Use Xen common shared buffer
> implementation")
>
> Signed-off-by: Oleksan
On Thu, 04 Apr 2019 14:42:44 +0200,
Juergen Gross wrote:
>
> On 04/04/2019 14:38, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko
> >
> > This fixes the regression introduced while moving to Xen shared
> > buffer implementation.
> >
> > Fixes: 58f9d806d16a ("ALSA: xen-front: Us
On 4/3/19 6:30 PM, Jan Beulich wrote:
On 03.04.19 at 17:17, wrote:
On 4/3/19 5:58 PM, Jan Beulich wrote:
On 03.04.19 at 16:29, wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -3011,8 +3011,16 @@ int p2m_set_suppress_ve(struct domain *d, gfn_t gfn,
bool suppress_ve,
On 04/04/2019 13:29, Julien Grall wrote:
>
> On 04/04/2019 13:07, Artem Mygaiev wrote:
>> Hello Andrew
> Hi,
>
>> Minor note below.
>>
>> On Wed, 2019-04-03 at 16:00 +0100, Andrew Cooper wrote:
>>
>> [snip]
>>
>>> + For ARM builds, while Xen will compile with ``CONFIG_COVERAGE``
>>> enabled, the
>
On 4/4/19 3:45 PM, Takashi Iwai wrote:
On Thu, 04 Apr 2019 14:42:44 +0200,
Juergen Gross wrote:
On 04/04/2019 14:38, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This fixes the regression introduced while moving to Xen shared
buffer implementation.
Fixes: 58f9d806d16a ("ALSA:
On 04/04/2019 13:46, Razvan Cojocaru wrote:
> On 4/3/19 6:30 PM, Jan Beulich wrote:
> On 03.04.19 at 17:17, wrote:
>>> On 4/3/19 5:58 PM, Jan Beulich wrote:
>>> On 03.04.19 at 16:29, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -3011,8 +3011,16 @@ in
On 4/4/19 3:46 PM, Razvan Cojocaru wrote:
On 4/3/19 6:30 PM, Jan Beulich wrote:
On 03.04.19 at 17:17, wrote:
On 4/3/19 5:58 PM, Jan Beulich wrote:
On 03.04.19 at 16:29, wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -3011,8 +3011,16 @@ int p2m_set_suppress_ve(struct domai
On Tue, 2019-04-02 at 18:19 +0200, Juergen Gross wrote:
> cpu_disable_scheduler() is being called from __cpu_disable() today.
> There is no need to execute it on the cpu just being disabled, so use
> the CPU_DEAD case of the cpu notifier chain. Moving the call out of
> stop_machine() context is fin
On Thu, Apr 4, 2019 at 6:50 AM Razvan Cojocaru
wrote:
>
> On 4/4/19 3:46 PM, Razvan Cojocaru wrote:
> > On 4/3/19 6:30 PM, Jan Beulich wrote:
> > On 03.04.19 at 17:17, wrote:
> >>> On 4/3/19 5:58 PM, Jan Beulich wrote:
> >>> On 03.04.19 at 16:29, wrote:
> > --- a/xen/arch/x86/mm/p2m.
On Thu, Apr 04, 2019 at 12:23:02PM +0100, Wei Liu wrote:
> Although the image comes with clang, clang builds don't work yet.
>
> Signed-off-by: Wei Liu
Acked-by: Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.x
On Thu, Mar 14, 2019 at 02:08:47PM +, Wei Liu wrote:
> It is common that build hosts are isolated from outside world. They
> don't necessarily have wget or ftp installed.
>
> Turn the error into warning in configure. And point FETCHER to `false'
> command if neither wget nor ftp is available,
On Thu, Apr 4, 2019 at 6:49 AM Andrew Cooper wrote:
>
> On 04/04/2019 13:46, Razvan Cojocaru wrote:
> > On 4/3/19 6:30 PM, Jan Beulich wrote:
> > On 03.04.19 at 17:17, wrote:
> >>> On 4/3/19 5:58 PM, Jan Beulich wrote:
> >>> On 03.04.19 at 16:29, wrote:
> > --- a/xen/arch/x86/mm/p2m.
On 04/04/2019 14:13, Wei Liu wrote:
> On Thu, Mar 14, 2019 at 02:08:47PM +, Wei Liu wrote:
>> It is common that build hosts are isolated from outside world. They
>> don't necessarily have wget or ftp installed.
>>
>> Turn the error into warning in configure. And point FETCHER to `false'
>> comm
Hi,
On 04/04/2019 13:46, Andrew Cooper wrote:
On 04/04/2019 13:29, Julien Grall wrote:
On 04/04/2019 13:07, Artem Mygaiev wrote:
Hello Andrew
Hi,
Minor note below.
On Wed, 2019-04-03 at 16:00 +0100, Andrew Cooper wrote:
[snip]
+ For ARM builds, while Xen will compile with ``CONFIG_COV
On Fri, Mar 15, 2019 at 05:29:28PM +0100, Juergen Gross wrote:
> On 15/03/2019 16:55, Andrew Cooper wrote:
> > On 14/03/2019 11:59, Juergen Gross wrote:
> >> @@ -1100,6 +1100,20 @@ typedef struct xen_sysctl_cpu_policy
> >> xen_sysctl_cpu_policy_t;
> >> DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpu_polic
On 04/04/2019 15:27, Wei Liu wrote:
> On Fri, Mar 15, 2019 at 05:29:28PM +0100, Juergen Gross wrote:
>> On 15/03/2019 16:55, Andrew Cooper wrote:
>>> On 14/03/2019 11:59, Juergen Gross wrote:
@@ -1100,6 +1100,20 @@ typedef struct xen_sysctl_cpu_policy
xen_sysctl_cpu_policy_t;
DEFIN
On 03/04/2019 10:38, Jan Beulich wrote:
On 03.04.19 at 11:06, wrote:
>> On 03/04/2019 09:53, Jan Beulich wrote:
>> On 02.04.19 at 21:57, wrote:
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -137,27 +137,35 @@ long arch_do_sysctl(
case XEN_SYSCTL_cpu_
The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon
Dhyana support to print the value of TOP_MEM2.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/cpu/mtrr/generic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu/mtrr/g
There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
this MSR will stop the Xen initialization process in some Hygon
systems or produce GPF(0). So directly return false in the function
probe_cpuid_faulting() if !cpu_has_hypervisor.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
The Hygon Dhyana CPU has the same speculative execution as AMD family
17h, so share AMD Retpoline and PTI mitigation code with Hygon Dhyana.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/spec_ctrl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arc
The machine check architecture for Hygon Dhyana CPU is similar to the
AMD family 17h one. Add vendor checking for Hygon Dhyana to share the
code path of AMD family 17h.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/cpu/common.c | 3 ++-
xen/arch/x86/cpu/mcheck/amd_no
As Hygon Dhyana CPU share similar PMU architecture with AMD family
17h one, so add Hygon Dhyana support in vpmu_arch_initialise() and
vpmu_init() by sharing AMD code path.
Split the common part in amd_vpmu_init() to a static function
_vpmu_init(), making AMD and Hygon to call the shared function t
Add Hygon Dhyana support to the acpi cpufreq and cpuidle subsystems by
using the code path of AMD.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/acpi/cpu_idle.c | 3 ++-
xen/arch/x86/acpi/cpufreq/cpufreq.c | 8 +---
xen/arch/x86/acpi/cpufreq/powernow.c | 3 ++-
3 fil
The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
counter MSRs, hardware configuration MSR, MMIO configuration base address
MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to the
PV emulation infrastructure by using the code path of AMD.
Signed-off-by: Pu
Add Hygon Dhyana support to use modern APIC.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/apic.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index e6130cf..65228cb 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@
Add Hygon Dhyana support to handle HyperTransport range.
Also loading a nul selector does not clear bases and limits on Hygon
CPUs, so add Hygon Dhyana support to the function preload_segment.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/dom0_build.c | 3 ++-
xen/arch/x86/domai
The IOMMU architecture for the Hygon Dhyana CPU is similar to the AMD
family 17h one. So add Hygon Dhyana support to it by sharing the code
path of AMD.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/include/asm-x86/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/include/as
The Hygon Dhyana family 18h processor shares the same cpuid leaves as
the AMD family 17h one. So add Hygon Dhyana support to caculate the
cpuid policies as the AMD CPU does.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/cpuid.c | 10 +++---
1 file changed, 7 insertions(+), 3
Add Hygon Dhyana support to update cpuid info for creating PV guest.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/domctl.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9bf2d08..19b7bdd 1006
Hi,
I am not sure why I end up to be CCed on the cover letter when I am not CCed on
the rest of series.
Cheers,
On 04/04/2019 14:44, Pu Wen wrote:
As a new x86 CPU vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
is a joint venture between AMD and Haiguang Information Technology Co.,
Ltd.
Add Hygon Dhyana support to caculate the cpuid policies for creating PV
or HVM guest by using the code path of AMD.
Signed-off-by: Pu Wen
---
tools/libxc/xc_cpuid_x86.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpu
Add x86 architecture support for a new processor: Hygon Dhyana Family
18h. To make Hygon initialization flow more clear, carve out code from
amd.c into a separate file hygon.c, and remove unnecessary code for
Hygon Dhyana.
To identify Hygon Dhyana CPU, add a new vendor type X86_VENDOR_HYGON
and ve
The Hygon Dhyana processor has the methold to get the last exception
source IP from MSR_01DD. So add support for it if the boot param
ler is true.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/traps.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/x86/traps.c
As a new x86 CPU vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
is a joint venture between AMD and Haiguang Information Technology Co.,
Ltd., aims at providing high performance x86 processors for China
server market.
The first generation Hygon processor(Dhyana) originates from AMD
technology
At the moment, xen/lib/x86 is covered by the "REST". However, this is
x86-only, so this can fall under the x86 maintainership.
Signed-off-by: Julien Grall
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ba7527c423..a9929a91de 100644
--- a/MAINT
On 04/04/2019 14:45, Pu Wen wrote:
> index 774ceac..75fefcf 100644
> --- a/xen/include/asm-x86/x86-vendors.h
> +++ b/xen/include/asm-x86/x86-vendors.h
> @@ -30,6 +30,11 @@
> #define X86_VENDOR_SHANGHAI_ECX 0x20206961U
> #define X86_VENDOR_SHANGHAI_EDX 0x68676e61U
>
> -#define X86_VENDOR_NUM 5
>
Signed-off-by: Wei Liu
---
Cc: DavidWang
Or perhaps it should have been Zhaoxin?
---
xen/arch/x86/cpu/shanghai.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpu/shanghai.c b/xen/arch/x86/cpu/shanghai.c
index 24af5c8259..36c1763c81 100644
--- a/xen/arch/x86/c
It's not used outside of schedule.c.
Signed-off-by: Wei Liu
---
xen/common/schedule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 26298c09fc..39b87a7682 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -
>>> On 04.04.19 at 16:04, wrote:
> At the moment, xen/lib/x86 is covered by the "REST". However, this is
> x86-only, so this can fall under the x86 maintainership.
>
> Signed-off-by: Julien Grall
Acked-by: Jan Beulich
Thanks for noticing. Would you mind adding xen/include/xen/lib/x86/
at this
On 04/04/2019 15:04, Julien Grall wrote:
> At the moment, xen/lib/x86 is covered by the "REST". However, this is
> x86-only, so this can fall under the x86 maintainership.
>
> Signed-off-by: Julien Grall
Reviewed-by: Andrew Cooper
Sorry - this is almost certainly my fault
_
On Thu, Apr 04, 2019 at 03:18:49PM +0100, Andrew Cooper wrote:
> On 04/04/2019 15:11, Wei Liu wrote:
> > Signed-off-by: Wei Liu
>
> Sadly not. This is a char[8] field (so loses the \0 terminator), which
> then gets passed to %s
>
> I've got an overhaul to this area of code in the works, and am
Hi,
On 04/04/2019 15:19, Jan Beulich wrote:
On 04.04.19 at 16:04, wrote:
At the moment, xen/lib/x86 is covered by the "REST". However, this is
x86-only, so this can fall under the x86 maintainership.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
Thanks for noticing. Would you mind ad
>>> On 04.04.19 at 16:11, wrote:
> --- a/xen/arch/x86/cpu/shanghai.c
> +++ b/xen/arch/x86/cpu/shanghai.c
> @@ -16,7 +16,7 @@ static void init_shanghai(struct cpuinfo_x86 *c)
> }
>
> static const struct cpu_dev shanghai_cpu_dev = {
> -.c_vendor = " Shang",
> +.c_vendor = "Shanghai"
>>> On 04.04.19 at 16:20, wrote:
> On 04/04/2019 15:19, Jan Beulich wrote:
> On 04.04.19 at 16:04, wrote:
>>> At the moment, xen/lib/x86 is covered by the "REST". However, this is
>>> x86-only, so this can fall under the x86 maintainership.
>>>
>>> Signed-off-by: Julien Grall
>>
>> Acked-by
On 04/04/2019 15:11, Wei Liu wrote:
> Signed-off-by: Wei Liu
Sadly not. This is a char[8] field (so loses the \0 terminator), which
then gets passed to %s
I've got an overhaul to this area of code in the works, and am planning
to remove this field entirely,
~Andrew
___
On 04/04/2019 15:19, Wei Liu wrote:
> On Thu, Apr 04, 2019 at 03:18:49PM +0100, Andrew Cooper wrote:
>> On 04/04/2019 15:11, Wei Liu wrote:
>>> Signed-off-by: Wei Liu
>> Sadly not. This is a char[8] field (so loses the \0 terminator), which
>> then gets passed to %s
>>
>> I've got an overhaul to
>>> On 04.04.19 at 14:50, wrote:
> On 4/4/19 3:46 PM, Razvan Cojocaru wrote:
>> Before going into that, are we now certain that ALLOC is sufficient? I
>> believe it should be for _our_ use-cases, but we don't want to break
>> anyone's code. Maybe Tamas knows more about this.
>
> Sorry, I forgot
>>> On 04.04.19 at 15:09, wrote:
> I agree that it is confusing. It would be fine to UNSHARE here as well
> to keep things consistent but otherwise it's not really an issue as
> the entry type is checked later to ensure that this is a p2m_ram_rw
> entry. We are simply trying to keep mem_sharing an
flight 134375 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134375/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
Commit fd32dcfe ("x86/vmx: Don't leak EFER.NXE into guest context")
introduced a regression on Harpertown and earlier cores (Gen 1 VT-x)
where as soon as guest EFER becomes equal to Xen EFER
(almost any 64-bit VM) stale version of EFER is incorrectly
loaded into a guest causing almost immediate gue
On 04/04/2019 15:20, Julien Grall wrote:
> Hi,
>
> On 04/04/2019 15:19, Jan Beulich wrote:
> On 04.04.19 at 16:04, wrote:
>>> At the moment, xen/lib/x86 is covered by the "REST". However, this is
>>> x86-only, so this can fall under the x86 maintainership.
>>>
>>> Signed-off-by: Julien Grall
On Thu, Apr 4, 2019 at 8:36 AM Jan Beulich wrote:
>
> >>> On 04.04.19 at 15:09, wrote:
> > I agree that it is confusing. It would be fine to UNSHARE here as well
> > to keep things consistent but otherwise it's not really an issue as
> > the entry type is checked later to ensure that this is a p2
>>> On 04.04.19 at 16:43, wrote:
> On Thu, Apr 4, 2019 at 8:36 AM Jan Beulich wrote:
>>
>> >>> On 04.04.19 at 15:09, wrote:
>> > I agree that it is confusing. It would be fine to UNSHARE here as well
>> > to keep things consistent but otherwise it's not really an issue as
>> > the entry type is
On 04/04/2019 15:42, Igor Druzhinin wrote:
I'd add "entries" to the subject, which can be done on commit.
> Commit fd32dcfe ("x86/vmx: Don't leak EFER.NXE into guest context")
> introduced a regression on Harpertown and earlier cores (Gen 1 VT-x)
> where as soon as guest EFER becomes equal to Xen
>>> On 04.04.19 at 16:42, wrote:
> Commit fd32dcfe ("x86/vmx: Don't leak EFER.NXE into guest context")
> introduced a regression on Harpertown and earlier cores (Gen 1 VT-x)
> where as soon as guest EFER becomes equal to Xen EFER
> (almost any 64-bit VM) stale version of EFER is incorrectly
> load
> On Apr 4, 2019, at 3:36 PM, Jan Beulich wrote:
>
On 04.04.19 at 15:09, wrote:
>> I agree that it is confusing. It would be fine to UNSHARE here as well
>> to keep things consistent but otherwise it's not really an issue as
>> the entry type is checked later to ensure that this is a p2m_
> On Apr 4, 2019, at 3:13 PM, Wei Liu wrote:
>
> It's not used outside of schedule.c.
>
> Signed-off-by: Wei Liu
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-
On Thu, Apr 4, 2019 at 8:51 AM Jan Beulich wrote:
>
> >>> On 04.04.19 at 16:43, wrote:
> > On Thu, Apr 4, 2019 at 8:36 AM Jan Beulich wrote:
> >>
> >> >>> On 04.04.19 at 15:09, wrote:
> >> > I agree that it is confusing. It would be fine to UNSHARE here as well
> >> > to keep things consistent
The "call" variable comes from the user in privcmd_ioctl_hypercall().
It's an offset into the hypercall_page[] which has (PAGE_SIZE / 32)
elements. We need to put an upper bound on it to prevent an out of
bounds access.
Fixes: 1246ae0bb992 ("xen: add variable hypercall caller")
Signed-off-by: Dan
On 4/4/19 11:12 AM, Dan Carpenter wrote:
> The "call" variable comes from the user in privcmd_ioctl_hypercall().
> It's an offset into the hypercall_page[] which has (PAGE_SIZE / 32)
> elements. We need to put an upper bound on it to prevent an out of
> bounds access.
>
> Fixes: 1246ae0bb992 ("xen
flight 134267 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134267/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
Commit 540d5422 ("x86/vmx: Support removing MSRs from the host/guest
load/save lists") introduced infrastructure finally exposed by
commit fd32dcfe ("x86/vmx: Don't leak EFER.NXE into guest context")
that led to a functional regression on Harpertown and earlier cores
(Gen 1 VT-x) due to MSR count b
On Thu, Apr 04, 2019 at 09:48:13PM +0800, Pu Wen wrote:
> Add Hygon Dhyana support to caculate the cpuid policies for creating PV
> or HVM guest by using the code path of AMD.
>
> Signed-off-by: Pu Wen
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen
On 2019/4/4 22:07, Andrew Cooper wrote:
On 04/04/2019 14:45, Pu Wen wrote:
index 774ceac..75fefcf 100644
--- a/xen/include/asm-x86/x86-vendors.h
+++ b/xen/include/asm-x86/x86-vendors.h
@@ -30,6 +30,11 @@
#define X86_VENDOR_SHANGHAI_ECX 0x20206961U
#define X86_VENDOR_SHANGHAI_EDX 0x68676e61U
On 2019/4/5 0:38, Wei Liu wrote:
On Thu, Apr 04, 2019 at 09:48:13PM +0800, Pu Wen wrote:
Add Hygon Dhyana support to caculate the cpuid policies for creating PV
or HVM guest by using the code path of AMD.
Signed-off-by: Pu Wen
Acked-by: Wei Liu
Thanks.
--
Regards,
Pu Wen
___
On 2019/4/4 22:08, Julien Grall wrote:
Hi,
I am not sure why I end up to be CCed on the cover letter when I am not CCed on
the rest of series.
The patch 01/15 of the series is CCed to you. :)
--
Regards,
Pu Wen
___
Xen-devel mailing list
Xen-devel@
On 04/04/2019 17:47, Pu Wen wrote:
On 2019/4/4 22:08, Julien Grall wrote:
Hi,
I am not sure why I end up to be CCed on the cover letter when I am not CCed on
the rest of series.
The patch 01/15 of the series is CCed to you. :)
I did notice it afterwards. But the code is only x86 specific.
.git
tags/pull-xen-20190404
for you to fetch changes up to 2bcd05cf24a7de34e7e265247c010977e43f40bc:
xen-block: scale sector based quantities correctly (2019-04-04 18:00:07 +0100)
Xen queue
xen-b
From: Paul Durrant
The Xen blkif protocol requires that sector based quantities should be
interpreted strictly as multiples of 512 bytes. Specifically:
"first_sect and last_sect in blkif_request_segment, as well as
sector_number in blkif_request, are always expressed in 512-byte units."
Commit
From: Paul Durrant
...and properly enable it when synthesizing a drive.
The Xen toolstack sets 'discard-enable' to '1' in xenstore when it wants
to enable discard on a specified image. The code in
xen_block_drive_create() correctly parses this and uses it to set
'discard' to 'unmap' for the file
### Attendees
Lars Kurth, Wei Liu, George Dunlap, Paul Durrant, Andy Cooper (Citrix)
Juergen Gross, Jan Beulich (Suse)
Brian Woods (AMD)
Tamas K Lengyel (Intel)
Daniel Smith (Apertus)
Christopher Clark (OpenXT Project)
Julien Grall (Arm)
Rich Persaud (OpenXT)
### Actions not yet resolved
flight 134395 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134395/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
flight 134336 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134336/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 77b8255fbc4e7b9150b6fb509a3898ee93abc270
baseline version:
freebsd 06b01911768
On 16/10/2018 19:54, Andrew Cooper wrote:
> Hello,
>
> I realise this is an old CPU, but I've I've encountered a weird failure
> on it.
>
> Specifically:
>
> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 23 (0x17), Stepping 6
> (raw 00010676)
> [root@harpertown ~]# head /proc/cpuinfo
Just to foll
From: Chris Patterson
To enable it, set vga="virtio".
Default videoram for virtio-vga is set to match current
QEMU default with 256MB.
Signed-off-by: Chris Patterson
---
docs/man/xl.cfg.5.pod.in| 4 +++-
tools/libxl/libxl.h | 10 ++
tools/libxl/libxl_create.c | 9 ++
1 - 100 of 117 matches
Mail list logo
