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: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
>>
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 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.
> -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
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 ++
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
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
---
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
---
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:
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 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
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
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:
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 @@
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
> -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
>>> 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
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
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
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
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
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
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
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,
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
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
>>> 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
>
>
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
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
>
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:
>>> 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
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
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
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 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:
> > ---
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:
> > ---
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'
>>
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;
> >>
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
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
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
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 ++-
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
---
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.,
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
>>> 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 =
>>> 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
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
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
>>> 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 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:
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
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
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
>>> 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
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 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
>
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
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
---
>>> 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
>>
>>
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
> 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
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;
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
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 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 ++-
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:
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 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
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
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
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
---
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
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 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: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
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
> 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
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
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
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
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
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 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
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
/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-block fixes
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
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
From: Chris Patterson
It was honored in libxl__build_device_model_args_old(), but did not
transition to libxl__build_device_model_args_new().
The opengl flag is useful for SDL to toggle virgl when using virtio-vga.
To accomplish this, we also switch from the short-hand "-sdl" notation to
From: Pu Wen
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
cpu_dev.c_vendor[] is a char[8] array which is printed using %s in two
locations. This leads to subtle lack-of-NUL bugs when using an 8 character
vendor name.
Introduce x86_cpuid_vendor_to_str() to turn an x86_vendor into a printable
string, use it in the two locations that c_vendor is used, and
These helpers each fill in a single cpu_devs[] pointer, and since c/s
00b4f4d0f "x86/cpuid: Drop get_cpu_vendor() completely", this array is read
exactly once on boot.
Delete the hooks and cpu_devs[], and have early_cpu_detect() pick the
appropriate cpu_dev structure directly.
Signed-off-by:
Pu: I'm sorry to keep on breaking the code you're working, but I think the
changes here will simplify your Hygon series somewhat. See patch 3 for the
best example.
To apologise, I've also rebased your v5 Patch 1 over the changes here (patch 4
in this series), to save you the work. I'll also fix
1 - 100 of 114 matches
Mail list logo
