Re: [Xen-devel] [PATCH] x86/cpu: Support a new cpu vendor, which is Shanghai
>>> "Fiona Li(BJ-RD)" 04/10/18 3:08 AM >>>
>> +static void init_shanghai(struct cpuinfo_x86 *c) {
>> +uint64_t msr_ace,msr_rng;
>> +/* Test for Shanghai Extended CPUID information */
>> +if (cpuid_eax(0xC000) >= 0xC001) {
>> +/*Get Shanghai Extended function number */
>> +u32 extented_feature_flags = cpuid_edx(0xC001);
>> +
>> +/* enable ACE,if support ACE unit */
>> +if(ACE_PRESENT(extented_feature_flags) &&
>> !ACE_ENABLED(extented_feature_flags)){
>> +rdmsrl(MSR_ZX_ACE, msr_ace);
>> +/* enable ACE */
>> +wrmsrl(MSR_ZX_ACE, (msr_ace | ACE_FCR));
>>> +printk(KERN_INFO "CPU: Enabled ACE h/w crypto\n");
>> +}
>> +/* enable RNG,if support RNG unit */
>> +if (RNG_PRESENT(extented_feature_flags) &&
>> !RNG_ENABLED(extented_feature_flags)) {
>> +rdmsrl(MSR_ZX_RNG, msr_rng);
>> +/* enable RNG */
>> +wrmsrl(MSR_ZX_RNG, msr_rng | RNG_ENABLE);
>> +printk(KERN_INFO "CPU: Enabled h/w RNG\n");
>> +}
>> +}
>> +
>> +if (c->x86 == 0x6 && c->x86_model >= 0xf) {
>> +c->x86_cache_alignment = c->x86_clflush_size * 2;
>> +__set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
>> +}
>
>Is there a specification available anywhere for all of the above?
>[FionaLi]: Main usage of Zhaoxin platforms in recent years is for limited and
>embedded
>instead of distributed markets. So there is no such document for public access
>at
>present. But, Zhaoxin's x86 CPU is compatible with Intel x86 architecture. Its
>instruction
>sets are compatible with Intel. Furthermore, Zhaoxin's CPU virtualization tech
>and I/O
>virtualization tech are compatible with Intel VMX and VT-d respectively. So
>maybe we
>can refer to Intel manual at present.
Notw how I had said "for all of the above": The extensions are clearly not in
the Intel
docs, and the cache alignment and TSC properties aren't general x86 attributes
either.
>What about guests? How would they know these extensions are available for
>their use?
>[FionaLi]: My colleagues is committing code to Linux kernel and windows. Its
>extensions
>will be available to guests.
That wasn't the point of the question: Even with aware guest OSes you first of
all need
to make sure guests can actually obtain the respective CPUID leaves. Afaict the
C000 range will come out as all zeros for them without you doing something
about
it. It is also questionable whether blanket enabling of the features for all
guests is a
good step - I think this should be left to guest OSes (requiring you to
properly emulate
their MSR accesses within Xen, unless the MSRs can be made directly accessible
to
guests without security risks).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] BUG - 'xl restore' does not overwrite HVM
Hi with at least 1 version of Windows 10 (build 16299), the 'xl restore' command does not overwrite the previously running HVM. The symptoms are: 1) the restore appears to rapidly complete after approx 50% of the time 2) files created after the save in the running HVM are present after the restore 3) the Windows system tries to recover. I have tried restoring both with a shutdown of the Windows system or a destroy. In both cases the results are the same. I have listed some relevant info below. Any help would be appreciated. Thanks Peter My xen config is immediately below and the HVM config below that: root@debian:~# xl info host : debian release: 3.16.0-4-amd64 version: #1 SMP Debian 3.16.51-3 (2017-12-13) machine: x86_64 nr_cpus: 2 max_cpu_id : 3 nr_nodes : 1 cores_per_socket : 2 threads_per_core : 1 cpu_mhz: 2926 hw_caps: bfebfbff:20100800::0900:0408e3bd::0001: virt_caps : hvm total_memory : 4060 free_memory: 2248 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 4 xen_extra : .1 xen_version: 4.4.1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : xen_commandline: placeholder cc_compiler: gcc (Debian 4.9.2-10) 4.9.2 cc_compile_by : ian.jackson cc_compile_domain : eu.citrix.com cc_compile_date: Thu Sep 7 18:01:06 UTC 2017 xend_config_format : 4 Config: #kernel=@/usr/lib/xen-4.0/boot/hvmloader@ builder = 'hvm' memory = 2048 vcpus = 1 name="W10N" vif = ['bridge=xenbr0'] #disk = ['phy:/dev/vg0/W10N,xvda,w','file:/media/usb/isos/windows10_16299.iso,hdc:cdrom,r'] disk = ['phy:/dev/vg0/W10N,xvda,w','file:/root/windows10_16299.iso,hdc:cdrom,r'] acpi = 1 boot = "cdn" sdl = 0 serial = 'pty' usb = 1 keymap="en-gb" vnc = 1 vnclisten = '' vncpasswd = "" root@debian:~# Peter McLaren ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] drm/xen-front: use simple display pipe prepare_fb helper
On 04/09/2018 11:51 AM, Daniel Vetter wrote:
I missed this one because on an older tree.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 0bd6681fa4f3..a3479eb72d79 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -226,12 +226,6 @@ static bool display_send_page_flip(struct
drm_simple_display_pipe *pipe,
return false;
}
-static int display_prepare_fb(struct drm_simple_display_pipe *pipe,
- struct drm_plane_state *plane_state)
-{
- return drm_gem_fb_prepare_fb(&pipe->plane, plane_state);
-}
-
static void display_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *old_plane_state)
{
@@ -294,7 +288,7 @@ static const struct drm_simple_display_pipe_funcs
display_funcs = {
.mode_valid = display_mode_valid,
.enable = display_enable,
.disable = display_disable,
- .prepare_fb = display_prepare_fb,
+ .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
.update = display_update,
};
Thank you,
Reviewed-by: Oleksandr Andrushchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 122153: regressions - FAIL
flight 122153 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122153/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 121876 build-armhf 6 xen-buildfail REGR. vs. 121876 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen aaae6290965b1434ae41e08b808bf5a59e6cf93e baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 121876 2018-04-05 10:04:25 Z4 days Failing since121889 2018-04-05 13:02:10 Z4 days 42 attempts Testing same since 122146 2018-04-09 20:01:28 Z0 days4 attempts People who touched revisions under test: Amit Singh Tomar Andre Przywara Andre Pzywara Andrew Cooper Boris Ostrovsky George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Marcello Seri Marcus of Wetware Labs Marek Marczykowski-Górecki Petre Eftime Razvan Cojocaru Stefano Stabellini Tim Deegan Wei Liu jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 776 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/pvh: Indicate XENFEAT_linux_rsdp_unrestricted to Xen
On 09/04/18 20:51, Boris Ostrovsky wrote:
> Pre-4.17 kernels ignored start_info's rsdp_paddr pointer and instead
> relied on finding RSDP in standard location in BIOS RO memory. This
> has worked since that's where Xen used to place it.
>
> However, with recent Xen change (commit 4a5733771e6f ("libxl: put RSDP
> for PVH guest near 4GB")) it prefers to keep RSDP at a "non-standard"
> address. Even though as of commit b17d9d1df3c3 ("x86/xen: Add pvh
> specific rsdp address retrieval function") Linux is able to find RSDP,
> for back-compatibility reasons we need to indicate to Xen that we can
> handle this, an we do so by setting XENFEAT_linux_rsdp_unrestricted
> flag in ELF notes.
>
> (Also take this opportunity and sync features.h header file with Xen)
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 0/5] sndif: add explicit back and front synchronization
Konrad? On 04/03/2018 08:37 AM, Oleksandr Andrushchenko wrote: ping On 03/27/2018 08:41 AM, Oleksandr Andrushchenko wrote: Hi, Konrad! Could you please review? Thank you, Oleksandr On 03/21/2018 09:25 AM, Oleksandr Andrushchenko wrote: On 03/21/2018 09:20 AM, Takashi Iwai wrote: On Wed, 21 Mar 2018 08:15:36 +0100, Oleksandr Andrushchenko wrote: On 03/20/2018 10:22 PM, Takashi Iwai wrote: On Mon, 19 Mar 2018 08:22:19 +0100, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello, all! In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - bump protocol version to 2 - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events - add XENSND_OP_HW_PARAM_QUERY request to read/update stream configuration space: request passes desired intervals/formats for the stream parameters and the response returns allowed intervals and formats mask that can be used. Changes since v2: 1. Konrad's r-b tag for version patch 2. MAJOR: changed req/resp/evt packet sizes from 32 to 64 octets 3. Reworked XENSND_OP_HW_PARAM_QUERY so it now sends all parameters at once, allowing to check all the configuration space. 4. Minor documentation cleanup (added missed "reserved" fields) Changes since v1: 1. Changed protocol version definition from string to integer, so it can easily be used in comparisons. Konrad, I have removed your r-b tag for the reason of this change. 2. In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used. Parameters supported by this request/response: - format mask - sample rate interval - number of channels interval - buffer size, interval, frames - period size, interval, frames I can't judge exactly about the protocol without the actual FE/BE implementations, but the change looks good to me, especially if you've already tested something. Thank you, I have tested the changes and need them to start upstreaming the frontend driver used to test the protocol. Do you mind if I put your Acked-by (or you prefer Reviewed-by?) tag to these patches: [PATCH v3 4/5] sndif: Add explicit back and front synchronization [PATCH v3 5/5] sndif: Add explicit back and front parameter negotiation Sure, feel free to take my ack: Reviewed-by: Takashi Iwai Thank you Takashi Please note, that the changes first to be merged into Xen and then I'll prepare the same, but for the kernel If other people have no concern, let's go ahead with FE/BE stuff. Konrad, are you ok with the changes? thanks, Takashi Thank you, Oleksandr ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 122129: tolerable FAIL
flight 122129 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/122129/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 122104 pass in 122129 test-amd64-amd64-xl-qcow215 guest-localmigrate fail pass in 122104 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122104 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122104 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122104 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122104 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122104 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122104 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122104 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122104 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122104 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122104 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: xen 451004603247205467ec34b366b4cfa3814a5d95 baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 122129 2018-04-09 09:48:42 Z0 days Testing same since (not found) 0 attempts jobs: build
[Xen-devel] [xen-unstable-smoke test] 122152: regressions - FAIL
flight 122152 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122152/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 121876 build-armhf 6 xen-buildfail REGR. vs. 121876 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen aaae6290965b1434ae41e08b808bf5a59e6cf93e baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 121876 2018-04-05 10:04:25 Z4 days Failing since121889 2018-04-05 13:02:10 Z4 days 41 attempts Testing same since 122146 2018-04-09 20:01:28 Z0 days3 attempts People who touched revisions under test: Amit Singh Tomar Andre Przywara Andre Pzywara Andrew Cooper Boris Ostrovsky George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Marcello Seri Marcus of Wetware Labs Marek Marczykowski-Górecki Petre Eftime Razvan Cojocaru Stefano Stabellini Tim Deegan Wei Liu jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 776 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/cpu: Support a new cpu vendor, which is Shanghai
Hi Jan,
Thanks for your reply. I want to give some explanation as follows.
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, March 23, 2018 11:32 PM
To: Fionali
Cc: xen-devel@lists.xenproject.org; Fiona Li(BJ-RD)
Subject: Re: [PATCH] x86/cpu: Support a new cpu vendor,which is Shanghai
>>> On 23.03.18 at 12:28, wrote:
> From: FionaLi
>
> Signed-off-by: Fiona Li
First of all, please shorten the subject and put a fair part of what you had
there in the description.
[FionaLi]:Thanks, I will revise that in next version of the patch.
Then you talk about a VT-d compatible IOMMU, but not about VMX or some other
CPU side hardware virtualization. Is that really not available?
[FionaLi]: My description about the IOMMU in subject is inexact. ZhaoXin is a
x86 IC designer. Its SOC products support both CPU virtualization and I/O
virtualization, which are compatible with Intel VMX and VT-d respectively.
Whose cpu vendor id is 'Shanghai'.
Further it would help if the mail address you send from was in sync (or at
least allow some matching with) the one in the From and S-o-b.
[FionaLi]: To solve this problem, I will use another email
address(davidw...@zhaoxin.com) to resubmit my patch. If necessary, please
abandon current patch and subject. I am sorry for the trouble.
> --- a/xen/arch/x86/cpu/Makefile
> +++ b/xen/arch/x86/cpu/Makefile
> @@ -5,6 +5,7 @@ obj-y += amd.o
> obj-y += centaur.o
> obj-y += common.o
> obj-y += intel.o
> +obj-y += shanghai.o
Please put where it belongs alphabetically.
> --- /dev/null
> +++ b/xen/arch/x86/cpu/shanghai.c
> @@ -0,0 +1,61 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "cpu.h"
> +
> +#define ACE_PRESENT(x) ((x)&(1U<<6)) #define ACE_ENABLED(x)
> +((x)&(1U<<7))
> +#define ACE_FCR(1U << 28)/* MSR_ZX_ACE Advanced Cryprography Engine */
> +
> +#define RNG_PRESENT(x) ((x)&(1U<<6)) #define RNG_ENABLED(x)
> +((x)&(1U<<7))
> +#define RNG_ENABLE(1U << 6)/* MSR_ZX_RNG Random Number Generator */
Style: Blanks around binary operators please.
> +
> +
> +
Please don't put multiple consecutive blank lines anywhere.
> +static void init_shanghai(struct cpuinfo_x86 *c) {
> +uint64_t msr_ace,msr_rng;
> +/* Test for Shanghai Extended CPUID information */
> +if (cpuid_eax(0xC000) >= 0xC001) {
> +/*Get Shanghai Extended function number */
> +u32 extented_feature_flags = cpuid_edx(0xC001);
> +
> +/* enable ACE,if support ACE unit */
> +if(ACE_PRESENT(extented_feature_flags) &&
> !ACE_ENABLED(extented_feature_flags)){
> +rdmsrl(MSR_ZX_ACE, msr_ace);
> +/* enable ACE */
> +wrmsrl(MSR_ZX_ACE, (msr_ace | ACE_FCR));
> +printk(KERN_INFO "CPU: Enabled ACE h/w crypto\n");
> +}
> +/* enable RNG,if support RNG unit */
> +if (RNG_PRESENT(extented_feature_flags) &&
> !RNG_ENABLED(extented_feature_flags)) {
> +rdmsrl(MSR_ZX_RNG, msr_rng);
> +/* enable RNG */
> +wrmsrl(MSR_ZX_RNG, msr_rng | RNG_ENABLE);
> +printk(KERN_INFO "CPU: Enabled h/w RNG\n");
> +}
> +}
> +
> +if (c->x86 == 0x6 && c->x86_model >= 0xf) {
> +c->x86_cache_alignment = c->x86_clflush_size * 2;
> +__set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> +}
Is there a specification available anywhere for all of the above?
[FionaLi]: Main usage of Zhaoxin platforms in recent years is for limited and
embedded instead of distributed markets. So there is no such document for
public access at present. But, Zhaoxin's x86 CPU is compatible with Intel x86
architecture. Its instruction sets are compatible with Intel. Furthermore,
Zhaoxin's CPU virtualization tech and I/O virtualization tech are compatible
with Intel VMX and VT-d respectively. So maybe we can refer to Intel manual at
present.
What about guests? How would they know these extensions are available for their
use?
[FionaLi]: My colleagues is committing code to Linux kernel and windows. Its
extensions will be available to guests.
> --- a/xen/include/asm-x86/iommu.h
> +++ b/xen/include/asm-x86/iommu.h
> @@ -53,6 +53,7 @@ static inline const struct iommu_ops
> *iommu_get_ops(void) {
> switch ( boot_cpu_data.x86_vendor )
> {
> +case X86_VENDOR_SHANGHAI:
> case X86_VENDOR_INTEL:
> return &intel_iommu_ops;
> case X86_VENDOR_AMD:
> @@ -68,6 +69,7 @@ static inline int iommu_hardware_setup(void) {
> switch ( boot_cpu_data.x86_vendor )
> {
> +case X86_VENDOR_SHANGHAI:
> case X86_VENDOR_INTEL:
> return intel_vtd_setup();
> case X86_VENDOR_AMD:
Please don't put new entries first.
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -293,6 +293,10 @@
> #define MSR_TMTA_LRTI_READOUT0x80868018
> #define MSR_TMTA_LRTI_VOLT_MHZ0x8086801a
>
> +/* Shanghai ZhaoXin defined MSRs*/
> +#define MSR_ZX_ACE0x1107
> +#define MSR_ZX_RNG0x110b
As Wei has already indicated, we'd prefer consistent names.
Either ZX / ZhaoXin everywhere, or Shanghai. If one of them is just a code
name, the per
[Xen-devel] [xen-unstable-smoke test] 122150: regressions - FAIL
flight 122150 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122150/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 121876 build-armhf 6 xen-buildfail REGR. vs. 121876 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen aaae6290965b1434ae41e08b808bf5a59e6cf93e baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 121876 2018-04-05 10:04:25 Z4 days Failing since121889 2018-04-05 13:02:10 Z4 days 40 attempts Testing same since 122146 2018-04-09 20:01:28 Z0 days2 attempts People who touched revisions under test: Amit Singh Tomar Andre Przywara Andre Pzywara Andrew Cooper Boris Ostrovsky George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Marcello Seri Marcus of Wetware Labs Marek Marczykowski-Górecki Petre Eftime Razvan Cojocaru Stefano Stabellini Tim Deegan Wei Liu jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 776 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-next test] 122127: regressions - FAIL
flight 122127 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/122127/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 7 xen-boot fail REGR. vs. 122111 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 122111 test-armhf-armhf-xl-xsm 10 debian-install fail REGR. vs. 122111 test-armhf-armhf-libvirt-xsm 10 debian-install fail REGR. vs. 122111 test-armhf-armhf-xl-credit2 10 debian-install fail REGR. vs. 122111 test-armhf-armhf-xl-arndale 10 debian-install fail REGR. vs. 122111 test-armhf-armhf-xl 10 debian-install fail REGR. vs. 122111 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 10 debian-install fail REGR. vs. 122111 Tests which did not succeed, but are not blocking: test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail blocked in 122111 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 122111 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail blocked in 122111 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail blocked in 122111 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122111 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122111 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122111 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122111 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122111 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linux231c7b7d0d9f14d33da46b3d74a73847a342ad28 baseline version: linuxf8cf2f16a7c95acce497bfafa90e7c6d8397d653 Last test of basis (not found) Failing since (not found) Testing same since 122127 2018-04-09 09:24:39 Z0 days1 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt
[Xen-devel] [xen-unstable-smoke test] 122146: regressions - FAIL
flight 122146 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122146/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 121876 test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR. vs. 121876 build-armhf 6 xen-buildfail REGR. vs. 121876 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen aaae6290965b1434ae41e08b808bf5a59e6cf93e baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 121876 2018-04-05 10:04:25 Z4 days Failing since121889 2018-04-05 13:02:10 Z4 days 39 attempts Testing same since 122146 2018-04-09 20:01:28 Z0 days1 attempts People who touched revisions under test: Amit Singh Tomar Andre Przywara Andre Pzywara Andrew Cooper Boris Ostrovsky George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Marcello Seri Marcus of Wetware Labs Marek Marczykowski-Górecki Petre Eftime Razvan Cojocaru Stefano Stabellini Tim Deegan Wei Liu jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 fail test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 776 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 122141: regressions - FAIL
flight 122141 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122141/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 121876 build-armhf 6 xen-buildfail REGR. vs. 121876 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen dba899de14989b3dff78009404ed891da7fefdc1 baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 121876 2018-04-05 10:04:25 Z4 days Failing since121889 2018-04-05 13:02:10 Z4 days 38 attempts Testing same since 122136 2018-04-09 14:02:06 Z0 days2 attempts People who touched revisions under test: Amit Singh Tomar Andre Przywara Andre Pzywara Andrew Cooper George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Marcello Seri Marcus of Wetware Labs Marek Marczykowski-Górecki Petre Eftime Razvan Cojocaru Stefano Stabellini Tim Deegan Wei Liu jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 750 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 122125: regressions - FAIL
flight 122125 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122125/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 6 kernel-build fail REGR. vs. 121320 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 121320 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 121320 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 121320 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 121320 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass build-arm64-pvops 6 kernel-build fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linux3f2968010fda1eb82de1ff79c7384e3329f96673 baseline version: linux9764536dc592144beee43c987fef45d2e91ca55c Last test of basis 121320 2018-03-28 02:34:55 Z 12 days Testing same since 122094 2018-04-08 10:18:48 Z1 days3 attempts People who touched revisions under test: Alexander Gerasiov Alexey Kodanev Andrew Morton Andri Yngvason Andy Lutomirski Arend van Spriel Arkadi Sharshevsky Arvind Yadav Ben Hutchings Boris Brezillon Christophe JAILLET Clemens Werther Colin Ian King Dan Carpenter Daniel Mentz Daniel Vetter David Ahern David Lechner David S. Miller Dennis Wassenberg Dmitry Torokhov Doug Gilbert Eric Biggers Eric Dumazet Felipe Balbi Felipe Balbi Felipe F. Tonello Florian Fainelli Florian Westphal Greg Hackmann Greg Kroah-Hartman Guillaume Nault Guoqing Jiang Hans de Goede Hans Verkuil Hans Verkuil Herbert Xu Ingo Molnar James Chapman Jens Axboe Jiri Pirko Johan Hovold Johannes Thumshirn Johannes Weiner Ju Hyung Park Julian Wiedmann Kai-Heng Feng Kalle Valo Keerthy Kirill Marinushkin Krzysztof Opasiak Krzysztof Opasiak Linus Torvalds Linus Walleij Lorenzo Bianconi Major Hayden Marc Kleine-Budde Marcel Ho
[Xen-devel] [ovmf baseline-only test] 74565: all pass
This run is configured for baseline tests only. flight 74565 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74565/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 95cc4962167572089a99be324574094ba22415ad baseline version: ovmf e037e88cd81d4ac63dd627719c87c305bf0b439e Last test of basis74561 2018-04-08 13:21:46 Z1 days Testing same since74565 2018-04-09 12:19:59 Z0 days1 attempts People who touched revisions under test: Feng, YunhuaX Yunhua Feng jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 95cc4962167572089a99be324574094ba22415ad Author: Feng, YunhuaX Date: Wed Apr 4 13:53:13 2018 +0800 BaseTools: Remove FdfParserLite.py from source since it is not used Remove FdfParserLite.py from source code since it is not used. Cc: Liming Gao Cc: Yonghong Zhu Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yunhua Feng Reviewed-by: Yonghong Zhu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE
On 04/09/2018 12:36 PM, Boris Ostrovsky wrote:
> On 04/09/2018 05:36 AM, Paul Durrant wrote:
>> My recent Xen patch series introduces a new HYPERVISOR_memory_op to
>> support direct priv-mapping of certain guest resources (such as ioreq
>> pages, used by emulators) by a tools domain, rather than having to access
>> such resources via the guest P2M.
>>
>> This patch adds the necessary infrastructure to the privcmd driver and
>> Xen MMU code to support direct resource mapping.
>>
>> NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now
>> allow a PV tools domain to map guest pages either by GFN or MFN, thus
>> the term 'mfn' has been swapped for 'pfn' in the lower layers of the
>> remap code.
>>
>> Signed-off-by: Paul Durrant
> Reviewed-by: Boris Ostrovsky
>
> I think this will have to wait until 4.18 though, it's somewhat late for
> current merge window right now.
Warns on 32-bit ARM build:
CC drivers/xen/privcmd.o
In file included from /data/upstream/linux-xen/include/linux/kernel.h:14:0,
from /data/upstream/linux-xen/drivers/xen/privcmd.c:11:
/data/upstream/linux-xen/drivers/xen/privcmd.c: In function
‘privcmd_ioctl_mmap_resource’:
/data/upstream/linux-xen/drivers/xen/privcmd.c:788:33: warning: cast to
pointer from integer of different size [-Wint-to-pointer-cast]
pr_info("pfn[%u] = %p\n", i, (void *)pfns[i]);
^
/data/upstream/linux-xen/include/linux/printk.h:308:34: note: in
definition of macro ‘pr_info’
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~
AR drivers/xen/xen-privcmd.o
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 122115: FAIL
flight 122115 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/122115/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl broken in 122080 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 4 host-install(4) broken in 122080 pass in 122115 test-armhf-armhf-libvirt 5 host-ping-check-native fail pass in 122080 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail in 122080 baseline untested test-armhf-armhf-libvirt 14 saverestore-support-check fail in 122080 like 120095 test-armhf-armhf-libvirt13 migrate-support-check fail in 122080 never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 120095 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120095 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120095 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 120095 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120095 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: qemuu08e173f29461396575c85510eb41474b993cb1fb baseline version: qemuu6697439794f72b3501ee16bb95d16854f9981421 Last test of basis 120095 2018-02-28 13:46:33 Z 40 days Failing since120146 2018-03-02 10:10:57 Z 38 days 26 attempts Testing same since 121998 2018-04-07 00:57:17 Z2 days3 attempts People who touched revisions under test: Alberto Garcia Alex Bennée Alex Bennée
[Xen-devel] [PATCH] xen/pvh: Indicate XENFEAT_linux_rsdp_unrestricted to Xen
Pre-4.17 kernels ignored start_info's rsdp_paddr pointer and instead
relied on finding RSDP in standard location in BIOS RO memory. This
has worked since that's where Xen used to place it.
However, with recent Xen change (commit 4a5733771e6f ("libxl: put RSDP
for PVH guest near 4GB")) it prefers to keep RSDP at a "non-standard"
address. Even though as of commit b17d9d1df3c3 ("x86/xen: Add pvh
specific rsdp address retrieval function") Linux is able to find RSDP,
for back-compatibility reasons we need to indicate to Xen that we can
handle this, an we do so by setting XENFEAT_linux_rsdp_unrestricted
flag in ELF notes.
(Also take this opportunity and sync features.h header file with Xen)
Signed-off-by: Boris Ostrovsky
---
XENFEAT_linux_rsdp_unrestricted inly makes sense for CONFIG_XEN_PVH but
I set it uncoditionally to avoid what I think is unnecessary ifdefery.
arch/x86/xen/xen-head.S | 4 +++-
include/xen/interface/features.h | 23 +++
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 96f26e0..5077ead 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -89,7 +89,9 @@ END(hypercall_page)
ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,
.ascii "!writable_page_tables|pae_pgdir_above_4gb")
ELFNOTE(Xen, XEN_ELFNOTE_SUPPORTED_FEATURES,
- .long (1 << XENFEAT_writable_page_tables) | (1 << XENFEAT_dom0))
+ .long (1 << XENFEAT_writable_page_tables) | \
+ (1 << XENFEAT_dom0) | \
+ (1 << XENFEAT_linux_rsdp_unrestricted))
ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "yes")
ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic")
ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index 9b0eb57..6d1384a 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -42,6 +42,9 @@
/* x86: Does this Xen host support the MMU_PT_UPDATE_PRESERVE_AD hypercall? */
#define XENFEAT_mmu_pt_update_preserve_ad 5
+/* x86: Does this Xen host support the MMU_{CLEAR,COPY}_PAGE hypercall? */
+#define XENFEAT_highmem_assist 6
+
/*
* If set, GNTTABOP_map_grant_ref honors flags to be placed into guest kernel
* available pte bits.
@@ -60,6 +63,26 @@
/* operation as Dom0 is supported */
#define XENFEAT_dom0 11
+/* Xen also maps grant references at pfn = mfn.
+ * This feature flag is deprecated and should not be used.
+#define XENFEAT_grant_map_identity12
+ */
+
+/* Guest can use XENMEMF_vnode to specify virtual node for memory op. */
+#define XENFEAT_memory_op_vnode_supported 13
+
+/* arm: Hypervisor supports ARM SMC calling convention. */
+#define XENFEAT_ARM_SMCCC_supported 14
+
+/*
+ * x86/PVH: If set, ACPI RSDP can be placed at any address. Otherwise RSDP
+ * must be located in lower 1MB, as required by ACPI Specification for IA-PC
+ * systems.
+ * This feature flag is only consulted if XEN_ELFNOTE_GUEST_OS contains
+ * the "linux" string.
+ */
+#define XENFEAT_linux_rsdp_unrestricted 15
+
#define XENFEAT_NR_SUBMAPS 1
#endif /* __XEN_PUBLIC_FEATURES_H__ */
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11] x86/VT-x: Fix determination of EFER.LMA in vmcs_dump_vcpu()
The LMA setting comes from the entry controls.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
CC: Juergen Gross
This arguably wants backporting, so should go into 4.11 at this point. If
not, I'll queue it in x86-next for the 4.12 dev window.
---
xen/arch/x86/hvm/vmx/vmcs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 2c5ef36..70c2fb7 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1788,7 +1788,10 @@ void vmcs_dump_vcpu(struct vcpu *v)
vmentry_ctl = vmr32(VM_ENTRY_CONTROLS),
vmexit_ctl = vmr32(VM_EXIT_CONTROLS);
cr4 = vmr(GUEST_CR4);
-efer = vmr(GUEST_EFER);
+
+/* EFER.LMA is read as zero, and is loaded from vmentry_ctl on entry. */
+BUILD_BUG_ON(VM_ENTRY_IA32E_MODE << 1 != EFER_LMA);
+efer = vmr(GUEST_EFER) | ((vmentry_ctl & VM_ENTRY_IA32E_MODE) << 1);
printk("*** Guest State ***\n");
printk("CR0: actual=0x%016lx, shadow=0x%016lx, gh_mask=%016lx\n",
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: fix build after f20a6e309
On Mon, 9 Apr 2018, Wei Liu wrote:
> Commit f20a6e309 removed a parameter from smp_prepare_cpus but only
> the x86 parts were submitted and committed.
>
> Signed-off-by: Wei Liu
Reviewed-by: Stefano Stabellini
> ---
> Cc: Stefano Stabellini
> Cc: Julien Grall
> ---
> xen/arch/arm/setup.c | 2 +-
> xen/arch/arm/smpboot.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 6e49e8fd1f..1d6f6bf37e 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -804,7 +804,7 @@ void __init start_xen(unsigned long boot_phys_offset,
> local_irq_enable();
> local_abort_enable();
>
> -smp_prepare_cpus(cpus);
> +smp_prepare_cpus();
>
> initialize_keytable();
>
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 62f795f68e..b2116f0d2d 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -283,7 +283,7 @@ smp_get_max_cpus (void)
> }
>
> void __init
> -smp_prepare_cpus (unsigned int max_cpus)
> +smp_prepare_cpus(void)
> {
> cpumask_copy(&cpu_present_map, &cpu_possible_map);
>
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 122136: regressions - FAIL
flight 122136 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122136/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 121876 build-armhf 6 xen-buildfail REGR. vs. 121876 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen dba899de14989b3dff78009404ed891da7fefdc1 baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 121876 2018-04-05 10:04:25 Z4 days Failing since121889 2018-04-05 13:02:10 Z4 days 37 attempts Testing same since 122136 2018-04-09 14:02:06 Z0 days1 attempts People who touched revisions under test: Amit Singh Tomar Andre Przywara Andre Pzywara Andrew Cooper George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Marcello Seri Marcus of Wetware Labs Marek Marczykowski-Górecki Petre Eftime Razvan Cojocaru Stefano Stabellini Tim Deegan Wei Liu jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 750 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE
On 04/09/2018 05:36 AM, Paul Durrant wrote: > My recent Xen patch series introduces a new HYPERVISOR_memory_op to > support direct priv-mapping of certain guest resources (such as ioreq > pages, used by emulators) by a tools domain, rather than having to access > such resources via the guest P2M. > > This patch adds the necessary infrastructure to the privcmd driver and > Xen MMU code to support direct resource mapping. > > NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now > allow a PV tools domain to map guest pages either by GFN or MFN, thus > the term 'mfn' has been swapped for 'pfn' in the lower layers of the > remap code. > > Signed-off-by: Paul Durrant Reviewed-by: Boris Ostrovsky I think this will have to wait until 4.18 though, it's somewhat late for current merge window right now. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary
On 04/09/2018 12:08 PM, Wei Liu wrote:
> On Mon, Apr 09, 2018 at 10:24:59AM -0400, Boris Ostrovsky wrote:
>> Commit 4a5733771e6f ("libxl: put RSDP for PVH guest near 4GB") breaks
>> pre-4.17 Linux guests since they do not use start_info's rsdp_paddr
>> pointer and instread scan BIOS memory for RSDP signature.
>>
>> Introduce XENFEAT_rsdp_unrestricted feature flag that indicates whether
> I realise the name here is not updated. That can be done upon
> committing.
Please!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary
On Mon, Apr 09, 2018 at 10:24:59AM -0400, Boris Ostrovsky wrote:
> Commit 4a5733771e6f ("libxl: put RSDP for PVH guest near 4GB") breaks
> pre-4.17 Linux guests since they do not use start_info's rsdp_paddr
> pointer and instread scan BIOS memory for RSDP signature.
>
> Introduce XENFEAT_rsdp_unrestricted feature flag that indicates whether
> the guest can handle RSDP at locations pointed to by rsdp_paddr.
>
> Since only Linux PVH guests suffer from this problem (BSD has always
> relied on rsdp_paddr) we check this flag just for those guests. If the
> flag is not set we place RSDP in BIOS, as before.
>
> Signed-off-by: Boris Ostrovsky
LGTM:
Reviewed-by: Roger Pau Monné
Thanks!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary
On Mon, Apr 09, 2018 at 10:24:59AM -0400, Boris Ostrovsky wrote:
> Commit 4a5733771e6f ("libxl: put RSDP for PVH guest near 4GB") breaks
> pre-4.17 Linux guests since they do not use start_info's rsdp_paddr
> pointer and instread scan BIOS memory for RSDP signature.
>
> Introduce XENFEAT_rsdp_unrestricted feature flag that indicates whether
I realise the name here is not updated. That can be done upon
committing.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary
On 09/04/18 16:24, Boris Ostrovsky wrote:
> Commit 4a5733771e6f ("libxl: put RSDP for PVH guest near 4GB") breaks
> pre-4.17 Linux guests since they do not use start_info's rsdp_paddr
> pointer and instread scan BIOS memory for RSDP signature.
>
> Introduce XENFEAT_rsdp_unrestricted feature flag that indicates whether
> the guest can handle RSDP at locations pointed to by rsdp_paddr.
>
> Since only Linux PVH guests suffer from this problem (BSD has always
> relied on rsdp_paddr) we check this flag just for those guests. If the
> flag is not set we place RSDP in BIOS, as before.
>
> Signed-off-by: Boris Ostrovsky
> ---
> v2:
> * Renamed flag to XENFEAT_linux_rsdp_unrestricted
> * Clarified comment in features.h
>
> I did not include tags because of the changes but just in case ---
> here they are:
>
> Acked-by: George Dunlap
So again:
Reviewed-by: Juergen Gross
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] vhpet: add support for level triggered interrupts
>>> On 30.03.18 at 14:36, wrote:
> Level triggered interrupts are not an optional feature of HPET, and
> must be implemented in order to comply with the HPET specification.
>
> Implement them by adding a callback to the timer which sets the
> interrupt bit in the general interrupt status register. Further
> interrupts (in case of periodic mode) will not be injected until the
> bit is cleared.
>
> In order to reset the interrupts when the status bit is clear Xen must
> also detect accesses to such register.
s/detect/handle/ and s/such/the status/ ?
> --- a/xen/arch/x86/hvm/hpet.c
> +++ b/xen/arch/x86/hvm/hpet.c
> @@ -220,6 +220,17 @@ static void hpet_stop_timer(HPETState *h, unsigned int
> tn,
> hpet_get_comparator(h, tn, guest_time);
> }
>
> +static void hpet_timer_fired(struct vcpu *v, void *data)
No need for the hpet_ prefix when the function is static.
> +{
> +unsigned int tn = (unsigned int)data;
Most gcc versions I'm aware of will warn about casts between
pointers and integers of different size - the cast needs to be to
unsigned long (while the variable type can remain as is). Oddly
enough you go through unsigned long when casting in the other
direction.
> @@ -360,6 +377,19 @@ static int hpet_write(
> }
> break;
>
> +case HPET_STATUS:
> +/* write 1 to clear. */
> +while (new_val)
Missing blanks.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On Sun, 8 Apr 2018 23:38:31 +0300
Razvan Cojocaru wrote:
>I've noticed altp2m behaviour I can't explain yet - I'm not all that
>familiar with all the ways the new views corellate with the previous
>EPT-based "view 0".
>
>In short, if we create a new view and simply switch to it early in the
>boot process of the guest, something goes wrong and the guest either
>freezes, becomes unresponsive to input, or has something wrong with the
>display (most often the latter, with a black band on top of the image):
>
>https://ibb.co/eUPJ6c
>https://ibb.co/etCXXH
>
>That guest is a 64-bit Windows 7 system with nothing special about it.
>It's easy to reproduce this:
>
>1. Start the guest paused (I've used "xl create -p myguest.conf").
>2. Patch xen-access like this: https://pastebin.com/67PpQ9fu (just
>remove the part of the code that modifies the new view before switching
>to it).
>3. Hook xen-access to the guest ("./xen-access altp2m_write").
>4. Unpause the guest ("xl unpause ").
>
>I think that's a valid scenario and supposed to work.
>
>I've also noticed that if I wait to do this until the OS is
>up-and-running (e.g. after logging into Windows), there seems to be no
>problem. I don't know if this is just coincidence (as is bound to
>happen with race-condition situations), or means something, but I can
>get the problems every time when switching views early, and never when
>switching the views late.
>
>Suggestions on what the problem could be are, as always, greatly
>appreciated.
The difference between starting the domain paused and switching altp2m
views later (in this particular case) is likely the fact whether
the emulated LFB backing storage (aka VRAM) was "deployed" to the guest
domain or not.
QEMU uses special ranges to maintain the state of some emulated
devices with memories. These are VRAM and Option ROMs, but latter are
emulated as MMIO currently for some reason (either a bug or
intentionally). VRAM area is used to hold the LFB content for the
emulated videocard (stdvga/cirrus/etc) and its usage depends on whether
the emulated LFB is currently mapped or not.
When you start the domain paused, VRAM is not mapped to the guest
address space yet -- it is allocated to the location outside the guest
memory map, known to QEMU. In order to map VRAM to the guest's address
space, the emulated QEMU videocard needs to be initialized, which
happens when hvmloader or guest OS allocates MMIO BARs for the emulated
videocard.
Upon writing the corresponding BAR register, the VRAM area is relocated
to the guest's visible address space (via add_to_physmap hypercall).
Disabling MMIO decoding may cause to relocate the VRAM range back
to its hidden backing storage (again via add_to_physmap).
So, it's basically the same appearance of the problem of different
Xen/QEMU views on guest's memory layout.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86/vpt: execute callbacks for masked interrupts
>>> On 30.03.18 at 14:35, wrote:
> Execute periodic_time callbacks even if the interrupt is not actually
> injected because the IRQ is masked.
>
> Current callbacks from emulated timer devices only update emulated
> registers, which from my reading of the specs should happen regardless
> of whether the interrupt has been injected or not.
While generally I agree, it also means extra work done. Looking
at the PIT case, for example, there's no strict need to do the
update when the IRQ is masked, as the value being updated is
only used to subtract from get_guest_time()'s return value.
Similarly for the LAPIC case.
In the RTC case your change actually looks risky, due to the
pt_dead_ticks logic. I can't help getting the impression that the
IRQ being off for 10 ticks would lead to no RTC interrupts at all
anymore for the guest (until something resets that counter),
which seems wrong to me.
> @@ -282,6 +305,12 @@ int pt_update_irq(struct vcpu *v)
>
> if ( earliest_pt == NULL )
> {
> +/*
> + * NB: although the to_purge list is local, calls to
> + * destroy_periodic_time can still remove items from the list, hence
pt_adjust_vcpu() as well as it looks.
> + * the need to hold the lock while accessing it.
> + */
> +execute_callbacks(v, &to_purge);
> spin_unlock(&v->arch.hvm_vcpu.tm_lock);
> return -1;
> }
> @@ -290,6 +319,8 @@ int pt_update_irq(struct vcpu *v)
> irq = earliest_pt->irq;
> is_lapic = (earliest_pt->source == PTSRC_lapic);
>
> +execute_callbacks(v, &to_purge);
> +
> spin_unlock(&v->arch.hvm_vcpu.tm_lock);
It seems to me that with your addition some code restructuring
would actually be desirable, such that execute_callbacks() (and
the lock release) would occur just once. Perhaps the mid-function
return could be avoided altogether.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 7/7] xen/x86: use PCID feature
>>> On 09.04.18 at 16:33, wrote: > On 09/04/18 16:15, Jan Beulich wrote: > On 06.04.18 at 09:52, wrote: >>> @@ -100,12 +102,35 @@ void write_cr3_cr4(unsigned long cr3, unsigned long >>> cr4) >>> t = pre_flush(); >>> >>> if ( read_cr4() & X86_CR4_PGE ) >>> +/* >>> + * X86_CR4_PGE set means PCID being inactive. >>> + * We have to purge the TLB via flipping cr4.pge. >>> + */ >>> write_cr4(cr4 & ~X86_CR4_PGE); >>> +else if ( use_invpcid ) >>> +/* >>> + * If we are using PCID purge the TLB via INVPCID as loading cr3 >>> + * will affect the new PCID only. >>> + * If INVPCID is not supported we don't use PCIDs so loading cr3 >>> + * will purge the TLB (we are in the "global pages off" branch). >>> + * invpcid_flush_all_nonglobals() seems to be faster than >>> + * invpcid_flush_all(). >>> + */ >>> +invpcid_flush_all_nonglobals(); >>> >>> asm volatile ( "mov %0, %%cr3" : : "r" (cr3) : "memory" ); >>> >>> if ( read_cr4() != cr4 ) >>> write_cr4(cr4); >>> +else if ( old_pcid != (cr3 & X86_CR3_PCID_MASK) ) >>> +/* >>> + * Make sure no TLB entries related to the old PCID created between >>> + * flushing the TLB and writing the new %cr3 value remain in the >>> TLB. >>> + * Writing %cr3 is documented to be a speculation barrier, OTOH the >>> + * performance impact of the additional flush is next to invisible. >>> + * So better be save than sorry. >>> + */ >>> +invpcid_flush_single_context(old_pcid); >> >> I'm not really happy about this comment. The CR3 write being a >> speculation barrier is of no real interest here. Until the CPU's >> speculation logic reaches that insn, all sort of things can happen. >> We don't even know the exact code the compiler will generate, >> much less what that code will trigger inside the CPU. > > In case you are feeling strong regarding this comment I can > remove it. The first sentence is fine (and useful), so please don't drop it wholesale. >>> --- a/xen/include/asm-x86/x86-defns.h >>> +++ b/xen/include/asm-x86/x86-defns.h >>> @@ -45,7 +45,9 @@ >>> /* >>> * Intel CPU flags in CR3 >>> */ >>> -#define X86_CR3_NOFLUSH (_AC(1, ULL) << 63) >>> +#define X86_CR3_NOFLUSH(_AC(1, ULL) << 63) >>> +#define X86_CR3_ADDR_MASK (PAGE_MASK & PADDR_MASK & ~X86_CR3_NOFLUSH) >> >> Why still ~X86_CR3_NOFLUSH now that you use PADDR_MASK? > > I just want to make clear that NOFLUSH is not included. Would you > like a comment better? No - the involved symbol names together make clear that the NOFLUSH bit can't be included. The same bit can't possibly be part of the address _and_ be the signal to not flush. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] new config option vtsc_tolerance_khz to avoid TSC emulation
>>> On 09.04.18 at 16:55, wrote: > Am Mon, 09 Apr 2018 08:19:53 -0600 > schrieb "Jan Beulich" : > >> Is there any guarantee that old hypervisors will send this field as zero >> (rather than some random value)? If so, I think this should be said >> explicitly in the commit message, together with the fact that you >> re-use padding fields. > > I have to double check, but I'm sure the whole size of the struct is > initialized with zero. The commit message already has "Existing padding > fields are reused to store vtsc_khz_tolerance as u16." It's that sentence that I've referred to - it talks about padding, but doesn't make clear that this padding is zero at all times. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_init_device
pcistub_init_device() is never called in atomic context.
The call chain ending up at pcistub_init_device() is:
[1] pcistub_init_device() <- pcistub_seize() <- pcistub_probe()
[2] pcistub_init_device() <- pcistub_init_devices_late() <-
xen_pcibk_init()
pcistub_probe() is only set as ".probe" in struct pci_driver.
xen_pcibk_init() is is only set as a parameter of module_init().
These functions are not called in atomic context.
Despite never getting called from atomic context,
pcistub_init_device() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/xen/xen-pciback/pci_stub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xen-pciback/pci_stub.c
b/drivers/xen/xen-pciback/pci_stub.c
index 9e480fd..bf8c0d3 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -364,7 +364,7 @@ static int pcistub_init_device(struct pci_dev *dev)
* here and then to call kfree(pci_get_drvdata(psdev->dev)).
*/
dev_data = kzalloc(sizeof(*dev_data) + strlen(DRV_NAME "[]")
- + strlen(pci_name(dev)) + 1, GFP_ATOMIC);
+ + strlen(pci_name(dev)) + 1, GFP_KERNEL);
if (!dev_data) {
err = -ENOMEM;
goto out;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe
pcistub_probe() is never called in atomic context.
This function is only set as ".probe" in struct pci_driver.
Despite never getting called from atomic context,
pcistub_probe() calls kmalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/xen/xen-pciback/pci_stub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xen-pciback/pci_stub.c
b/drivers/xen/xen-pciback/pci_stub.c
index 9e480fd..95e6ddd 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -577,7 +577,7 @@ static int pcistub_probe(struct pci_dev *dev, const struct
pci_device_id *id)
}
if (!match) {
- pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_ATOMIC);
+ pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);
if (!pci_dev_id) {
err = -ENOMEM;
goto out;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_device_alloc
pcistub_device_alloc() is never called in atomic context. The call chain ending up at pcistub_device_alloc() is: [1] pcistub_device_alloc() <- pcistub_seize() <- pcistub_probe() pcistub_probe() is only set as ".probe" in struct pci_driver. This function is not called in atomic context. Despite never getting called from atomic context, pcistub_device_alloc() calls kzalloc() with GFP_ATOMIC, which does not sleep for allocation. GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, which can sleep and improve the possibility of sucessful allocation. Signed-off-by: Jia-Ju Bai --- drivers/xen/xen-pciback/pci_stub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c index 9e480fd..fecc536 100644 --- a/drivers/xen/xen-pciback/pci_stub.c +++ b/drivers/xen/xen-pciback/pci_stub.c @@ -71,7 +71,7 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev) dev_dbg(&dev->dev, "pcistub_device_alloc\n"); - psdev = kzalloc(sizeof(*psdev), GFP_ATOMIC); + psdev = kzalloc(sizeof(*psdev), GFP_KERNEL); if (!psdev) return NULL; -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in xen_pcibk_config_quirks_init
xen_pcibk_config_quirks_init() is never called in atomic context.
The call chains ending up at xen_pcibk_config_quirks_init() are:
[1] xen_pcibk_config_quirks_init() <- xen_pcibk_config_init_dev() <-
pcistub_init_device() <- pcistub_seize() <- pcistub_probe()
[2] xen_pcibk_config_quirks_init() <- xen_pcibk_config_init_dev() <-
pcistub_init_device() <- pcistub_init_devices_late() <-
xen_pcibk_init()
pcistub_probe() is only set as ".probe" in struct pci_driver.
xen_pcibk_init() is is only set as a parameter of module_init().
These functions are not called in atomic context.
Despite never getting called from atomic context,
xen_pcibk_config_quirks_init() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
Signed-off-by: Jia-Ju Bai
---
drivers/xen/xen-pciback/conf_space_quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xen-pciback/conf_space_quirks.c
b/drivers/xen/xen-pciback/conf_space_quirks.c
index 7476791..e3df3f9 100644
--- a/drivers/xen/xen-pciback/conf_space_quirks.c
+++ b/drivers/xen/xen-pciback/conf_space_quirks.c
@@ -94,7 +94,7 @@ int xen_pcibk_config_quirks_init(struct pci_dev *dev)
struct xen_pcibk_config_quirk *quirk;
int ret = 0;
- quirk = kzalloc(sizeof(*quirk), GFP_ATOMIC);
+ quirk = kzalloc(sizeof(*quirk), GFP_KERNEL);
if (!quirk) {
ret = -ENOMEM;
goto out;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH governance.git] Make Security Policy Doc ready to become a CNA
Note: this time with html disabled To become a CNA, we need to more clearly specifiy the scope of security support. This change updates the document and points to SUPPORT.md and pages generated from SUPPORT.md Also fixed a typo in the following paragraph. Signed-off-by: Lars Kurth --- security-policy.pandoc | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/security-policy.pandoc b/security-policy.pandoc index 5783183..6796220 100644 --- a/security-policy.pandoc +++ b/security-policy.pandoc @@ -19,7 +19,15 @@ Scope of this process This process primarily covers the [Xen Hypervisor Project](index.php?option=com_content&view=article&id=82:xen-hypervisor&catid=80:developers&Itemid=484). -Vulnerabilties reported against other Xen Project teams will be handled on a +Specific information about features with security support can be found in + +1. [SUPPORT.md](http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md) + in the releases' tar ball and its xen.git tree and on + [web pages generated from the SUPPORT.md file](http://xenbits.xenproject.org/docs/support/) +2. For releases that do not contain SUPPORT.md, this information can be found + on the [Release Feature wiki page](https://wiki.xenproject.org/wiki/Xen_Project_Release_Features) + +Vulnerabilities reported against other Xen Project teams will be handled on a best effort basis by the relevant Project Lead together with the Security Response Team. @@ -401,7 +409,7 @@ Change History -- - +- **v3.18 April 9th 2017:** Added reference to SUPPORT.md - **v3.17 July 20th 2017:** Added Zynstra - **v3.16 April 21st 2017:** Added HostPapa - **v3.15 March 21st 2017:** Added CloudVPS (Feb 13) and BitDefender SRL -- 2.13.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH governance.git] Make Security Policy Doc ready to become a CNA
To become a CNA, we need to more clearly specifiy the scope of security support. This change updates the document and points to SUPPORT.md and pages generated from SUPPORT.md Also fixed a typo in the following paragraph. Signed-off-by: Lars Kurth --- security-policy.pandoc | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/security-policy.pandoc b/security-policy.pandoc index 5783183..6796220 100644 --- a/security-policy.pandoc +++ b/security-policy.pandoc @@ -19,7 +19,15 @@ Scope of this process This process primarily covers the [Xen Hypervisor Project](index.php?option=com_content&view=article&id=82:xen-hypervisor&catid=80:developers&Itemid=484). -Vulnerabilties reported against other Xen Project teams will be handled on a +Specific information about features with security support can be found in + +1. [SUPPORT.md](http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md) +in the releases' tar ball and its xen.git tree and on +[web pages generated from the SUPPORT.md file](http://xenbits.xenproject.org/docs/support/) +2. For releases that do not contain SUPPORT.md, this information can be found +on the [Release Feature wiki page](https://wiki.xenproject.org/wiki/Xen_Project_Release_Features) + +Vulnerabilities reported against other Xen Project teams will be handled on a best effort basis by the relevant Project Lead together with the Security Response Team. @@ -401,7 +409,7 @@ Change History -- - +- **v3.18 April 9th 2017:** Added reference to SUPPORT.md - **v3.17 July 20th 2017:** Added Zynstra - **v3.16 April 21st 2017:** Added HostPapa - **v3.15 March 21st 2017:** Added CloudVPS (Feb 13) and BitDefender SRL -- 2.13.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] new config option vtsc_tolerance_khz to avoid TSC emulation
Am Mon, 09 Apr 2018 08:19:53 -0600 schrieb "Jan Beulich" : > Is there any guarantee that old hypervisors will send this field as zero > (rather than some random value)? If so, I think this should be said > explicitly in the commit message, together with the fact that you > re-use padding fields. I have to double check, but I'm sure the whole size of the struct is initialized with zero. The commit message already has "Existing padding fields are reused to store vtsc_khz_tolerance as u16." Thanks, Olaf pgpesO4uraFI2.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/7] introduce time managment in xtf
On 04/09/2018 04:35 PM, Roger Pau Monné wrote:
this file is introduce to be able to implement an inter domain
communication protocol over xenstore. For synchronization purpose, we do
really want to be able to "control" time
common/time.c: since_boot_time gets the time in nanoseconds from the
moment the VM has booted
Signed-off-by: Paul Semel
---
This seems to be missing a list of changes between v2 and v3. Please
add such a list when posting new versions.
+uint64_t since_boot_time(void)
+{
+uint64_t tsc;
+uint32_t ver1, ver2;
+uint64_t system_time;
+uint64_t old_tsc;
+
+do
+{
+do
+{
+ver1 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
+smp_rmb();
+} while ( (ver1 & 1) == 1 );
+
+system_time = ACCESS_ONCE(shared_info.vcpu_info[0].time.system_time);
+old_tsc = ACCESS_ONCE(shared_info.vcpu_info[0].time.tsc_timestamp);
+smp_rmb();
+ver2 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
+smp_rmb();
+} while ( ver1 != ver2 );
This is still overly complicated IMO, and you have not replied to my
question of whether doing the scale_delta below is OK.
About this scale_delta, we discussed with Andrew, and we are going to use
another version of the function as far as I remember. That's why I am not taking
care of it for the moment.
AFAICT uou _cannot_ access any of the vcpu_time_info fields without
checking for the version (in order to avoid reading inconsistent data
during an update), yet below you read tsc_to_system_mul and
tsc_shift.
I'm sorry, I am probably not getting your point here, because I am already
checking for the version. I was actually checking for the wc_version too in the
first version of those patches, but after chatting with Andrew, It appeared that
it was not necessary..
I've already pointed out the code at:
https://github.com/freebsd/freebsd/blob/master/sys/x86/x86/pvclock.c#L141
As a simpler reference implementation.
+
+rdtsc(tsc);
+
+system_time += scale_delta(tsc - old_tsc,
+
ACCESS_ONCE(shared_info.vcpu_info[0].time.tsc_to_system_mul),
+ ACCESS_ONCE(shared_info.vcpu_info[0].time.tsc_shift));
+
+return system_time;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xtf/time.h b/include/xtf/time.h
new file mode 100644
index 000..b88da63
--- /dev/null
+++ b/include/xtf/time.h
@@ -0,0 +1,31 @@
+/**
+ * @file include/xtf/time.h
+ *
+ * Time management
+ */
+#ifndef XTF_TIME_H
+# define XTF_TIME_H
+
+#include
+
+#define rdtsc(tsc) {\
+uint32_t lo, hi;\
+__asm__ volatile("rdtsc": "=a"(lo), "=d"(hi));\
Please make sure you only send a new version after having fixed all
the comments, this is still missing the serialization requirements
mentioned in the review, and it's also the wrong file to place this
helper:
I am sorry, I was really convinced that this version didn't need revision
anymore (and I still don't see what I should change).
https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg00546.html
Roger.
Thanks,
--
Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/7] introduce time managment in xtf
On 09/04/18 15:35, Roger Pau Monné wrote:
> On Mon, Apr 09, 2018 at 04:35:37PM +0200, Paul Semel wrote:
>> From: Paul Semel
>>
>> this file is introduce to be able to implement an inter domain
>> communication protocol over xenstore. For synchronization purpose, we do
>> really want to be able to "control" time
>>
>> common/time.c: since_boot_time gets the time in nanoseconds from the
>> moment the VM has booted
>>
>> Signed-off-by: Paul Semel
>> ---
> This seems to be missing a list of changes between v2 and v3. Please
> add such a list when posting new versions.
>
>> +uint64_t since_boot_time(void)
>> +{
>> +uint64_t tsc;
>> +uint32_t ver1, ver2;
>> +uint64_t system_time;
>> +uint64_t old_tsc;
>> +
>> +do
>> +{
>> +do
>> +{
>> +ver1 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
>> +smp_rmb();
>> +} while ( (ver1 & 1) == 1 );
>> +
>> +system_time =
>> ACCESS_ONCE(shared_info.vcpu_info[0].time.system_time);
>> +old_tsc = ACCESS_ONCE(shared_info.vcpu_info[0].time.tsc_timestamp);
>> +smp_rmb();
>> +ver2 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
>> +smp_rmb();
>> +} while ( ver1 != ver2 );
> This is still overly complicated IMO, and you have not replied to my
> question of whether doing the scale_delta below is OK.
>
> AFAICT uou _cannot_ access any of the vcpu_time_info fields without
> checking for the version (in order to avoid reading inconsistent data
> during an update), yet below you read tsc_to_system_mul and
> tsc_shift.
>
> I've already pointed out the code at:
>
> https://github.com/freebsd/freebsd/blob/master/sys/x86/x86/pvclock.c#L141
>
> As a simpler reference implementation.
There are real bugs in that implementation (wrong barriers, although
they are overly strong rather than overly week), and an inefficiency, in
that you don't want any extraneous calculation in between the two reads
of version. The call to pvclock_get_nsec_offset(ti) wants to be outside
of the critical region, to reduce the chance of intersecting an update
and having repeat the loop again.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary
On Mon, Apr 09, 2018 at 10:24:59AM -0400, Boris Ostrovsky wrote:
> Commit 4a5733771e6f ("libxl: put RSDP for PVH guest near 4GB") breaks
> pre-4.17 Linux guests since they do not use start_info's rsdp_paddr
> pointer and instread scan BIOS memory for RSDP signature.
>
> Introduce XENFEAT_rsdp_unrestricted feature flag that indicates whether
> the guest can handle RSDP at locations pointed to by rsdp_paddr.
>
> Since only Linux PVH guests suffer from this problem (BSD has always
> relied on rsdp_paddr) we check this flag just for those guests. If the
> flag is not set we place RSDP in BIOS, as before.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/7] introduce time managment in xtf
On Mon, Apr 09, 2018 at 04:35:37PM +0200, Paul Semel wrote:
> From: Paul Semel
>
> this file is introduce to be able to implement an inter domain
> communication protocol over xenstore. For synchronization purpose, we do
> really want to be able to "control" time
>
> common/time.c: since_boot_time gets the time in nanoseconds from the
> moment the VM has booted
>
> Signed-off-by: Paul Semel
> ---
This seems to be missing a list of changes between v2 and v3. Please
add such a list when posting new versions.
> +uint64_t since_boot_time(void)
> +{
> +uint64_t tsc;
> +uint32_t ver1, ver2;
> +uint64_t system_time;
> +uint64_t old_tsc;
> +
> +do
> +{
> +do
> +{
> +ver1 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
> +smp_rmb();
> +} while ( (ver1 & 1) == 1 );
> +
> +system_time = ACCESS_ONCE(shared_info.vcpu_info[0].time.system_time);
> +old_tsc = ACCESS_ONCE(shared_info.vcpu_info[0].time.tsc_timestamp);
> +smp_rmb();
> +ver2 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
> +smp_rmb();
> +} while ( ver1 != ver2 );
This is still overly complicated IMO, and you have not replied to my
question of whether doing the scale_delta below is OK.
AFAICT uou _cannot_ access any of the vcpu_time_info fields without
checking for the version (in order to avoid reading inconsistent data
during an update), yet below you read tsc_to_system_mul and
tsc_shift.
I've already pointed out the code at:
https://github.com/freebsd/freebsd/blob/master/sys/x86/x86/pvclock.c#L141
As a simpler reference implementation.
> +
> +rdtsc(tsc);
> +
> +system_time += scale_delta(tsc - old_tsc,
> +
> ACCESS_ONCE(shared_info.vcpu_info[0].time.tsc_to_system_mul),
> + ACCESS_ONCE(shared_info.vcpu_info[0].time.tsc_shift));
> +
> +return system_time;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/include/xtf/time.h b/include/xtf/time.h
> new file mode 100644
> index 000..b88da63
> --- /dev/null
> +++ b/include/xtf/time.h
> @@ -0,0 +1,31 @@
> +/**
> + * @file include/xtf/time.h
> + *
> + * Time management
> + */
> +#ifndef XTF_TIME_H
> +# define XTF_TIME_H
> +
> +#include
> +
> +#define rdtsc(tsc) {\
> +uint32_t lo, hi;\
> +__asm__ volatile("rdtsc": "=a"(lo), "=d"(hi));\
Please make sure you only send a new version after having fixed all
the comments, this is still missing the serialization requirements
mentioned in the review, and it's also the wrong file to place this
helper:
https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg00546.html
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 7/7] xen/x86: use PCID feature
On 09/04/18 16:15, Jan Beulich wrote: On 06.04.18 at 09:52, wrote: >> @@ -100,12 +102,35 @@ void write_cr3_cr4(unsigned long cr3, unsigned long >> cr4) >> t = pre_flush(); >> >> if ( read_cr4() & X86_CR4_PGE ) >> +/* >> + * X86_CR4_PGE set means PCID being inactive. >> + * We have to purge the TLB via flipping cr4.pge. >> + */ >> write_cr4(cr4 & ~X86_CR4_PGE); >> +else if ( use_invpcid ) >> +/* >> + * If we are using PCID purge the TLB via INVPCID as loading cr3 >> + * will affect the new PCID only. >> + * If INVPCID is not supported we don't use PCIDs so loading cr3 >> + * will purge the TLB (we are in the "global pages off" branch). >> + * invpcid_flush_all_nonglobals() seems to be faster than >> + * invpcid_flush_all(). >> + */ >> +invpcid_flush_all_nonglobals(); >> >> asm volatile ( "mov %0, %%cr3" : : "r" (cr3) : "memory" ); >> >> if ( read_cr4() != cr4 ) >> write_cr4(cr4); >> +else if ( old_pcid != (cr3 & X86_CR3_PCID_MASK) ) >> +/* >> + * Make sure no TLB entries related to the old PCID created between >> + * flushing the TLB and writing the new %cr3 value remain in the >> TLB. >> + * Writing %cr3 is documented to be a speculation barrier, OTOH the >> + * performance impact of the additional flush is next to invisible. >> + * So better be save than sorry. >> + */ >> +invpcid_flush_single_context(old_pcid); > > I'm not really happy about this comment. The CR3 write being a > speculation barrier is of no real interest here. Until the CPU's > speculation logic reaches that insn, all sort of things can happen. > We don't even know the exact code the compiler will generate, > much less what that code will trigger inside the CPU. In case you are feeling strong regarding this comment I can remove it. > > Also I think it's "safe" in the last sentence. Of course. > >> --- a/xen/include/asm-x86/x86-defns.h >> +++ b/xen/include/asm-x86/x86-defns.h >> @@ -45,7 +45,9 @@ >> /* >> * Intel CPU flags in CR3 >> */ >> -#define X86_CR3_NOFLUSH (_AC(1, ULL) << 63) >> +#define X86_CR3_NOFLUSH(_AC(1, ULL) << 63) >> +#define X86_CR3_ADDR_MASK (PAGE_MASK & PADDR_MASK & ~X86_CR3_NOFLUSH) > > Why still ~X86_CR3_NOFLUSH now that you use PADDR_MASK? I just want to make clear that NOFLUSH is not included. Would you like a comment better? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary
Commit 4a5733771e6f ("libxl: put RSDP for PVH guest near 4GB") breaks
pre-4.17 Linux guests since they do not use start_info's rsdp_paddr
pointer and instread scan BIOS memory for RSDP signature.
Introduce XENFEAT_rsdp_unrestricted feature flag that indicates whether
the guest can handle RSDP at locations pointed to by rsdp_paddr.
Since only Linux PVH guests suffer from this problem (BSD has always
relied on rsdp_paddr) we check this flag just for those guests. If the
flag is not set we place RSDP in BIOS, as before.
Signed-off-by: Boris Ostrovsky
---
v2:
* Renamed flag to XENFEAT_linux_rsdp_unrestricted
* Clarified comment in features.h
I did not include tags because of the changes but just in case ---
here they are:
Acked-by: George Dunlap
Reviewed-by: Juergen Gross
Release-acked-by: Juergen Gross
tools/libxl/libxl_x86_acpi.c | 14 --
xen/include/public/features.h | 9 +
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
index fe87418bc1..143ce66644 100644
--- a/tools/libxl/libxl_x86_acpi.c
+++ b/tools/libxl/libxl_x86_acpi.c
@@ -218,8 +218,18 @@ int libxl__dom_load_acpi(libxl__gc *gc,
dom->acpi_modules[0].data = (void *)config.rsdp;
dom->acpi_modules[0].length = 64;
-dom->acpi_modules[0].guest_addr_out = ACPI_INFO_PHYSICAL_ADDRESS +
-(1 + acpi_pages_num) * libxl_ctxt.page_size;
+/*
+ * Some Linux versions cannot properly process hvm_start_info.rsdp_paddr
+ * and so we need to put RSDP in location that can be discovered by ACPI's
+ * standard search method, in R-O BIOS memory (we chose last 64 bytes)
+ */
+if (strcmp(dom->parms.guest_os, "linux") ||
+elf_xen_feature_get(XENFEAT_linux_rsdp_unrestricted,
+dom->parms.f_supported))
+dom->acpi_modules[0].guest_addr_out = ACPI_INFO_PHYSICAL_ADDRESS +
+(1 + acpi_pages_num) * libxl_ctxt.page_size;
+else
+dom->acpi_modules[0].guest_addr_out = 0x10 - 64;
dom->acpi_modules[1].data = (void *)config.infop;
dom->acpi_modules[1].length = 4096;
diff --git a/xen/include/public/features.h b/xen/include/public/features.h
index 1a989b8bf9..443e6eca53 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -105,6 +105,15 @@
/* arm: Hypervisor supports ARM SMC calling convention. */
#define XENFEAT_ARM_SMCCC_supported 14
+/*
+ * x86/PVH: If set, ACPI RSDP can be placed at any address. Otherwise RSDP
+ * must be located in lower 1MB, as required by ACPI Specification for IA-PC
+ * systems.
+ * This feature flag is only consulted if XEN_ELFNOTE_GUEST_OS contains
+ * the "linux" string.
+ */
+#define XENFEAT_linux_rsdp_unrestricted 15
+
#define XENFEAT_NR_SUBMAPS 1
#endif /* __XEN_PUBLIC_FEATURES_H__ */
--
2.14.3
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] pci: a workaround for nonstandard PCI devices whose PBA shares
>>> On 09.04.18 at 16:10, wrote: > On Mon, Apr 09, 2018 at 07:40:15AM -0600, Jan Beulich wrote: >>I'm not convinced though that a global option is well suited here: >>Exposing the device in this way may be okay for one guest, but >>not for another. With your model one would need to reboot the >>entire host for such a usage change. >> >>Furthermore boot time specification of SBDF is a problem with the >>Dom0 kernel possibly re-organizing the topology, and is not going >>to work well with hot-plugged devices. > > Point taken. But one concern is if we don't specify devices at boot time > whether PVH dom0 can use such devices (in my understanding, PVH dom0 > will use EPT, it will meet the same issue as HVM domU). If not, we need > treat dom0 as an exception; pages where PBA resides won't be marked as > read-only. But mmio_ro_ranges is global. Maybe build two separate > mmio_ro_ranges for dom0 and domU? Boot time Dom0 settings can come from the command line. But already for hot-plugged devices (which go to Dom0 as well) this approach would break. Generally permitting Dom0 write access here is certainly an option, but strictly only as long as the MSI-X table won't also become writable. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] new config option vtsc_tolerance_khz to avoid TSC emulation
>>> On 01.04.18 at 22:29, wrote: > @@ -34,7 +35,8 @@ int handle_tsc_info(struct xc_sr_context *ctx, struct > xc_sr_record *rec) > } > > if ( xc_domain_set_tsc_info(xch, ctx->domid, tsc->mode, > -tsc->nsec, tsc->khz, tsc->incarnation) ) > +tsc->nsec, tsc->khz, tsc->vtsc_tolerance, > +tsc->incarnation) ) Is there any guarantee that old hypervisors will send this field as zero (rather than some random value)? If so, I think this should be said explicitly in the commit message, together with the fact that you re-use padding fields. Hypervisor side provisionally (upon Andrew finding his prior concerns addressed) Reviewed-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] pci: a workaround for nonstandard PCI devices whose PBA shares
On Mon, Apr 09, 2018 at 07:40:15AM -0600, Jan Beulich wrote: On 09.04.18 at 15:16, wrote: >> Given that parsing parameters starts at very early stage in which xmalloc is >> unusable, I choose to continue using an array other than a list to store >> SBDFs >> of such kind devices, like the way how we manage phantom_devs. > >Yes, I was about to say that on v1 when I saw v2 come in. > >> --- a/docs/misc/xen-command-line.markdown >> +++ b/docs/misc/xen-command-line.markdown >> @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors. >> >> > Default: `on` >> >> +### pba\_shared\_quirk >> +> `= List of [:]:.` >> + >> +Specify a list of SBDF of devices. When assigning devices in this list >> +to guest, reading or writing the page where MSI-X PBA resides are >> +allowed. This option provides a workaround for nonstandard PCI devices >> +whose MSI-X PBA shares the same 4K-byte page with registers irrelevant >> +to MSI-X. Note that adding an untrusted device to this option would >> +undermine security of the entire system. > >No underscores in new command line options please - use dashes. Will do. > >I'm not convinced though that a global option is well suited here: >Exposing the device in this way may be okay for one guest, but >not for another. With your model one would need to reboot the >entire host for such a usage change. > >Furthermore boot time specification of SBDF is a problem with the >Dom0 kernel possibly re-organizing the topology, and is not going >to work well with hot-plugged devices. Point taken. But one concern is if we don't specify devices at boot time whether PVH dom0 can use such devices (in my understanding, PVH dom0 will use EPT, it will meet the same issue as HVM domU). If not, we need treat dom0 as an exception; pages where PBA resides won't be marked as read-only. But mmio_ro_ranges is global. Maybe build two separate mmio_ro_ranges for dom0 and domU? Thanks Chao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 7/7] xen/x86: use PCID feature
>>> On 06.04.18 at 09:52, wrote: > @@ -100,12 +102,35 @@ void write_cr3_cr4(unsigned long cr3, unsigned long cr4) > t = pre_flush(); > > if ( read_cr4() & X86_CR4_PGE ) > +/* > + * X86_CR4_PGE set means PCID being inactive. > + * We have to purge the TLB via flipping cr4.pge. > + */ > write_cr4(cr4 & ~X86_CR4_PGE); > +else if ( use_invpcid ) > +/* > + * If we are using PCID purge the TLB via INVPCID as loading cr3 > + * will affect the new PCID only. > + * If INVPCID is not supported we don't use PCIDs so loading cr3 > + * will purge the TLB (we are in the "global pages off" branch). > + * invpcid_flush_all_nonglobals() seems to be faster than > + * invpcid_flush_all(). > + */ > +invpcid_flush_all_nonglobals(); > > asm volatile ( "mov %0, %%cr3" : : "r" (cr3) : "memory" ); > > if ( read_cr4() != cr4 ) > write_cr4(cr4); > +else if ( old_pcid != (cr3 & X86_CR3_PCID_MASK) ) > +/* > + * Make sure no TLB entries related to the old PCID created between > + * flushing the TLB and writing the new %cr3 value remain in the TLB. > + * Writing %cr3 is documented to be a speculation barrier, OTOH the > + * performance impact of the additional flush is next to invisible. > + * So better be save than sorry. > + */ > +invpcid_flush_single_context(old_pcid); I'm not really happy about this comment. The CR3 write being a speculation barrier is of no real interest here. Until the CPU's speculation logic reaches that insn, all sort of things can happen. We don't even know the exact code the compiler will generate, much less what that code will trigger inside the CPU. Also I think it's "safe" in the last sentence. > --- a/xen/include/asm-x86/x86-defns.h > +++ b/xen/include/asm-x86/x86-defns.h > @@ -45,7 +45,9 @@ > /* > * Intel CPU flags in CR3 > */ > -#define X86_CR3_NOFLUSH (_AC(1, ULL) << 63) > +#define X86_CR3_NOFLUSH(_AC(1, ULL) << 63) > +#define X86_CR3_ADDR_MASK (PAGE_MASK & PADDR_MASK & ~X86_CR3_NOFLUSH) Why still ~X86_CR3_NOFLUSH now that you use PADDR_MASK? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On 04/08/2018 09:38 PM, Razvan Cojocaru wrote:
> Hello,
>
> I've noticed altp2m behaviour I can't explain yet - I'm not all that
> familiar with all the ways the new views corellate with the previous
> EPT-based "view 0".
>
> In short, if we create a new view and simply switch to it early in the
> boot process of the guest, something goes wrong and the guest either
> freezes, becomes unresponsive to input, or has something wrong with the
> display (most often the latter, with a black band on top of the image):
>
> https://ibb.co/eUPJ6c
> https://ibb.co/etCXXH
>
> That guest is a 64-bit Windows 7 system with nothing special about it.
> It's easy to reproduce this:
>
> 1. Start the guest paused (I've used "xl create -p myguest.conf").
> 2. Patch xen-access like this: https://pastebin.com/67PpQ9fu (just
> remove the part of the code that modifies the new view before switching
> to it).
> 3. Hook xen-access to the guest ("./xen-access altp2m_write").
> 4. Unpause the guest ("xl unpause ").
>
> I think that's a valid scenario and supposed to work.
>
> I've also noticed that if I wait to do this until the OS is
> up-and-running (e.g. after logging into Windows), there seems to be no
> problem. I don't know if this is just coincidence (as is bound to happen
> with race-condition situations), or means something, but I can get the
> problems every time when switching views early, and never when switching
> the views late.
>
> Suggestions on what the problem could be are, as always, greatly
> appreciated.
The obvious place to look is the logdirtyvram functionality, which is
used to make it easier for QEMU to figure out which bits of the display
buffer have been modified. One of the big reasons the altp2m
functionality is still considered "experimental" is that these sorts of
interactions were never carefully thought out.
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 3/7] add gettimeofday function to time managment
From: Paul Semel
this function acts as the POSIX gettimeofday function
Signed-off-by: Paul Semel
---
common/time.c | 30 ++
include/xtf/time.h | 7 +++
2 files changed, 37 insertions(+)
diff --git a/common/time.c b/common/time.c
index 29b38ca..d0c9ed2 100644
--- a/common/time.c
+++ b/common/time.c
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
#include
#include
@@ -109,6 +110,35 @@ uint64_t current_time(void)
return sec + boot_time;
}
+/* The POSIX gettimeofday syscall normally takes a second argument, which is
+ * the timezone (struct timezone). However, it sould be NULL because linux
+ * doesn't use it anymore. So we need for us to add it in this function
+ */
+int gettimeofday(struct timeval *tp, void *restrict tzp)
+{
+uint64_t boot_time, sec;
+uint32_t mod, nsec;
+
+if ( tzp != NULL )
+return -EOPNOTSUPP;
+
+if ( tp == NULL )
+return -EINVAL;
+
+get_time_info(&boot_time, &sec, &nsec);
+
+#if defined(__i386__)
+mod = divmod64(&boot_time, SEC_TO_NSEC(1));
+#else
+mod = boot_time % SEC_TO_NSEC(1);
+boot_time /= SEC_TO_NSEC(1);
+#endif
+
+tp->sec = sec + boot_time;
+tp->nsec = nsec + mod;
+return 0;
+}
+
/*
* Local variables:
* mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index 4d94958..5ed88ad 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -8,6 +8,11 @@
#include
+struct timeval {
+uint64_t sec;
+uint64_t nsec;
+};
+
#define rdtsc(tsc) {\
uint32_t lo, hi;\
__asm__ volatile("rdtsc": "=a"(lo), "=d"(hi));\
@@ -22,6 +27,8 @@ uint64_t since_boot_time(void);
uint64_t current_time(void);
+int gettimeofday(struct timeval *tp, void *restrict tzp);
+
#endif /* XTF_TIME_H */
/*
--
2.16.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 4/7] add nspin_sleep function to time manager
From: Paul Semel
this function spin sleeps for t nanoseconds
Signed-off-by: Paul Semel
---
common/time.c | 12
1 file changed, 12 insertions(+)
diff --git a/common/time.c b/common/time.c
index d0c9ed2..4770b9a 100644
--- a/common/time.c
+++ b/common/time.c
@@ -139,6 +139,18 @@ int gettimeofday(struct timeval *tp, void *restrict tzp)
return 0;
}
+static inline void nspin_sleep(uint64_t t)
+{
+uint64_t curr = since_boot_time();
+uint64_t end = curr + t;
+
+if ( end < curr )
+panic("end value overflows counter\n");
+
+while ( since_boot_time() < end )
+asm volatile ("pause");
+}
+
/*
* Local variables:
* mode: C
--
2.16.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 7/7] add sleep, msleep and NOW() macros to time manager
From: Paul Semel
those are helpful macro to use the time manager correctly
Signed-off-by: Paul Semel
---
common/time.c | 10 ++
include/xtf/time.h | 12
2 files changed, 22 insertions(+)
diff --git a/common/time.c b/common/time.c
index 9685591..714afb8 100644
--- a/common/time.c
+++ b/common/time.c
@@ -163,6 +163,16 @@ static inline void mspin_sleep(uint64_t t)
nspin_sleep(nsec);
}
+void sleep(uint64_t t)
+{
+spin_sleep(t);
+}
+
+void msleep(uint64_t t)
+{
+mspin_sleep(t);
+}
+
/*
* Local variables:
* mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index 17fb561..ff431a2 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -28,8 +28,20 @@ uint64_t since_boot_time(void);
uint64_t current_time(void);
+/* This function takes seconds in parameter */
+void sleep(uint64_t f);
+
+/* Be careful, this function takes milliseconds in parameter,
+ * not microseconds !
+ */
+void msleep(uint64_t f);
+
int gettimeofday(struct timeval *tp, void *restrict tzp);
+
+/* This returns the current epoch time */
+#define NOW() current_time()
+
#endif /* XTF_TIME_H */
/*
--
2.16.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 1/7] introduce time managment in xtf
From: Paul Semel
this file is introduce to be able to implement an inter domain
communication protocol over xenstore. For synchronization purpose, we do
really want to be able to "control" time
common/time.c: since_boot_time gets the time in nanoseconds from the
moment the VM has booted
Signed-off-by: Paul Semel
---
build/files.mk | 1 +
common/time.c | 81 ++
include/xtf/time.h | 31 +
3 files changed, 113 insertions(+)
create mode 100644 common/time.c
create mode 100644 include/xtf/time.h
diff --git a/build/files.mk b/build/files.mk
index 46b42d6..55ed1ca 100644
--- a/build/files.mk
+++ b/build/files.mk
@@ -16,6 +16,7 @@ obj-perarch += $(ROOT)/common/libc/vsnprintf.o
obj-perarch += $(ROOT)/common/report.o
obj-perarch += $(ROOT)/common/setup.o
obj-perarch += $(ROOT)/common/xenbus.o
+obj-perarch += $(ROOT)/common/time.o
obj-perenv += $(ROOT)/arch/x86/decode.o
obj-perenv += $(ROOT)/arch/x86/desc.o
diff --git a/common/time.c b/common/time.c
new file mode 100644
index 000..7859c21
--- /dev/null
+++ b/common/time.c
@@ -0,0 +1,81 @@
+#include
+#include
+#include
+
+#include
+
+/* This function was taken from mini-os source code */
+/* It returns ((delta << shift) * mul_frac) >> 32 */
+static inline uint64_t scale_delta(uint64_t delta, uint32_t mul_frac, int
shift)
+{
+uint64_t product;
+#ifdef __i386__
+uint32_t tmp1, tmp2;
+#endif
+
+if ( shift < 0 )
+delta >>= -shift;
+else
+delta <<= shift;
+
+#ifdef __i386__
+__asm__ (
+"mul %5 ; "
+"mov %4,%%eax ; "
+"mov %%edx,%4 ; "
+"mul %5 ; "
+"add %4,%%eax ; "
+"xor %5,%5; "
+"adc %5,%%edx ; "
+: "=A" (product), "=r" (tmp1), "=r" (tmp2)
+: "a" ((uint32_t)delta), "1" ((uint32_t)(delta >> 32)), "2"
(mul_frac) );
+#else
+__asm__ (
+"mul %%rdx ; shrd $32,%%rdx,%%rax"
+: "=a" (product) : "0" (delta), "d" ((uint64_t)mul_frac) );
+#endif
+
+return product;
+}
+
+
+uint64_t since_boot_time(void)
+{
+uint64_t tsc;
+uint32_t ver1, ver2;
+uint64_t system_time;
+uint64_t old_tsc;
+
+do
+{
+do
+{
+ver1 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
+smp_rmb();
+} while ( (ver1 & 1) == 1 );
+
+system_time = ACCESS_ONCE(shared_info.vcpu_info[0].time.system_time);
+old_tsc = ACCESS_ONCE(shared_info.vcpu_info[0].time.tsc_timestamp);
+smp_rmb();
+ver2 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
+smp_rmb();
+} while ( ver1 != ver2 );
+
+rdtsc(tsc);
+
+system_time += scale_delta(tsc - old_tsc,
+
ACCESS_ONCE(shared_info.vcpu_info[0].time.tsc_to_system_mul),
+ ACCESS_ONCE(shared_info.vcpu_info[0].time.tsc_shift));
+
+return system_time;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xtf/time.h b/include/xtf/time.h
new file mode 100644
index 000..b88da63
--- /dev/null
+++ b/include/xtf/time.h
@@ -0,0 +1,31 @@
+/**
+ * @file include/xtf/time.h
+ *
+ * Time management
+ */
+#ifndef XTF_TIME_H
+# define XTF_TIME_H
+
+#include
+
+#define rdtsc(tsc) {\
+uint32_t lo, hi;\
+__asm__ volatile("rdtsc": "=a"(lo), "=d"(hi));\
+tsc = ((uint64_t)hi << 32) | lo;\
+}
+
+
+/* Time from boot in nanoseconds */
+uint64_t since_boot_time(void);
+
+#endif /* XTF_TIME_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.16.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 6/7] add mspin_sleep function to time manager
From: Paul Semel
this function uses mspin_sleep to spin sleep for t milliseconds
Signed-off-by: Paul Semel
---
common/time.c | 6 ++
include/xtf/time.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/common/time.c b/common/time.c
index e744ab1..9685591 100644
--- a/common/time.c
+++ b/common/time.c
@@ -157,6 +157,12 @@ static inline void spin_sleep(uint64_t t)
nspin_sleep(nsec);
}
+static inline void mspin_sleep(uint64_t t)
+{
+uint64_t nsec = MSEC_TO_NSEC(t);
+nspin_sleep(nsec);
+}
+
/*
* Local variables:
* mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index 5ed88ad..17fb561 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -20,6 +20,7 @@ struct timeval {
}
#define SEC_TO_NSEC(x) ((x) * 10ul)
+#define MSEC_TO_NSEC(x) ((x) * 100ul)
/* Time from boot in nanoseconds */
--
2.16.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/7] add current_time function to time manager
From: Paul Semel
this function returns the "epoch" time
Signed-off-by: Paul Semel
---
common/time.c | 39 +++
include/xtf/time.h | 4
2 files changed, 43 insertions(+)
diff --git a/common/time.c b/common/time.c
index 7859c21..29b38ca 100644
--- a/common/time.c
+++ b/common/time.c
@@ -3,6 +3,7 @@
#include
#include
+#include
/* This function was taken from mini-os source code */
/* It returns ((delta << shift) * mul_frac) >> 32 */
@@ -70,6 +71,44 @@ uint64_t since_boot_time(void)
return system_time;
}
+static void get_time_info(uint64_t *boot_time, uint64_t *sec, uint32_t *nsec)
+{
+uint32_t ver1, ver2;
+do {
+ver1 = ACCESS_ONCE(shared_info.wc_version);
+smp_rmb();
+*boot_time = since_boot_time();
+#if defined(__i386__)
+*sec = (uint64_t)ACCESS_ONCE(shared_info.wc_sec);
+#else
+*sec = ((uint64_t)ACCESS_ONCE(shared_info.wc_sec_hi) << 32)
+| ACCESS_ONCE(shared_info.wc_sec);
+#endif
+*nsec = (uint64_t)ACCESS_ONCE(shared_info.wc_nsec);
+smp_rmb();
+ver2 = ACCESS_ONCE(shared_info.wc_version);
+smp_rmb();
+} while ( (ver1 & 1) != 0 && ver1 != ver2 );
+}
+
+/* This function return the epoch time (number of seconds elapsed
+ * since Juanary 1, 1970) */
+uint64_t current_time(void)
+{
+uint32_t nsec;
+uint64_t boot_time, sec;
+
+get_time_info(&boot_time, &sec, &nsec);
+
+#if defined(__i386__)
+divmod64(&boot_time, SEC_TO_NSEC(1));
+#else
+boot_time /= SEC_TO_NSEC(1);
+#endif
+
+return sec + boot_time;
+}
+
/*
* Local variables:
* mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index b88da63..4d94958 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -14,10 +14,14 @@
tsc = ((uint64_t)hi << 32) | lo;\
}
+#define SEC_TO_NSEC(x) ((x) * 10ul)
+
/* Time from boot in nanoseconds */
uint64_t since_boot_time(void);
+uint64_t current_time(void);
+
#endif /* XTF_TIME_H */
/*
--
2.16.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 5/7] add spin_sleep function to time manager
From: Paul Semel
this function uses nspin_sleep to spin sleep for t seconds
Signed-off-by: Paul Semel
---
common/time.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/common/time.c b/common/time.c
index 4770b9a..e744ab1 100644
--- a/common/time.c
+++ b/common/time.c
@@ -151,6 +151,12 @@ static inline void nspin_sleep(uint64_t t)
asm volatile ("pause");
}
+static inline void spin_sleep(uint64_t t)
+{
+uint64_t nsec = SEC_TO_NSEC(t);
+nspin_sleep(nsec);
+}
+
/*
* Local variables:
* mode: C
--
2.16.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: fix build after f20a6e309
On 09/04/18 15:49, Wei Liu wrote: > Commit f20a6e309 removed a parameter from smp_prepare_cpus but only > the x86 parts were submitted and committed. > > Signed-off-by: Wei Liu Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/arm: fix build after f20a6e309
Commit f20a6e309 removed a parameter from smp_prepare_cpus but only
the x86 parts were submitted and committed.
Signed-off-by: Wei Liu
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
xen/arch/arm/setup.c | 2 +-
xen/arch/arm/smpboot.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6e49e8fd1f..1d6f6bf37e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -804,7 +804,7 @@ void __init start_xen(unsigned long boot_phys_offset,
local_irq_enable();
local_abort_enable();
-smp_prepare_cpus(cpus);
+smp_prepare_cpus();
initialize_keytable();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 62f795f68e..b2116f0d2d 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -283,7 +283,7 @@ smp_get_max_cpus (void)
}
void __init
-smp_prepare_cpus (unsigned int max_cpus)
+smp_prepare_cpus(void)
{
cpumask_copy(&cpu_present_map, &cpu_possible_map);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-sid test] 74563: trouble: blocked/broken/fail/pass
flight 74563 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74563/ 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-pvopsbroken Tests which did not succeed, but are not blocking: test-arm64-arm64-armhf-sid-netboot-pygrub 1 build-check(1)blocked n/a build-arm64-pvops 2 hosts-allocate broken blocked in 74460 build-arm64 2 hosts-allocate broken blocked in 74460 build-arm64-pvops 3 capture-logs broken blocked in 74460 build-arm64 3 capture-logs broken blocked in 74460 test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail blocked in 74460 test-amd64-i386-amd64-sid-netboot-pygrub 10 debian-di-install fail blocked in 74460 test-amd64-amd64-amd64-sid-netboot-pvgrub 10 debian-di-install fail blocked in 74460 test-amd64-amd64-i386-sid-netboot-pygrub 10 debian-di-install fail blocked in 74460 test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail blocked in 74460 baseline version: flight 74460 jobs: build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-pvopspass build-arm64-pvopsbroken build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-sid-netboot-pvgrubfail test-amd64-i386-i386-sid-netboot-pvgrub fail test-amd64-i386-amd64-sid-netboot-pygrub fail test-arm64-arm64-armhf-sid-netboot-pygrubblocked test-armhf-armhf-armhf-sid-netboot-pygrubfail test-amd64-amd64-i386-sid-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/HVM: alter completion-needed checking
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Jan Beulich > Sent: 09 April 2018 14:44 > To: Paul Durrant > Cc: Juergen Gross ; Andrew Cooper > ; Kevin Tian ; Jun > Nakajima ; xen-devel de...@lists.xenproject.org> > Subject: Re: [Xen-devel] [PATCH 2/2] x86/HVM: alter completion-needed > checking > > >>> On 09.04.18 at 15:33, wrote: > >> -Original Message- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 09 April 2018 14:24 > >> To: xen-devel > >> Cc: Andrew Cooper ; Paul Durrant > >> ; Jun Nakajima ; > Kevin > >> Tian ; Juergen Gross > >> Subject: [PATCH 2/2] x86/HVM: alter completion-needed checking > >> > >> The function only looks at the ioreq_t, so pass it a pointer to just > >> that. Also use it in hvmemul_do_io(). > >> > >> Suggested-by: Paul Durrant > >> Signed-off-by: Jan Beulich > >> --- > >> RFC: While this avoids some open coding, generated code looks to be > >> worse for that particular case. I'm therefore not certain that we > >> want this change (or perhaps just the function name/signature > >> change portion). > >> > > > > FAOD my reason for suggesting it was such that exactly the same test > > implementation is used in all cases to decide whether I/O completion is > > needed. > > So does that mean you think the change is worthwhile? If so, do > you have any comments, or are you willing to ack it (despite it > not really being a 4.11 candidate at this point in time)? > Yes, I think the change is worthwhile as it makes the code clearer (to me at least) so you can consider it Reviewed-by: Paul Durrant > Jan > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/HVM: alter completion-needed checking
>>> On 09.04.18 at 15:33, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 09 April 2018 14:24 >> To: xen-devel >> Cc: Andrew Cooper ; Paul Durrant >> ; Jun Nakajima ; Kevin >> Tian ; Juergen Gross >> Subject: [PATCH 2/2] x86/HVM: alter completion-needed checking >> >> The function only looks at the ioreq_t, so pass it a pointer to just >> that. Also use it in hvmemul_do_io(). >> >> Suggested-by: Paul Durrant >> Signed-off-by: Jan Beulich >> --- >> RFC: While this avoids some open coding, generated code looks to be >> worse for that particular case. I'm therefore not certain that we >> want this change (or perhaps just the function name/signature >> change portion). >> > > FAOD my reason for suggesting it was such that exactly the same test > implementation is used in all cases to decide whether I/O completion is > needed. So does that mean you think the change is worthwhile? If so, do you have any comments, or are you willing to ack it (despite it not really being a 4.11 candidate at this point in time)? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] pci: a workaround for nonstandard PCI devices whose PBA shares
>>> On 09.04.18 at 15:16, wrote:
> Given that parsing parameters starts at very early stage in which xmalloc is
> unusable, I choose to continue using an array other than a list to store SBDFs
> of such kind devices, like the way how we manage phantom_devs.
Yes, I was about to say that on v1 when I saw v2 come in.
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
>
> > Default: `on`
>
> +### pba\_shared\_quirk
> +> `= List of [:]:.`
> +
> +Specify a list of SBDF of devices. When assigning devices in this list
> +to guest, reading or writing the page where MSI-X PBA resides are
> +allowed. This option provides a workaround for nonstandard PCI devices
> +whose MSI-X PBA shares the same 4K-byte page with registers irrelevant
> +to MSI-X. Note that adding an untrusted device to this option would
> +undermine security of the entire system.
No underscores in new command line options please - use dashes.
I'm not convinced though that a global option is well suited here:
Exposing the device in this way may be okay for one guest, but
not for another. With your model one would need to reboot the
entire host for such a usage change.
Furthermore boot time specification of SBDF is a problem with the
Dom0 kernel possibly re-organizing the topology, and is not going
to work well with hot-plugged devices.
IOW - I think this setting needs to be specified at device
assignment time.
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -992,7 +992,22 @@ static int msix_capability_init(struct pci_dev *dev,
> if ( rangeset_add_range(mmio_ro_ranges, msix->table.first,
> msix->table.last) )
> WARN();
> -if ( rangeset_add_range(mmio_ro_ranges, msix->pba.first,
> +
> +/*
> + * If pages where MSI-X PBA resides overlap with other read-only mmio
> + * range, pba_shared_quirk won't meet our desire. Hence disable it.
> + */
> +if ( msix->pba_shared_quirk_enabled &&
> + rangeset_overlaps_range(mmio_ro_ranges, msix->pba.first,
> + msix->pba.last) )
> +{
> +printk("PBA_shared_quirk is disabled for %04x:%02x:%02x.%u",
> + seg, bus, slot, func);
> +msix->pba_shared_quirk_enabled = false;
> +}
> +
> +if ( !msix->pba_shared_quirk_enabled &&
> + rangeset_add_range(mmio_ro_ranges, msix->pba.first,
> msix->pba.last) )
> WARN();
>
> @@ -1139,7 +1154,8 @@ static void _pci_cleanup_msix(struct arch_msix *msix)
> if ( rangeset_remove_range(mmio_ro_ranges, msix->table.first,
> msix->table.last) )
> WARN();
> -if ( rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
> +if ( !msix->pba_shared_quirk_enabled &&
> + rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
> msix->pba.last) )
I don't think you need to alter the condition here.
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -184,6 +184,39 @@ static int __init parse_phantom_dev(const char *str)
> }
> custom_param("pci-phantom", parse_phantom_dev);
>
> +static struct pba_shared_quirk_dev {
> +pci_sbdf_t sbdf;
> +} pba_shared_quirk_devs[8];
Any reason this can't be of type pci_sbdf_t[8]?
> +static unsigned int nr_pba_shared_quirk_devs;
Both __read_mostly please.
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -239,6 +239,7 @@ struct arch_msix {
> int table_idx[MAX_MSIX_TABLE_PAGES];
> spinlock_t table_lock;
> bool host_maskall, guest_maskall;
> +bool pba_shared_quirk_enabled;
I don't think you need the "_enabled" suffix - it's a boolean after all.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/HVM: alter completion-needed checking
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 April 2018 14:24
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Jun Nakajima ; Kevin
> Tian ; Juergen Gross
> Subject: [PATCH 2/2] x86/HVM: alter completion-needed checking
>
> The function only looks at the ioreq_t, so pass it a pointer to just
> that. Also use it in hvmemul_do_io().
>
> Suggested-by: Paul Durrant
> Signed-off-by: Jan Beulich
> ---
> RFC: While this avoids some open coding, generated code looks to be
> worse for that particular case. I'm therefore not certain that we
> want this change (or perhaps just the function name/signature
> change portion).
>
FAOD my reason for suggesting it was such that exactly the same test
implementation is used in all cases to decide whether I/O completion is needed.
Paul
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -282,11 +282,7 @@ static int hvmemul_do_io(
> rc = hvm_send_ioreq(s, &p, 0);
> if ( rc != X86EMUL_RETRY || currd->is_shutting_down )
> vio->io_req.state = STATE_IOREQ_NONE;
> -/*
> - * This effectively is !hvm_vcpu_io_need_completion(vio),
> slightly
> - * optimized and using local variables we have available.
> - */
> -else if ( data_is_addr || (!is_mmio && dir == IOREQ_WRITE) )
> +else if ( !hvm_ioreq_needs_completion(&vio->io_req) )
> rc = X86EMUL_OKAY;
> }
> break;
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -89,7 +89,7 @@ bool hvm_emulate_one_insn(hvm_emulate_va
>
> rc = hvm_emulate_one(&ctxt);
>
> -if ( hvm_vcpu_io_need_completion(vio) )
> +if ( hvm_ioreq_needs_completion(&vio->io_req) )
> vio->io_completion = HVMIO_mmio_completion;
> else
> vio->mmio_access = (struct npfec){};
> @@ -142,7 +142,7 @@ bool handle_pio(uint16_t port, unsigned
>
> rc = hvmemul_do_pio_buffer(port, size, dir, &data);
>
> -if ( hvm_vcpu_io_need_completion(vio) )
> +if ( hvm_ioreq_needs_completion(&vio->io_req) )
> vio->io_completion = HVMIO_pio_completion;
>
> switch ( rc )
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -110,15 +110,15 @@ bool hvm_io_pending(struct vcpu *v)
> static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data)
> {
> struct vcpu *v = sv->vcpu;
> -struct hvm_vcpu_io *vio = &v->arch.hvm_vcpu.hvm_io;
> +ioreq_t *ioreq = &v->arch.hvm_vcpu.hvm_io.io_req;
>
> -if ( hvm_vcpu_io_need_completion(vio) )
> +if ( hvm_ioreq_needs_completion(ioreq) )
> {
> -vio->io_req.state = STATE_IORESP_READY;
> -vio->io_req.data = data;
> +ioreq->state = STATE_IORESP_READY;
> +ioreq->data = data;
> }
> else
> -vio->io_req.state = STATE_IOREQ_NONE;
> +ioreq->state = STATE_IOREQ_NONE;
>
> msix_write_completion(v);
> vcpu_end_shutdown_deferral(v);
> --- a/xen/arch/x86/hvm/vmx/realmode.c
> +++ b/xen/arch/x86/hvm/vmx/realmode.c
> @@ -103,7 +103,7 @@ void vmx_realmode_emulate_one(struct hvm
>
> rc = hvm_emulate_one(hvmemul_ctxt);
>
> -if ( hvm_vcpu_io_need_completion(vio) )
> +if ( hvm_ioreq_needs_completion(&vio->io_req) )
> vio->io_completion = HVMIO_realmode_completion;
>
> if ( rc == X86EMUL_UNHANDLEABLE )
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -91,12 +91,11 @@ struct hvm_vcpu_io {
> const struct g2m_ioport *g2m_ioport;
> };
>
> -static inline bool hvm_vcpu_io_need_completion(const struct hvm_vcpu_io
> *vio)
> +static inline bool hvm_ioreq_needs_completion(const ioreq_t *ioreq)
> {
> -return (vio->io_req.state == STATE_IOREQ_READY) &&
> - !vio->io_req.data_is_ptr &&
> - (vio->io_req.type != IOREQ_TYPE_PIO ||
> -vio->io_req.dir != IOREQ_WRITE);
> +return ioreq->state == STATE_IOREQ_READY &&
> + !ioreq->data_is_ptr &&
> + (ioreq->type != IOREQ_TYPE_PIO || ioreq->dir != IOREQ_WRITE);
> }
>
> struct nestedvcpu {
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/HVM: suppress I/O completion for port output
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 April 2018 14:24
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Juergen Gross
> Subject: [PATCH 1/2] x86/HVM: suppress I/O completion for port output
>
> We don't break up port requests in case they cross emulation entity
> boundaries, and a write to an I/O port is necessarily the last
> operation of an instruction instance, so there's no need to re-invoke
> the full emulation path upon receiving the result from an external
> emulator.
>
> In case we want to properly split port accesses in the future, this
> change will need to be reverted, as it would prevent things working
> correctly when e.g. the first part needs to go to an external emulator,
> while the second part is to be handled internally.
>
> While this addresses the reported problem of Windows paging out the
> buffer underneath an in-process REP OUTS, it does not address the wider
> problem of the re-issued insn (to the insn emulator) being prone to
> raise an exception (#PF) during a replayed, previously successful memory
> access (we only record prior MMIO accesses).
>
> Leaving aside the problem tried to be worked around here, I think the
> performance aspect alone is a good reason to change the behavior.
>
> Also take the opportunity and change bool_t -> bool as
> hvm_vcpu_io_need_completion()'s return type.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -282,7 +282,11 @@ static int hvmemul_do_io(
> rc = hvm_send_ioreq(s, &p, 0);
> if ( rc != X86EMUL_RETRY || currd->is_shutting_down )
> vio->io_req.state = STATE_IOREQ_NONE;
> -else if ( data_is_addr )
> +/*
> + * This effectively is !hvm_vcpu_io_need_completion(vio),
> slightly
> + * optimized and using local variables we have available.
> + */
> +else if ( data_is_addr || (!is_mmio && dir == IOREQ_WRITE) )
> rc = X86EMUL_OKAY;
> }
> break;
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -91,10 +91,12 @@ struct hvm_vcpu_io {
> const struct g2m_ioport *g2m_ioport;
> };
>
> -static inline bool_t hvm_vcpu_io_need_completion(const struct
> hvm_vcpu_io *vio)
> +static inline bool hvm_vcpu_io_need_completion(const struct
> hvm_vcpu_io *vio)
> {
> return (vio->io_req.state == STATE_IOREQ_READY) &&
> - !vio->io_req.data_is_ptr;
> + !vio->io_req.data_is_ptr &&
> + (vio->io_req.type != IOREQ_TYPE_PIO ||
> +vio->io_req.dir != IOREQ_WRITE);
> }
>
> struct nestedvcpu {
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] x86/HVM: suppress I/O completion for port output
We don't break up port requests in case they cross emulation entity
boundaries, and a write to an I/O port is necessarily the last
operation of an instruction instance, so there's no need to re-invoke
the full emulation path upon receiving the result from an external
emulator.
In case we want to properly split port accesses in the future, this
change will need to be reverted, as it would prevent things working
correctly when e.g. the first part needs to go to an external emulator,
while the second part is to be handled internally.
While this addresses the reported problem of Windows paging out the
buffer underneath an in-process REP OUTS, it does not address the wider
problem of the re-issued insn (to the insn emulator) being prone to
raise an exception (#PF) during a replayed, previously successful memory
access (we only record prior MMIO accesses).
Leaving aside the problem tried to be worked around here, I think the
performance aspect alone is a good reason to change the behavior.
Also take the opportunity and change bool_t -> bool as
hvm_vcpu_io_need_completion()'s return type.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -282,7 +282,11 @@ static int hvmemul_do_io(
rc = hvm_send_ioreq(s, &p, 0);
if ( rc != X86EMUL_RETRY || currd->is_shutting_down )
vio->io_req.state = STATE_IOREQ_NONE;
-else if ( data_is_addr )
+/*
+ * This effectively is !hvm_vcpu_io_need_completion(vio), slightly
+ * optimized and using local variables we have available.
+ */
+else if ( data_is_addr || (!is_mmio && dir == IOREQ_WRITE) )
rc = X86EMUL_OKAY;
}
break;
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -91,10 +91,12 @@ struct hvm_vcpu_io {
const struct g2m_ioport *g2m_ioport;
};
-static inline bool_t hvm_vcpu_io_need_completion(const struct hvm_vcpu_io *vio)
+static inline bool hvm_vcpu_io_need_completion(const struct hvm_vcpu_io *vio)
{
return (vio->io_req.state == STATE_IOREQ_READY) &&
- !vio->io_req.data_is_ptr;
+ !vio->io_req.data_is_ptr &&
+ (vio->io_req.type != IOREQ_TYPE_PIO ||
+vio->io_req.dir != IOREQ_WRITE);
}
struct nestedvcpu {
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] x86/HVM: alter completion-needed checking
The function only looks at the ioreq_t, so pass it a pointer to just
that. Also use it in hvmemul_do_io().
Suggested-by: Paul Durrant
Signed-off-by: Jan Beulich
---
RFC: While this avoids some open coding, generated code looks to be
worse for that particular case. I'm therefore not certain that we
want this change (or perhaps just the function name/signature
change portion).
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -282,11 +282,7 @@ static int hvmemul_do_io(
rc = hvm_send_ioreq(s, &p, 0);
if ( rc != X86EMUL_RETRY || currd->is_shutting_down )
vio->io_req.state = STATE_IOREQ_NONE;
-/*
- * This effectively is !hvm_vcpu_io_need_completion(vio), slightly
- * optimized and using local variables we have available.
- */
-else if ( data_is_addr || (!is_mmio && dir == IOREQ_WRITE) )
+else if ( !hvm_ioreq_needs_completion(&vio->io_req) )
rc = X86EMUL_OKAY;
}
break;
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -89,7 +89,7 @@ bool hvm_emulate_one_insn(hvm_emulate_va
rc = hvm_emulate_one(&ctxt);
-if ( hvm_vcpu_io_need_completion(vio) )
+if ( hvm_ioreq_needs_completion(&vio->io_req) )
vio->io_completion = HVMIO_mmio_completion;
else
vio->mmio_access = (struct npfec){};
@@ -142,7 +142,7 @@ bool handle_pio(uint16_t port, unsigned
rc = hvmemul_do_pio_buffer(port, size, dir, &data);
-if ( hvm_vcpu_io_need_completion(vio) )
+if ( hvm_ioreq_needs_completion(&vio->io_req) )
vio->io_completion = HVMIO_pio_completion;
switch ( rc )
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -110,15 +110,15 @@ bool hvm_io_pending(struct vcpu *v)
static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data)
{
struct vcpu *v = sv->vcpu;
-struct hvm_vcpu_io *vio = &v->arch.hvm_vcpu.hvm_io;
+ioreq_t *ioreq = &v->arch.hvm_vcpu.hvm_io.io_req;
-if ( hvm_vcpu_io_need_completion(vio) )
+if ( hvm_ioreq_needs_completion(ioreq) )
{
-vio->io_req.state = STATE_IORESP_READY;
-vio->io_req.data = data;
+ioreq->state = STATE_IORESP_READY;
+ioreq->data = data;
}
else
-vio->io_req.state = STATE_IOREQ_NONE;
+ioreq->state = STATE_IOREQ_NONE;
msix_write_completion(v);
vcpu_end_shutdown_deferral(v);
--- a/xen/arch/x86/hvm/vmx/realmode.c
+++ b/xen/arch/x86/hvm/vmx/realmode.c
@@ -103,7 +103,7 @@ void vmx_realmode_emulate_one(struct hvm
rc = hvm_emulate_one(hvmemul_ctxt);
-if ( hvm_vcpu_io_need_completion(vio) )
+if ( hvm_ioreq_needs_completion(&vio->io_req) )
vio->io_completion = HVMIO_realmode_completion;
if ( rc == X86EMUL_UNHANDLEABLE )
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -91,12 +91,11 @@ struct hvm_vcpu_io {
const struct g2m_ioport *g2m_ioport;
};
-static inline bool hvm_vcpu_io_need_completion(const struct hvm_vcpu_io *vio)
+static inline bool hvm_ioreq_needs_completion(const ioreq_t *ioreq)
{
-return (vio->io_req.state == STATE_IOREQ_READY) &&
- !vio->io_req.data_is_ptr &&
- (vio->io_req.type != IOREQ_TYPE_PIO ||
-vio->io_req.dir != IOREQ_WRITE);
+return ioreq->state == STATE_IOREQ_READY &&
+ !ioreq->data_is_ptr &&
+ (ioreq->type != IOREQ_TYPE_PIO || ioreq->dir != IOREQ_WRITE);
}
struct nestedvcpu {
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] pci: a workaround for nonstandard PCI devices whose PBA shares
... the same page with other registers which are not relevant to MSI-X. Xen
marks pages where PBA resides as read-only. When assigning such devices to
guest, device driver writes MSI-X irrelevant registers on those pages would
lead to an EPT violation and the guest is destroyed because no handler is
registered for those address range. In order to make guest capable to use such
kind of devices, trapping very frequent write accesses is not a good idea for
it would significantly impact the performance.
This patch provides a workaround with caveat. Specifically, an option is
introduced to specify a list of devices. For those devices, Xen doesn't
control the access right to pages where PBA resides. Hence, guest device
driver is able to write those pages and functions well. Note that adding an
untrusted device to this option may endanger security of the entire system.
Signed-off-by: Chao Gao
---
Given that parsing parameters starts at very early stage in which xmalloc is
unusable, I choose to continue using an array other than a list to store SBDFs
of such kind devices, like the way how we manage phantom_devs.
changes in v2:
- use a more informative name, pba_shared_quirk, to describe the quirk
- use pci_sbdf_t other than uint32_t
- disable this quirk when PBA shares the same page with other RO mmio
- exit the loop in alloc_pdev() once a match is found
---
docs/misc/xen-command-line.markdown | 10
xen/arch/x86/msi.c | 20 ++--
xen/drivers/passthrough/pci.c | 48 +++--
xen/include/asm-x86/msi.h | 1 +
4 files changed, 75 insertions(+), 4 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index b353352..7c10e63 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
> Default: `on`
+### pba\_shared\_quirk
+> `= List of [:]:.`
+
+Specify a list of SBDF of devices. When assigning devices in this list
+to guest, reading or writing the page where MSI-X PBA resides are
+allowed. This option provides a workaround for nonstandard PCI devices
+whose MSI-X PBA shares the same 4K-byte page with registers irrelevant
+to MSI-X. Note that adding an untrusted device to this option would
+undermine security of the entire system.
+
### pci
> `= {no-}serr | {no-}perr`
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 5567990..53280ec 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -992,7 +992,22 @@ static int msix_capability_init(struct pci_dev *dev,
if ( rangeset_add_range(mmio_ro_ranges, msix->table.first,
msix->table.last) )
WARN();
-if ( rangeset_add_range(mmio_ro_ranges, msix->pba.first,
+
+/*
+ * If pages where MSI-X PBA resides overlap with other read-only mmio
+ * range, pba_shared_quirk won't meet our desire. Hence disable it.
+ */
+if ( msix->pba_shared_quirk_enabled &&
+ rangeset_overlaps_range(mmio_ro_ranges, msix->pba.first,
+ msix->pba.last) )
+{
+printk("PBA_shared_quirk is disabled for %04x:%02x:%02x.%u",
+ seg, bus, slot, func);
+msix->pba_shared_quirk_enabled = false;
+}
+
+if ( !msix->pba_shared_quirk_enabled &&
+ rangeset_add_range(mmio_ro_ranges, msix->pba.first,
msix->pba.last) )
WARN();
@@ -1139,7 +1154,8 @@ static void _pci_cleanup_msix(struct arch_msix *msix)
if ( rangeset_remove_range(mmio_ro_ranges, msix->table.first,
msix->table.last) )
WARN();
-if ( rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
+if ( !msix->pba_shared_quirk_enabled &&
+ rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
msix->pba.last) )
WARN();
}
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1db69d5..993aa22 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -184,6 +184,39 @@ static int __init parse_phantom_dev(const char *str)
}
custom_param("pci-phantom", parse_phantom_dev);
+static struct pba_shared_quirk_dev {
+pci_sbdf_t sbdf;
+} pba_shared_quirk_devs[8];
+static unsigned int nr_pba_shared_quirk_devs;
+
+static int __init parse_pba_shared_quirk(const char *str)
+{
+for ( ; ; )
+{
+unsigned int seg, bus, dev, func;
+
+if ( nr_pba_shared_quirk_devs >= ARRAY_SIZE(pba_shared_quirk_devs) )
+return -E2BIG;
+
+str = parse_pci(str, &seg, &bus, &dev, &func);
+if ( !str )
+return -EINVAL;
+
+pba_shared_quirk_devs[nr_pba_shared_quirk_devs++].sbdf.sbdf =
+PC
[Xen-devel] [xen-unstable-smoke test] 122133: regressions - FAIL
flight 122133 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122133/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 121876 build-armhf 6 xen-buildfail REGR. vs. 121876 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen f20a6e30931a92c9810ff21cfdcd85e22f12cddc baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 121876 2018-04-05 10:04:25 Z4 days Failing since121889 2018-04-05 13:02:10 Z3 days 36 attempts Testing same since 122133 2018-04-09 11:01:19 Z0 days1 attempts People who touched revisions under test: Amit Singh Tomar Andre Przywara Andre Pzywara Andrew Cooper George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Marcello Seri Marcus of Wetware Labs Marek Marczykowski-Górecki Petre Eftime Razvan Cojocaru Stefano Stabellini Tim Deegan Wei Liu jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 722 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/2] x86/HVM: I/O completion adjustments
1: suppress I/O completion for port output 2: alter completion-needed checking Signed-off-by: Jan Beulich Patch 1, while not addressing the fundamental underlying problem, is strictly a fix for an observed bug (with Windows Server 2016) (besides also being an optimization), so should be considered for 4.11. Patch 2, otoh, is not even clear whether we want it at all (see there). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86/HVM: suppress I/O completion for port output
>>> On 29.03.18 at 11:13, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 29 March 2018 10:10
>> >> --- a/xen/include/asm-x86/hvm/vcpu.h
>> >> +++ b/xen/include/asm-x86/hvm/vcpu.h
>> >> @@ -91,10 +91,12 @@ struct hvm_vcpu_io {
>> >> const struct g2m_ioport *g2m_ioport;
>> >> };
>> >>
>> >> -static inline bool_t hvm_vcpu_io_need_completion(const struct
>> >> hvm_vcpu_io *vio)
>> >> +static inline bool hvm_vcpu_io_need_completion(const struct
>> >> hvm_vcpu_io *vio)
>> >> {
>> >> return (vio->io_req.state == STATE_IOREQ_READY) &&
>> >> - !vio->io_req.data_is_ptr;
>> >> + !vio->io_req.data_is_ptr &&
>> >> + (vio->io_req.type != IOREQ_TYPE_PIO ||
>> >> +vio->io_req.dir != IOREQ_WRITE);
>> >
>> > ... now that you've updated it here.
>>
>> It could have been before, and it wasn't, so I didn't want to change
>> that. My assumption is that the function wasn't used to leverage
>> local variables (and avoid the .state comparison altogether).
>
> Yes, that's why it was like it is.
>
>> Technically it could be switched, I agree. I guess I should at least
>> attach a comment, clarifying that this is an open-coded, slightly
>> optimized variant of the function.
>>
>
> Alternatively if the macro is modified to take an ioreq_t pointer directly
> rather than a struct hvm_vcpu_io pointer, then I think you could just pass
> the on-stack ioreq_t to it in hvmemul_do_io() and avoid any real need for the
> open-coded test.
We can't use the on-stack ioreq_t, as hvm_send_ioreq() alters its
state field. I'm now going to see whether &vio->io_req could be
used here, but the first try already produced worse code, and I
don't expect this extra change to improve things (but rather make
them slightly worse).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 122120: all pass - PUSHED
flight 122120 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/122120/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 95cc4962167572089a99be324574094ba22415ad baseline version: ovmf e037e88cd81d4ac63dd627719c87c305bf0b439e Last test of basis 122092 2018-04-08 09:46:57 Z1 days Testing same since 122120 2018-04-09 03:22:26 Z0 days1 attempts People who touched revisions under test: Feng, YunhuaX Yunhua Feng jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git e037e88cd8..95cc496216 95cc4962167572089a99be324574094ba22415ad -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/pv: Fix up erroneous segments for 32bit syscall entry
On 09/04/18 13:02, Jan Beulich wrote:
On 09.04.18 at 12:44, wrote:
>> On Mon, Apr 09, 2018 at 10:44:47AM +0100, Andrew Cooper wrote:
>>> The existing FLAT_KERNEL_SS expands to the correct value, 0xe02b, but is the
>>> wrong constant to use. Switch to FLAT_USER_SS32.
>>>
>>> For compat domains however, the reported values are entirely bogus.
>>> FLAT_USER_SS32 (value 0xe02b) is FLAT_RING3_CS in the 32bit ABI, while
>>> FLAT_USER_CS32 (value 0xe023) is FLAT_RING1_DS with an RPL of 3.
>>>
>>> The guests SYSCALL callback is invoked with a broken iret frame, and if left
>>> unmodified by the guest, will fail on the way back out when Xen's iret tries
>>> to load a code segment into %ss.
>>>
>>> In practice, this is only a problem for 32bit PV guests on AMD hardware, as
>>> Intel hardware doesn't permit the SYSCALL instruction outside of 64bit mode.
>>>
>>> This appears to have been broken ever since 64bit support was added to Xen,
>>> and has gone unnoticed because Linux doesn't use SYSCALL in 32bit builds.
>>>
>>> Signed-off-by: Andrew Cooper
>>> ---
>>> CC: Jan Beulich
>>> CC: Roger Pau Monné
>>> CC: Wei Liu
>>> CC: Juergen Gross
>>>
>>> This wants backporting basically everywhere, and as such, also wants to be
>>> considered for 4.11 at this point.
>>> ---
>>> xen/arch/x86/x86_64/compat/entry.S | 7 ++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/x86/x86_64/compat/entry.S
>> b/xen/arch/x86/x86_64/compat/entry.S
>>> index 6c7fcf9..2bc046c 100644
>>> --- a/xen/arch/x86/x86_64/compat/entry.S
>>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>>> @@ -197,7 +197,7 @@ ENTRY(cstar_enter)
>>> /* sti could live here when we don't switch page tables below. */
>>> CR4_PV32_RESTORE
>>> movq 8(%rsp),%rax /* Restore %rax. */
>>> -movq $FLAT_KERNEL_SS,8(%rsp)
>>> +movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat
>>> handled lower. */
>>> pushq %r11
>>> pushq $FLAT_USER_CS32
>>> pushq %rcx
>>> @@ -223,6 +223,11 @@ ENTRY(cstar_enter)
>>> movq VCPU_domain(%rbx),%rcx
>>> cmpb $0,DOMAIN_is_32bit_pv(%rcx)
>>> jeswitch_to_kernel
>>> +
>>> +/* Fix up reported %cs/%ss for compat domains. */
>>> +movl $0xe033, UREGS_ss(%rsp) /* Compat FLAT_RING3_SS */
>>> +movl $0xe02b, UREGS_cs(%rsp) /* Compat FLAT_RING3_CS */
>> I wonder if it would be better to introduce COMPAT_FLAT_RING3_* in
>> xen-x86_64.h?
> We already have FLAT_COMPAT_RING3_{CS,DS,SS} - I don't see
> why two of them couldn't be used here (or their FLAT_COMPAT_USER_*
> aliases). With that
> Reviewed-by: Jan Beulich
Ooh - so we have. I'd completely missed those. Will fix.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/pv: Fix up erroneous segments for 32bit syscall entry
>>> On 09.04.18 at 12:44, wrote:
> On Mon, Apr 09, 2018 at 10:44:47AM +0100, Andrew Cooper wrote:
>> The existing FLAT_KERNEL_SS expands to the correct value, 0xe02b, but is the
>> wrong constant to use. Switch to FLAT_USER_SS32.
>>
>> For compat domains however, the reported values are entirely bogus.
>> FLAT_USER_SS32 (value 0xe02b) is FLAT_RING3_CS in the 32bit ABI, while
>> FLAT_USER_CS32 (value 0xe023) is FLAT_RING1_DS with an RPL of 3.
>>
>> The guests SYSCALL callback is invoked with a broken iret frame, and if left
>> unmodified by the guest, will fail on the way back out when Xen's iret tries
>> to load a code segment into %ss.
>>
>> In practice, this is only a problem for 32bit PV guests on AMD hardware, as
>> Intel hardware doesn't permit the SYSCALL instruction outside of 64bit mode.
>>
>> This appears to have been broken ever since 64bit support was added to Xen,
>> and has gone unnoticed because Linux doesn't use SYSCALL in 32bit builds.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>> CC: Wei Liu
>> CC: Juergen Gross
>>
>> This wants backporting basically everywhere, and as such, also wants to be
>> considered for 4.11 at this point.
>> ---
>> xen/arch/x86/x86_64/compat/entry.S | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/x86_64/compat/entry.S
> b/xen/arch/x86/x86_64/compat/entry.S
>> index 6c7fcf9..2bc046c 100644
>> --- a/xen/arch/x86/x86_64/compat/entry.S
>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>> @@ -197,7 +197,7 @@ ENTRY(cstar_enter)
>> /* sti could live here when we don't switch page tables below. */
>> CR4_PV32_RESTORE
>> movq 8(%rsp),%rax /* Restore %rax. */
>> -movq $FLAT_KERNEL_SS,8(%rsp)
>> +movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat
>> handled lower. */
>> pushq %r11
>> pushq $FLAT_USER_CS32
>> pushq %rcx
>> @@ -223,6 +223,11 @@ ENTRY(cstar_enter)
>> movq VCPU_domain(%rbx),%rcx
>> cmpb $0,DOMAIN_is_32bit_pv(%rcx)
>> jeswitch_to_kernel
>> +
>> +/* Fix up reported %cs/%ss for compat domains. */
>> +movl $0xe033, UREGS_ss(%rsp) /* Compat FLAT_RING3_SS */
>> +movl $0xe02b, UREGS_cs(%rsp) /* Compat FLAT_RING3_CS */
>
> I wonder if it would be better to introduce COMPAT_FLAT_RING3_* in
> xen-x86_64.h?
We already have FLAT_COMPAT_RING3_{CS,DS,SS} - I don't see
why two of them couldn't be used here (or their FLAT_COMPAT_USER_*
aliases). With that
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/pv: Fix up erroneous segments for 32bit syscall entry
On 09/04/18 11:49, Juergen Gross wrote: > On 09/04/18 12:46, Andrew Cooper wrote: >> On 09/04/18 11:44, Wei Liu wrote: >>> On Mon, Apr 09, 2018 at 10:44:47AM +0100, Andrew Cooper wrote: The existing FLAT_KERNEL_SS expands to the correct value, 0xe02b, but is the wrong constant to use. Switch to FLAT_USER_SS32. For compat domains however, the reported values are entirely bogus. FLAT_USER_SS32 (value 0xe02b) is FLAT_RING3_CS in the 32bit ABI, while FLAT_USER_CS32 (value 0xe023) is FLAT_RING1_DS with an RPL of 3. The guests SYSCALL callback is invoked with a broken iret frame, and if left unmodified by the guest, will fail on the way back out when Xen's iret tries to load a code segment into %ss. In practice, this is only a problem for 32bit PV guests on AMD hardware, as Intel hardware doesn't permit the SYSCALL instruction outside of 64bit mode. This appears to have been broken ever since 64bit support was added to Xen, and has gone unnoticed because Linux doesn't use SYSCALL in 32bit builds. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Juergen Gross This wants backporting basically everywhere, and as such, also wants to be considered for 4.11 at this point. --- xen/arch/x86/x86_64/compat/entry.S | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S index 6c7fcf9..2bc046c 100644 --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -197,7 +197,7 @@ ENTRY(cstar_enter) /* sti could live here when we don't switch page tables below. */ CR4_PV32_RESTORE movq 8(%rsp),%rax /* Restore %rax. */ -movq $FLAT_KERNEL_SS,8(%rsp) +movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat handled lower. */ pushq %r11 pushq $FLAT_USER_CS32 pushq %rcx @@ -223,6 +223,11 @@ ENTRY(cstar_enter) movq VCPU_domain(%rbx),%rcx cmpb $0,DOMAIN_is_32bit_pv(%rcx) jeswitch_to_kernel + +/* Fix up reported %cs/%ss for compat domains. */ +movl $0xe033, UREGS_ss(%rsp) /* Compat FLAT_RING3_SS */ +movl $0xe02b, UREGS_cs(%rsp) /* Compat FLAT_RING3_CS */ >>> I wonder if it would be better to introduce COMPAT_FLAT_RING3_* in >>> xen-x86_64.h? >>> >>> In any case, the reasoning and code looks correct to me: >>> >>> Reviewed-by: Wei Liu >> I considered that, and am open to suggestions. The problem is that we >> don't want to put COMPAT definitions in that header file, because they >> are inapplicable to 64bit PV guests, who are intended consumers. > Add a way to include x86_32.h defining the needed COMPAT_* macros only? For the same argument as the 64bit side, x86_32.h shouldn't contain COMPAT_* defines, as they are inapplicable. Furthermore, the constants can't be shared in such an include, because of naming conflicts with x86_64.h. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [rumprun test] 122121: all pass - PUSHED
flight 122121 rumprun real [real] http://logs.test-lab.xenproject.org/osstest/logs/122121/ Perfect :-) All tests in this flight passed as required version targeted for testing: rumprun 085e6e00ab04f6802abc70a45beea4c7d95c43d3 baseline version: rumprun c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 Last test of basis 106754 2017-03-18 04:21:25 Z 387 days Failing since120360 2018-03-09 04:19:20 Z 31 days 28 attempts Testing same since 122121 2018-04-09 04:20:36 Z0 days1 attempts People who touched revisions under test: Antti Kantee Kent McLeod Kent McLeod Naja Melan Sebastian Wicki Wei Liu yarl <5469248+ya...@users.noreply.github.com> jobs: build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-amd64-amd64-rumprun-amd64 pass test-amd64-i386-rumprun-i386 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/rumprun.git c7f2f01..085e6e0 085e6e00ab04f6802abc70a45beea4c7d95c43d3 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v10] x86/altp2m: support for setting restrictions for an array of pages
>>> On 30.03.18 at 12:32, wrote: > On 03/30/2018 11:14 AM, Razvan Cojocaru wrote: >> On 03/30/2018 01:03 PM, George Dunlap wrote: >>> In response to v8, I said: "FWIW the approach looks good to me here. >>> You mainly need an x86 maintainer's ack and a toolstack maintainer's >>> ack (of which I am neither)." >>> >>> I'm not a maintainer of `xen/arch/x86/hvm/hvm.c` -- that's Andy and Jan. >>> >>> OTOH, altp2m is a p2m feature, so arguably it should be primarily my >>> responsibility. >>> >>> Anyway, I'll take a look at it today; if I can give a Reviewed-by, then >>> maybe we can negotiate for it to go in with just that (with my committer >>> hat on on), or for Andy to Ack it based mostly on my R-b. >> >> Thank you for your help! And sorry if I've mistakenly named you here, >> quite possibly I've misunderstood Jan's earlier reply. > > No, you were clearly taking a lead from Jan -- I'm not sure exactly what > he had in mind by naming me (i.e., with the strict rules for who has to > approve what). I was just explaining why it didn't already have an R-b > from me. :-) Well, I had you in mind with the topic (altp2m) in mind, alongside the strict file based rules which would limit acks to Andrew and me. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools/libxl: Fix build following c/s 74fd984ae
Hi,
On 09/04/18 12:07, Wei Liu wrote:
On Mon, Apr 09, 2018 at 11:29:28AM +0100, Julien Grall wrote:
Hi,
On 06/04/18 10:33, Wei Liu wrote:
On Fri, Apr 06, 2018 at 10:03:14AM +0100, Julien Grall wrote:
This is wrong. gicv_to_string works on XEN_DOMCTL_* define and not the
LIBXL_GIC_*.
So this will not give the right output.
I would suggest to revert that patch and I will send one that actually fix the
compilation.
Not sure I would be able to do it today thought.
OK, I will revert this patch.
I have looked at a potential way to fix it. The original patch (74fd984ae6)
assumption is incorrect. Some of information from xc_domain_configuration_t
is not written back ton libxl__domain_build_state.
For instance, this is the case of the clock frequency. That field is used to
workaround bootloader/firmware that didn't configure correct CNTFRQ. If we
detect such platform, we will read the host clock frequency from the host
Device-Tree and write it to the guest Device-Tree. This should never be
exposed to the guest.
Not sure I follow. If you write that value to guest DT, guest should be
able to see it?
On normal system the clock frequency can be read by using the system
register CNTFRQ. This register is usually initialized by the
firmware/bootloader. However, on some platforms the firmware does not do
its job and therefore CNTFRQ is configured incorrectly. To workaround
the problem, a property exists in the host DT with the correct frequency.
On the broken platform, the field clock_frequency in
xc_domain_configuration_t will be written by the hypervisor with the
correct frequency.
Arguably, this field should not belong to xc_domain_configuration_t. So I
can see two solutions:
1) Store the frequency in libxl__domain_build_state
2) Introduce a different hypercall to get the system frequency. I guess
we
could piggy-back on Andrew's idea to provide
XEN_DOMCTL_{get,set}_arch_settings.
The latter will require some rework in the code and define a new API. Not
sure if that would be acceptable for Xen 4.11.
Any opinions?
#1 seems simpler to me, especially since we already have vuart (ARM
only) information in libxl__domain_build_state.
I will have a look at that.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools/libxl: Fix build following c/s 74fd984ae
On Mon, Apr 09, 2018 at 11:29:28AM +0100, Julien Grall wrote:
> Hi,
>
> On 06/04/18 10:33, Wei Liu wrote:
> > On Fri, Apr 06, 2018 at 10:03:14AM +0100, Julien Grall wrote:
> > > This is wrong. gicv_to_string works on XEN_DOMCTL_* define and not the
> > > LIBXL_GIC_*.
> > > So this will not give the right output.
> > >
> > > I would suggest to revert that patch and I will send one that actually
> > > fix the compilation.
> > > Not sure I would be able to do it today thought.
> > >
> >
> > OK, I will revert this patch.
>
> I have looked at a potential way to fix it. The original patch (74fd984ae6)
> assumption is incorrect. Some of information from xc_domain_configuration_t
> is not written back ton libxl__domain_build_state.
>
> For instance, this is the case of the clock frequency. That field is used to
> workaround bootloader/firmware that didn't configure correct CNTFRQ. If we
> detect such platform, we will read the host clock frequency from the host
> Device-Tree and write it to the guest Device-Tree. This should never be
> exposed to the guest.
Not sure I follow. If you write that value to guest DT, guest should be
able to see it?
>
> Arguably, this field should not belong to xc_domain_configuration_t. So I
> can see two solutions:
> 1) Store the frequency in libxl__domain_build_state
> 2) Introduce a different hypercall to get the system frequency. I guess
> we
> could piggy-back on Andrew's idea to provide
> XEN_DOMCTL_{get,set}_arch_settings.
>
> The latter will require some rework in the code and define a new API. Not
> sure if that would be acceptable for Xen 4.11.
>
> Any opinions?
#1 seems simpler to me, especially since we already have vuart (ARM
only) information in libxl__domain_build_state.
Wei.
>
> Cheers,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 122126: regressions - FAIL
flight 122126 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122126/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 121876 build-armhf 6 xen-buildfail REGR. vs. 121876 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen e62e140daa393c89342f7ca19906e303ebedf8db baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 121876 2018-04-05 10:04:25 Z4 days Failing since121889 2018-04-05 13:02:10 Z3 days 35 attempts Testing same since 122036 2018-04-07 15:01:18 Z1 days 17 attempts People who touched revisions under test: Amit Singh Tomar Andre Przywara Andre Pzywara Andrew Cooper George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Marcello Seri Marcus of Wetware Labs Marek Marczykowski-Górecki Petre Eftime Razvan Cojocaru Stefano Stabellini Tim Deegan Wei Liu jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 712 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/pv: Fix up erroneous segments for 32bit syscall entry
On 09/04/18 12:46, Andrew Cooper wrote: > On 09/04/18 11:44, Wei Liu wrote: >> On Mon, Apr 09, 2018 at 10:44:47AM +0100, Andrew Cooper wrote: >>> The existing FLAT_KERNEL_SS expands to the correct value, 0xe02b, but is the >>> wrong constant to use. Switch to FLAT_USER_SS32. >>> >>> For compat domains however, the reported values are entirely bogus. >>> FLAT_USER_SS32 (value 0xe02b) is FLAT_RING3_CS in the 32bit ABI, while >>> FLAT_USER_CS32 (value 0xe023) is FLAT_RING1_DS with an RPL of 3. >>> >>> The guests SYSCALL callback is invoked with a broken iret frame, and if left >>> unmodified by the guest, will fail on the way back out when Xen's iret tries >>> to load a code segment into %ss. >>> >>> In practice, this is only a problem for 32bit PV guests on AMD hardware, as >>> Intel hardware doesn't permit the SYSCALL instruction outside of 64bit mode. >>> >>> This appears to have been broken ever since 64bit support was added to Xen, >>> and has gone unnoticed because Linux doesn't use SYSCALL in 32bit builds. >>> >>> Signed-off-by: Andrew Cooper >>> --- >>> CC: Jan Beulich >>> CC: Roger Pau Monné >>> CC: Wei Liu >>> CC: Juergen Gross >>> >>> This wants backporting basically everywhere, and as such, also wants to be >>> considered for 4.11 at this point. >>> --- >>> xen/arch/x86/x86_64/compat/entry.S | 7 ++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/xen/arch/x86/x86_64/compat/entry.S >>> b/xen/arch/x86/x86_64/compat/entry.S >>> index 6c7fcf9..2bc046c 100644 >>> --- a/xen/arch/x86/x86_64/compat/entry.S >>> +++ b/xen/arch/x86/x86_64/compat/entry.S >>> @@ -197,7 +197,7 @@ ENTRY(cstar_enter) >>> /* sti could live here when we don't switch page tables below. */ >>> CR4_PV32_RESTORE >>> movq 8(%rsp),%rax /* Restore %rax. */ >>> -movq $FLAT_KERNEL_SS,8(%rsp) >>> +movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat >>> handled lower. */ >>> pushq %r11 >>> pushq $FLAT_USER_CS32 >>> pushq %rcx >>> @@ -223,6 +223,11 @@ ENTRY(cstar_enter) >>> movq VCPU_domain(%rbx),%rcx >>> cmpb $0,DOMAIN_is_32bit_pv(%rcx) >>> jeswitch_to_kernel >>> + >>> +/* Fix up reported %cs/%ss for compat domains. */ >>> +movl $0xe033, UREGS_ss(%rsp) /* Compat FLAT_RING3_SS */ >>> +movl $0xe02b, UREGS_cs(%rsp) /* Compat FLAT_RING3_CS */ >> I wonder if it would be better to introduce COMPAT_FLAT_RING3_* in >> xen-x86_64.h? >> >> In any case, the reasoning and code looks correct to me: >> >> Reviewed-by: Wei Liu > > I considered that, and am open to suggestions. The problem is that we > don't want to put COMPAT definitions in that header file, because they > are inapplicable to 64bit PV guests, who are intended consumers. Add a way to include x86_32.h defining the needed COMPAT_* macros only? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/pv: Fix up erroneous segments for 32bit syscall entry
On 09/04/18 11:44, Wei Liu wrote: > On Mon, Apr 09, 2018 at 10:44:47AM +0100, Andrew Cooper wrote: >> The existing FLAT_KERNEL_SS expands to the correct value, 0xe02b, but is the >> wrong constant to use. Switch to FLAT_USER_SS32. >> >> For compat domains however, the reported values are entirely bogus. >> FLAT_USER_SS32 (value 0xe02b) is FLAT_RING3_CS in the 32bit ABI, while >> FLAT_USER_CS32 (value 0xe023) is FLAT_RING1_DS with an RPL of 3. >> >> The guests SYSCALL callback is invoked with a broken iret frame, and if left >> unmodified by the guest, will fail on the way back out when Xen's iret tries >> to load a code segment into %ss. >> >> In practice, this is only a problem for 32bit PV guests on AMD hardware, as >> Intel hardware doesn't permit the SYSCALL instruction outside of 64bit mode. >> >> This appears to have been broken ever since 64bit support was added to Xen, >> and has gone unnoticed because Linux doesn't use SYSCALL in 32bit builds. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Roger Pau Monné >> CC: Wei Liu >> CC: Juergen Gross >> >> This wants backporting basically everywhere, and as such, also wants to be >> considered for 4.11 at this point. >> --- >> xen/arch/x86/x86_64/compat/entry.S | 7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/xen/arch/x86/x86_64/compat/entry.S >> b/xen/arch/x86/x86_64/compat/entry.S >> index 6c7fcf9..2bc046c 100644 >> --- a/xen/arch/x86/x86_64/compat/entry.S >> +++ b/xen/arch/x86/x86_64/compat/entry.S >> @@ -197,7 +197,7 @@ ENTRY(cstar_enter) >> /* sti could live here when we don't switch page tables below. */ >> CR4_PV32_RESTORE >> movq 8(%rsp),%rax /* Restore %rax. */ >> -movq $FLAT_KERNEL_SS,8(%rsp) >> +movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat >> handled lower. */ >> pushq %r11 >> pushq $FLAT_USER_CS32 >> pushq %rcx >> @@ -223,6 +223,11 @@ ENTRY(cstar_enter) >> movq VCPU_domain(%rbx),%rcx >> cmpb $0,DOMAIN_is_32bit_pv(%rcx) >> jeswitch_to_kernel >> + >> +/* Fix up reported %cs/%ss for compat domains. */ >> +movl $0xe033, UREGS_ss(%rsp) /* Compat FLAT_RING3_SS */ >> +movl $0xe02b, UREGS_cs(%rsp) /* Compat FLAT_RING3_CS */ > I wonder if it would be better to introduce COMPAT_FLAT_RING3_* in > xen-x86_64.h? > > In any case, the reasoning and code looks correct to me: > > Reviewed-by: Wei Liu I considered that, and am open to suggestions. The problem is that we don't want to put COMPAT definitions in that header file, because they are inapplicable to 64bit PV guests, who are intended consumers. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/pv: Fix up erroneous segments for 32bit syscall entry
On 09/04/18 12:44, Wei Liu wrote: > On Mon, Apr 09, 2018 at 10:44:47AM +0100, Andrew Cooper wrote: >> The existing FLAT_KERNEL_SS expands to the correct value, 0xe02b, but is the >> wrong constant to use. Switch to FLAT_USER_SS32. >> >> For compat domains however, the reported values are entirely bogus. >> FLAT_USER_SS32 (value 0xe02b) is FLAT_RING3_CS in the 32bit ABI, while >> FLAT_USER_CS32 (value 0xe023) is FLAT_RING1_DS with an RPL of 3. >> >> The guests SYSCALL callback is invoked with a broken iret frame, and if left >> unmodified by the guest, will fail on the way back out when Xen's iret tries >> to load a code segment into %ss. >> >> In practice, this is only a problem for 32bit PV guests on AMD hardware, as >> Intel hardware doesn't permit the SYSCALL instruction outside of 64bit mode. >> >> This appears to have been broken ever since 64bit support was added to Xen, >> and has gone unnoticed because Linux doesn't use SYSCALL in 32bit builds. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Roger Pau Monné >> CC: Wei Liu >> CC: Juergen Gross >> >> This wants backporting basically everywhere, and as such, also wants to be >> considered for 4.11 at this point. >> --- >> xen/arch/x86/x86_64/compat/entry.S | 7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/xen/arch/x86/x86_64/compat/entry.S >> b/xen/arch/x86/x86_64/compat/entry.S >> index 6c7fcf9..2bc046c 100644 >> --- a/xen/arch/x86/x86_64/compat/entry.S >> +++ b/xen/arch/x86/x86_64/compat/entry.S >> @@ -197,7 +197,7 @@ ENTRY(cstar_enter) >> /* sti could live here when we don't switch page tables below. */ >> CR4_PV32_RESTORE >> movq 8(%rsp),%rax /* Restore %rax. */ >> -movq $FLAT_KERNEL_SS,8(%rsp) >> +movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat >> handled lower. */ >> pushq %r11 >> pushq $FLAT_USER_CS32 >> pushq %rcx >> @@ -223,6 +223,11 @@ ENTRY(cstar_enter) >> movq VCPU_domain(%rbx),%rcx >> cmpb $0,DOMAIN_is_32bit_pv(%rcx) >> jeswitch_to_kernel >> + >> +/* Fix up reported %cs/%ss for compat domains. */ >> +movl $0xe033, UREGS_ss(%rsp) /* Compat FLAT_RING3_SS */ >> +movl $0xe02b, UREGS_cs(%rsp) /* Compat FLAT_RING3_CS */ > > I wonder if it would be better to introduce COMPAT_FLAT_RING3_* in > xen-x86_64.h? That was my first thought, too. > > In any case, the reasoning and code looks correct to me: > > Reviewed-by: Wei Liu Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/pv: Fix up erroneous segments for 32bit syscall entry
On Mon, Apr 09, 2018 at 10:44:47AM +0100, Andrew Cooper wrote: > The existing FLAT_KERNEL_SS expands to the correct value, 0xe02b, but is the > wrong constant to use. Switch to FLAT_USER_SS32. > > For compat domains however, the reported values are entirely bogus. > FLAT_USER_SS32 (value 0xe02b) is FLAT_RING3_CS in the 32bit ABI, while > FLAT_USER_CS32 (value 0xe023) is FLAT_RING1_DS with an RPL of 3. > > The guests SYSCALL callback is invoked with a broken iret frame, and if left > unmodified by the guest, will fail on the way back out when Xen's iret tries > to load a code segment into %ss. > > In practice, this is only a problem for 32bit PV guests on AMD hardware, as > Intel hardware doesn't permit the SYSCALL instruction outside of 64bit mode. > > This appears to have been broken ever since 64bit support was added to Xen, > and has gone unnoticed because Linux doesn't use SYSCALL in 32bit builds. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Wei Liu > CC: Juergen Gross > > This wants backporting basically everywhere, and as such, also wants to be > considered for 4.11 at this point. > --- > xen/arch/x86/x86_64/compat/entry.S | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/x86_64/compat/entry.S > b/xen/arch/x86/x86_64/compat/entry.S > index 6c7fcf9..2bc046c 100644 > --- a/xen/arch/x86/x86_64/compat/entry.S > +++ b/xen/arch/x86/x86_64/compat/entry.S > @@ -197,7 +197,7 @@ ENTRY(cstar_enter) > /* sti could live here when we don't switch page tables below. */ > CR4_PV32_RESTORE > movq 8(%rsp),%rax /* Restore %rax. */ > -movq $FLAT_KERNEL_SS,8(%rsp) > +movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat > handled lower. */ > pushq %r11 > pushq $FLAT_USER_CS32 > pushq %rcx > @@ -223,6 +223,11 @@ ENTRY(cstar_enter) > movq VCPU_domain(%rbx),%rcx > cmpb $0,DOMAIN_is_32bit_pv(%rcx) > jeswitch_to_kernel > + > +/* Fix up reported %cs/%ss for compat domains. */ > +movl $0xe033, UREGS_ss(%rsp) /* Compat FLAT_RING3_SS */ > +movl $0xe02b, UREGS_cs(%rsp) /* Compat FLAT_RING3_CS */ I wonder if it would be better to introduce COMPAT_FLAT_RING3_* in xen-x86_64.h? In any case, the reasoning and code looks correct to me: Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools/libxl: Fix build following c/s 74fd984ae
Hi,
On 06/04/18 10:33, Wei Liu wrote:
On Fri, Apr 06, 2018 at 10:03:14AM +0100, Julien Grall wrote:
This is wrong. gicv_to_string works on XEN_DOMCTL_* define and not the
LIBXL_GIC_*.
So this will not give the right output.
I would suggest to revert that patch and I will send one that actually fix the
compilation.
Not sure I would be able to do it today thought.
OK, I will revert this patch.
I have looked at a potential way to fix it. The original patch
(74fd984ae6) assumption is incorrect. Some of information from
xc_domain_configuration_t is not written back ton libxl__domain_build_state.
For instance, this is the case of the clock frequency. That field is
used to workaround bootloader/firmware that didn't configure correct
CNTFRQ. If we detect such platform, we will read the host clock
frequency from the host Device-Tree and write it to the guest
Device-Tree. This should never be exposed to the guest.
Arguably, this field should not belong to xc_domain_configuration_t. So
I can see two solutions:
1) Store the frequency in libxl__domain_build_state
2) Introduce a different hypercall to get the system frequency. I guess
we could piggy-back on Andrew's idea to provide
XEN_DOMCTL_{get,set}_arch_settings.
The latter will require some rework in the code and define a new API.
Not sure if that would be acceptable for Xen 4.11.
Any opinions?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary
On 04/08/2018 12:03 AM, Boris Ostrovsky wrote:
> Commit 4a5733771e6f ("libxl: put RSDP for PVH guest near 4GB") breaks
> pre-4.17 Linux guests since they do not use start_info's rsdp_paddr
> pointer and instread scan BIOS memory for RSDP signature.
>
> Introduce XENFEAT_rsdp_unrestricted feature flag that indicates whether
> the guest can handle RSDP at locations pointed to by rsdp_paddr.
>
> Since only Linux PVH guests suffer from this problem (BSD has always
> relied on rsdp_paddr) we check this flag just for those guests. If the
> flag is not set we place RSDP in BIOS, as before.
>
> Signed-off-by: Boris Ostrovsky
Thanks guys:
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Comments on v1 (was: [PATCH v2 1/7] introduce time managment in xtf)
Hello, I'm replying to patch 1/7 because there's no cover letter. I've made a bunch of comments on v1 because I didn't realize you had already sent v2. I think a bunch of the comments I've made in v1 also apply to v2, so could you please look at those and fix them up if required? Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11] x86/pv: Fix up erroneous segments for 32bit syscall entry
The existing FLAT_KERNEL_SS expands to the correct value, 0xe02b, but is the wrong constant to use. Switch to FLAT_USER_SS32. For compat domains however, the reported values are entirely bogus. FLAT_USER_SS32 (value 0xe02b) is FLAT_RING3_CS in the 32bit ABI, while FLAT_USER_CS32 (value 0xe023) is FLAT_RING1_DS with an RPL of 3. The guests SYSCALL callback is invoked with a broken iret frame, and if left unmodified by the guest, will fail on the way back out when Xen's iret tries to load a code segment into %ss. In practice, this is only a problem for 32bit PV guests on AMD hardware, as Intel hardware doesn't permit the SYSCALL instruction outside of 64bit mode. This appears to have been broken ever since 64bit support was added to Xen, and has gone unnoticed because Linux doesn't use SYSCALL in 32bit builds. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Juergen Gross This wants backporting basically everywhere, and as such, also wants to be considered for 4.11 at this point. --- xen/arch/x86/x86_64/compat/entry.S | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S index 6c7fcf9..2bc046c 100644 --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -197,7 +197,7 @@ ENTRY(cstar_enter) /* sti could live here when we don't switch page tables below. */ CR4_PV32_RESTORE movq 8(%rsp),%rax /* Restore %rax. */ -movq $FLAT_KERNEL_SS,8(%rsp) +movq $FLAT_USER_SS32, 8(%rsp) /* Assume a 64bit domain. Compat handled lower. */ pushq %r11 pushq $FLAT_USER_CS32 pushq %rcx @@ -223,6 +223,11 @@ ENTRY(cstar_enter) movq VCPU_domain(%rbx),%rcx cmpb $0,DOMAIN_is_32bit_pv(%rcx) jeswitch_to_kernel + +/* Fix up reported %cs/%ss for compat domains. */ +movl $0xe033, UREGS_ss(%rsp) /* Compat FLAT_RING3_SS */ +movl $0xe02b, UREGS_cs(%rsp) /* Compat FLAT_RING3_CS */ + cmpb $0,VCPU_syscall32_disables_events(%rbx) movzwl VCPU_syscall32_sel(%rbx),%esi movq VCPU_syscall32_addr(%rbx),%rax -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 122104: tolerable FAIL
flight 122104 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/122104/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 5 host-ping-check-native fail in 122043 pass in 122104 test-armhf-armhf-libvirt-xsm 6 xen-install fail in 122043 pass in 122104 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail pass in 122043 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 121974 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122043 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122043 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122043 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122043 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122043 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122043 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122043 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122043 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122043 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: xen 451004603247205467ec34b366b4cfa3814a5d95 baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 122104 2018-04-08 12:47:45 Z0 days Testing sa
Re: [Xen-devel] [PATCH for-4.11] x86/ioreq: Fix build from a collision of c/s f46b61973 and c/s 6e387461ed
Hi, On 06/04/18 18:57, Andrew Cooper wrote: Drop the _mfn() wrappers now that page_to_mfn() returns the correct type. Sorry for the breakage: Acked-by: Julien Grall Cheers, Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Julien Grall CC: Paul Durrant CC: Juergen Gross --- xen/arch/x86/hvm/ioreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index 3a201f5..9051329 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -973,12 +973,12 @@ int hvm_get_ioreq_server_frame(struct domain *d, ioservid_t id, if ( !HANDLE_BUFIOREQ(s) ) goto out; -*mfn = _mfn(page_to_mfn(s->bufioreq.page)); +*mfn = page_to_mfn(s->bufioreq.page); rc = 0; break; case XENMEM_resource_ioreq_server_frame_ioreq(0): -*mfn = _mfn(page_to_mfn(s->ioreq.page)); +*mfn = page_to_mfn(s->ioreq.page); rc = 0; break; -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/7] add spin_sleep function to time manager
On Wed, Apr 04, 2018 at 03:50:52PM +, Pawel Wieczorkiewicz wrote:
> From: Paul Semel
Missing commit log.
> Signed-off-by: Paul Semel
>
> cr https://code.amazon.com/reviews/CR-786226
> ---
> common/time.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/common/time.c b/common/time.c
> index db28d78..6aa1648 100644
> --- a/common/time.c
> +++ b/common/time.c
> @@ -124,6 +124,20 @@ static inline void nspin_sleep(uint64_t t)
> curr = since_boot_time();
> }
>
> +#if defined(__i386__)
> +static inline void spin_sleep(uint32_t t)
> +#else
> +static inline void spin_sleep(uint64_t t)
> +#endif
> +{
> +#if defined(__i386__)
> +uint32_t nsec = t * 10;
> +#else
> +uint64_t nsec = t * 10ul;
This value should be in a define with a proper name.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/7] add nspin_sleep function to time manager
On Wed, Apr 04, 2018 at 03:50:51PM +, Pawel Wieczorkiewicz wrote:
> From: Paul Semel
Missing commit log?
> Signed-off-by: Paul Semel
>
> cr https://code.amazon.com/reviews/CR-836539
> ---
> common/time.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/common/time.c b/common/time.c
> index c80bc11..db28d78 100644
> --- a/common/time.c
> +++ b/common/time.c
> @@ -106,6 +106,24 @@ int gettimeofday(struct timeval *tp)
> return 0;
> }
>
> +#if defined(__i386__)
> +static inline void nspin_sleep(uint32_t t)
> +#else
> +static inline void nspin_sleep(uint64_t t)
> +#endif
> +{
> +#if defined(__i386__)
> +uint32_t curr = since_boot_time();
> +uint32_t end = curr + t;
> +#else
> +uint64_t curr = since_boot_time();
> +uint64_t end = curr + t;
> +#endif
Again same comment as before regarding the 32 vs 64bit types.
You would probably want something like:
if ( end < curr )
panic("end value overflows counter\n");
> +
> +while ( curr < end )
> +curr = since_boot_time();
And you likely want this to be:
while ( end < since_boot_time() )
asm volatile ("pause");
I'm actually trying to add a "pause" instruction helper in:
https://marc.info/?l=xen-devel&m=152241364510840
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE
My recent Xen patch series introduces a new HYPERVISOR_memory_op to
support direct priv-mapping of certain guest resources (such as ioreq
pages, used by emulators) by a tools domain, rather than having to access
such resources via the guest P2M.
This patch adds the necessary infrastructure to the privcmd driver and
Xen MMU code to support direct resource mapping.
NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now
allow a PV tools domain to map guest pages either by GFN or MFN, thus
the term 'mfn' has been swapped for 'pfn' in the lower layers of the
remap code.
Signed-off-by: Paul Durrant
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Stefano Stabellini
v2:
- Fix bug when mapping multiple pages of a resource
v3:
- Addres comments from Boris
- Fix ARM build
---
arch/arm/xen/enlighten.c | 11
arch/x86/xen/mmu.c | 60 +--
drivers/xen/privcmd.c | 130 +
include/uapi/xen/privcmd.h | 11
include/xen/interface/memory.h | 66 +
include/xen/interface/xen.h| 7 ++-
include/xen/xen-ops.h | 24 +++-
7 files changed, 288 insertions(+), 21 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ba7f4c8f5c3e..8073625371f5 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -89,6 +89,17 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
}
EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
+/* Not used by XENFEAT_auto_translated guests. */
+int xen_remap_domain_mfn_array(struct vm_area_struct *vma,
+ unsigned long addr,
+ xen_pfn_t *mfn, int nr,
+ int *err_ptr, pgprot_t prot,
+ unsigned int domid, struct page **pages)
+{
+ return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_array);
+
static void xen_read_wallclock(struct timespec64 *ts)
{
u32 version;
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d33e7dbe3129..af2960cb7a3e 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -65,37 +65,44 @@ static void xen_flush_tlb_all(void)
#define REMAP_BATCH_SIZE 16
struct remap_data {
- xen_pfn_t *mfn;
+ xen_pfn_t *pfn;
bool contiguous;
+ bool no_translate;
pgprot_t prot;
struct mmu_update *mmu_update;
};
-static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
+static int remap_area_pfn_pte_fn(pte_t *ptep, pgtable_t token,
unsigned long addr, void *data)
{
struct remap_data *rmd = data;
- pte_t pte = pte_mkspecial(mfn_pte(*rmd->mfn, rmd->prot));
+ pte_t pte = pte_mkspecial(mfn_pte(*rmd->pfn, rmd->prot));
- /* If we have a contiguous range, just update the mfn itself,
- else update pointer to be "next mfn". */
+ /*
+* If we have a contiguous range, just update the pfn itself,
+* else update pointer to be "next pfn".
+*/
if (rmd->contiguous)
- (*rmd->mfn)++;
+ (*rmd->pfn)++;
else
- rmd->mfn++;
+ rmd->pfn++;
- rmd->mmu_update->ptr = virt_to_machine(ptep).maddr |
MMU_NORMAL_PT_UPDATE;
+ rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
+ rmd->mmu_update->ptr |= rmd->no_translate ?
+ MMU_PT_UPDATE_NO_TRANSLATE :
+ MMU_NORMAL_PT_UPDATE;
rmd->mmu_update->val = pte_val_ma(pte);
rmd->mmu_update++;
return 0;
}
-static int do_remap_gfn(struct vm_area_struct *vma,
+static int do_remap_pfn(struct vm_area_struct *vma,
unsigned long addr,
- xen_pfn_t *gfn, int nr,
+ xen_pfn_t *pfn, int nr,
int *err_ptr, pgprot_t prot,
- unsigned domid,
+ unsigned int domid,
+ bool no_translate,
struct page **pages)
{
int err = 0;
@@ -106,11 +113,14 @@ static int do_remap_gfn(struct vm_area_struct *vma,
BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
- rmd.mfn = gfn;
+ rmd.pfn = pfn;
rmd.prot = prot;
- /* We use the err_ptr to indicate if there we are doing a contiguous
-* mapping or a discontigious mapping. */
+ /*
+* We use the err_ptr to indicate if there we are doing a contiguous
+* mapping or a discontigious mapping.
+*/
rmd.contiguous = !err_ptr;
+ rmd.no_translate = no_translate;
while (nr) {
int index = 0;
@@ -121,7 +131,7 @@ static int do_remap_gfn(struct vm_area_struct *vma,
rmd.mmu_update = mmu_update;
err = apply_to_page_range(vma->vm_mm, addr, range
[Xen-devel] [PATCH] drm/xen-front: use simple display pipe prepare_fb helper
I missed this one because on an older tree.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 0bd6681fa4f3..a3479eb72d79 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -226,12 +226,6 @@ static bool display_send_page_flip(struct
drm_simple_display_pipe *pipe,
return false;
}
-static int display_prepare_fb(struct drm_simple_display_pipe *pipe,
- struct drm_plane_state *plane_state)
-{
- return drm_gem_fb_prepare_fb(&pipe->plane, plane_state);
-}
-
static void display_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *old_plane_state)
{
@@ -294,7 +288,7 @@ static const struct drm_simple_display_pipe_funcs
display_funcs = {
.mode_valid = display_mode_valid,
.enable = display_enable,
.disable = display_disable,
- .prepare_fb = display_prepare_fb,
+ .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
.update = display_update,
};
--
2.16.2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/7] add gettimeofday function to time managment
On Wed, Apr 04, 2018 at 03:50:50PM +, Pawel Wieczorkiewicz wrote:
> From: Paul Semel
>
> Signed-off-by: Paul Semel
>
> cr https://code.amazon.com/reviews/CR-786225
> ---
> common/time.c | 14 ++
> include/xtf/time.h | 12
> 2 files changed, 26 insertions(+)
>
> diff --git a/common/time.c b/common/time.c
> index 37a9faf..c80bc11 100644
> --- a/common/time.c
> +++ b/common/time.c
> @@ -92,6 +92,20 @@ uint64_t current_time(void)
> return seconds + (since_boot_time() / 10);
> }
>
> +/* The POSIX gettimeofday syscall normally takes a second argument, which is
> + * the timezone (struct timezone). However, it sould be NULL because linux
> + * doesn't use it anymore. So we need for us to add it in this function
IMO it's better to use the POSIX prototype.
I would instead panic if tz != NULL, or return EOPNOTSUPP.
> + */
> +int gettimeofday(struct timeval *tp)
> +{
> +if (!tp)
> +return -1;
> +
> +tp->sec = current_time();
> +tp->nsec = shared_info.wc_nsec + (since_boot_time() % 10);
Please add a define for 10.
Also, I'm not sure this is accurate.
current_time already calls since_boot_time, so you end up using data
from two different since_boot_time calls in order to fill the timeval
struct, which is wrong (ie: those calls will return different values
which you are mixing).
> +return 0;
> +}
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/include/xtf/time.h b/include/xtf/time.h
> index a8c10eb..16356eb 100644
> --- a/include/xtf/time.h
> +++ b/include/xtf/time.h
> @@ -8,6 +8,16 @@
>
> #include
>
> +struct timeval {
> +#if !defined(__i386__)
> +uint64_t sec;
> +uint64_t nsec;
> +#else
> +uint32_t sec;
> +uint32_t nsec;
> +#endif
> +};
Let's have a sane interface from the start and always use 64bit
fields.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/7] add current_time function to time manager
On Wed, Apr 04, 2018 at 03:50:49PM +, Pawel Wieczorkiewicz wrote:
> From: Paul Semel
>
> this function returns the "epoch" time
>
> Signed-off-by: Paul Semel
>
> cr https://code.amazon.com/reviews/CR-786224
> ---
> common/time.c | 16
> include/xtf/time.h | 4
> 2 files changed, 20 insertions(+)
>
> diff --git a/common/time.c b/common/time.c
> index 11ac168..37a9faf 100644
> --- a/common/time.c
> +++ b/common/time.c
> @@ -76,6 +76,22 @@ uint64_t since_boot_time(void)
> return system_time;
> }
>
> +/* This function return the epoch time (number of seconds elapsed
> + * since Juanary 1, 1970) */
> +#if defined(__i386__)
> +uint32_t current_time(void)
> +#else
> +uint64_t current_time(void)
> +#endif
> +{
> +#if defined(__i386__)
> +uint32_t seconds = shared_info.wc_sec;
> +#else
> +uint64_t seconds = ((uint64_t)shared_info.wc_sec_hi << 32) |
> shared_info.wc_sec;
> +#endif
> +return seconds + (since_boot_time() / 10);
You need barriers and checking wc_version, see:
https://github.com/freebsd/freebsd/blob/master/sys/x86/x86/pvclock.c#L156
And as commented in patch 1, I think you should return a 64bit value
regardless of the bitness of the binary.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/7] introduce time managment in xtf
On Wed, Apr 04, 2018 at 03:50:48PM +, Pawel Wieczorkiewicz wrote:
> From: Paul Semel
>
> this file is introduce to be able to implement an inter domain
> communication protocol over xenstore. For synchronization purpose, we do
> really want to be able to "control" time
>
> common/time.c: since_boot_time gets the time in nanoseconds from the
> moment the VM has booted
>
> Signed-off-by: Paul Semel
>
> cr https://code.amazon.com/reviews/CR-786223
This seems like some Amazon internal tracking, which shouldn't be sent
upstream (the webpage is not even accessible from the outside).
> ---
> build/files.mk | 1 +
> common/time.c | 87
> ++
> include/xtf/time.h | 35 ++
> 3 files changed, 123 insertions(+)
> create mode 100644 common/time.c
> create mode 100644 include/xtf/time.h
>
> diff --git a/build/files.mk b/build/files.mk
> index 46b42d6..55ed1ca 100644
> --- a/build/files.mk
> +++ b/build/files.mk
> @@ -16,6 +16,7 @@ obj-perarch += $(ROOT)/common/libc/vsnprintf.o
> obj-perarch += $(ROOT)/common/report.o
> obj-perarch += $(ROOT)/common/setup.o
> obj-perarch += $(ROOT)/common/xenbus.o
> +obj-perarch += $(ROOT)/common/time.o
>
> obj-perenv += $(ROOT)/arch/x86/decode.o
> obj-perenv += $(ROOT)/arch/x86/desc.o
> diff --git a/common/time.c b/common/time.c
> new file mode 100644
> index 000..11ac168
> --- /dev/null
> +++ b/common/time.c
> @@ -0,0 +1,87 @@
> +#include
> +#include
> +#include
> +
> +/* This function was taken from mini-os source code */
> +/* It returns ((delta << shift) * mul_frac) >> 32 */
> +static inline uint64_t scale_delta(uint64_t delta, uint32_t mul_frac, int
> shift)
> +{
> +uint64_t product;
> +#ifdef __i386__
> +uint32_t tmp1, tmp2;
> +#endif
> +
> +if ( shift < 0 )
> +delta >>= -shift;
> +else
> +delta <<= shift;
> +
> +#ifdef __i386__
> +__asm__ (
> +"mul %5 ; "
> +"mov %4,%%eax ; "
> +"mov %%edx,%4 ; "
> +"mul %5 ; "
> +"add %4,%%eax ; "
> +"xor %5,%5; "
> +"adc %5,%%edx ; "
> +: "=A" (product), "=r" (tmp1), "=r" (tmp2)
> +: "a" ((uint32_t)delta), "1" ((uint32_t)(delta >> 32)), "2"
> (mul_frac) );
> +#else
> +__asm__ (
> +"mul %%rdx ; shrd $32,%%rdx,%%rax"
> +: "=a" (product) : "0" (delta), "d" ((uint64_t)mul_frac) );
> +#endif
> +
> +return product;
> +}
> +
> +
> +#if defined(__i386__)
> +uint32_t since_boot_time(void)
> +#else
> +uint64_t since_boot_time(void)
> +#endif
Why is the return type different for 32 vs 64bits?
I see no reason to not return a 64bit value in both cases IMO, and
that would remove the need for all the ifdefery below.
> +{
> +uint64_t tsc;
> +uint32_t version, wc_version;
> +#if defined(__i386__)
> +uint32_t system_time;
> +#else
> +uint64_t system_time;
> +#endif
> +uint64_t old_tsc;
> +
> +do
> +{
> +do
> +{
> +wc_version = shared_info.wc_version ;
> +version = shared_info.vcpu_info[0].time.version;
> +} while ( (version & 1) == 1 || (wc_version & 1) == 1);
> +
> +system_time = shared_info.vcpu_info[0].time.system_time;
> +old_tsc = shared_info.vcpu_info[0].time.tsc_timestamp;
> +} while (
> +version != shared_info.vcpu_info[0].time.version ||
> +wc_version != shared_info.wc_version
> +);
> +
> +rdtscp(tsc);
> +
> +system_time += scale_delta(tsc - old_tsc,
> +
> shared_info.vcpu_info[0].time.tsc_to_system_mul,
> + shared_info.vcpu_info[0].time.tsc_shift);
This seems way more complicated that what's actually needed. First of
all you don't need to check wc_version at all if you are only fetching
the vcpu_time_info fields (wc_version is for the wallclock).
Then AFAICT you are also missing the barriers (or using something like
Linux's ACCESS_ONCE):
https://github.com/freebsd/freebsd/blob/master/sys/x86/x86/pvclock.c#L141
> +
> +return system_time;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/include/xtf/time.h b/include/xtf/time.h
> new file mode 100644
> index 000..15cbd48
> --- /dev/null
> +++ b/include/xtf/time.h
> @@ -0,0 +1,35 @@
> +/**
> + * @file include/xtf/time.h
> + *
> + * Time management
> + */
> +#ifndef XTF_TIME_H
> +# define XTF_TIME_H
> +
> +#include
> +
> +#define rdtscp(tsc) {\
Why is this called rdtscp when you are actually using rdtsc? (and not
rdtscp?)
> +uint32_t lo, hi;\
> +__asm__ volatile("rdtsc": "=a"(lo), "=d"(hi));\
> +tsc = ((uint64_t)hi << 32) | lo;\
rdtsc is not a serializing instruction, see:
https://marc.info/?l=xen-devel&m=151939254729277
Also this should lik
Re: [Xen-devel] [PATCH] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary
On Sat, Apr 07, 2018 at 07:03:32PM -0400, Boris Ostrovsky wrote:
> Commit 4a5733771e6f ("libxl: put RSDP for PVH guest near 4GB") breaks
> pre-4.17 Linux guests since they do not use start_info's rsdp_paddr
> pointer and instread scan BIOS memory for RSDP signature.
>
> Introduce XENFEAT_rsdp_unrestricted feature flag that indicates whether
> the guest can handle RSDP at locations pointed to by rsdp_paddr.
>
> Since only Linux PVH guests suffer from this problem (BSD has always
> relied on rsdp_paddr) we check this flag just for those guests. If the
> flag is not set we place RSDP in BIOS, as before.
>
> Signed-off-by: Boris Ostrovsky
> ---
> tools/libxl/libxl_x86_acpi.c | 13 +++--
> xen/include/public/features.h | 8
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
> index fe87418bc1..046d4866c7 100644
> --- a/tools/libxl/libxl_x86_acpi.c
> +++ b/tools/libxl/libxl_x86_acpi.c
> @@ -218,8 +218,17 @@ int libxl__dom_load_acpi(libxl__gc *gc,
>
> dom->acpi_modules[0].data = (void *)config.rsdp;
> dom->acpi_modules[0].length = 64;
> -dom->acpi_modules[0].guest_addr_out = ACPI_INFO_PHYSICAL_ADDRESS +
> -(1 + acpi_pages_num) * libxl_ctxt.page_size;
> +/*
> + * Some Linux versions cannot properly process hvm_start_info.rsdp_paddr
> + * and so we need to put RSDP in location that can be discovered by
> ACPI's
> + * standard search method, in R-O BIOS memory (we chose last 64 bytes)
> + */
> +if (strcmp(dom->parms.guest_os, "linux") ||
> +elf_xen_feature_get(XENFEAT_rsdp_unrestricted,
> dom->parms.f_supported))
> +dom->acpi_modules[0].guest_addr_out = ACPI_INFO_PHYSICAL_ADDRESS +
> +(1 + acpi_pages_num) * libxl_ctxt.page_size;
> +else
> +dom->acpi_modules[0].guest_addr_out = 0x10 - 64;
>
> dom->acpi_modules[1].data = (void *)config.infop;
> dom->acpi_modules[1].length = 4096;
> diff --git a/xen/include/public/features.h b/xen/include/public/features.h
> index 1a989b8bf9..c5319fbfbf 100644
> --- a/xen/include/public/features.h
> +++ b/xen/include/public/features.h
> @@ -105,6 +105,14 @@
> /* arm: Hypervisor supports ARM SMC calling convention. */
> #define XENFEAT_ARM_SMCCC_supported 14
>
> +/*
> + * x86/PVH: If set, ACPI RSDP can be placed at any address. Otherwise RSDP
> + * must be located in lower 1MB, as required by ACPI Specification for IA-PC
> + * systems.
> + * This feature flag is only consulted for Linux guests.
> + */
> +#define XENFEAT_rsdp_unrestricted 15
> +
It seems that this flag will remain linux only forever? If so, why not
add _linux_ to the name to make it clear?
(I don't normally bikeshed names, but this is public interface which
could use a bit of bikeshedding)
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary
On Sat, Apr 07, 2018 at 07:03:32PM -0400, Boris Ostrovsky wrote:
> Commit 4a5733771e6f ("libxl: put RSDP for PVH guest near 4GB") breaks
> pre-4.17 Linux guests since they do not use start_info's rsdp_paddr
> pointer and instread scan BIOS memory for RSDP signature.
>
> Introduce XENFEAT_rsdp_unrestricted feature flag that indicates whether
> the guest can handle RSDP at locations pointed to by rsdp_paddr.
>
> Since only Linux PVH guests suffer from this problem (BSD has always
> relied on rsdp_paddr) we check this flag just for those guests. If the
> flag is not set we place RSDP in BIOS, as before.
LGTM if we agree to do this based on the contents of
XEN_ELFNOTE_GUEST_OS. I think this is the first time we have a feature
flag that depends on the OS type.
> Signed-off-by: Boris Ostrovsky
> ---
> tools/libxl/libxl_x86_acpi.c | 13 +++--
> xen/include/public/features.h | 8
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
> index fe87418bc1..046d4866c7 100644
> --- a/tools/libxl/libxl_x86_acpi.c
> +++ b/tools/libxl/libxl_x86_acpi.c
> @@ -218,8 +218,17 @@ int libxl__dom_load_acpi(libxl__gc *gc,
>
> dom->acpi_modules[0].data = (void *)config.rsdp;
> dom->acpi_modules[0].length = 64;
> -dom->acpi_modules[0].guest_addr_out = ACPI_INFO_PHYSICAL_ADDRESS +
> -(1 + acpi_pages_num) * libxl_ctxt.page_size;
> +/*
> + * Some Linux versions cannot properly process hvm_start_info.rsdp_paddr
> + * and so we need to put RSDP in location that can be discovered by
> ACPI's
> + * standard search method, in R-O BIOS memory (we chose last 64 bytes)
> + */
> +if (strcmp(dom->parms.guest_os, "linux") ||
> +elf_xen_feature_get(XENFEAT_rsdp_unrestricted,
> dom->parms.f_supported))
> +dom->acpi_modules[0].guest_addr_out = ACPI_INFO_PHYSICAL_ADDRESS +
> +(1 + acpi_pages_num) * libxl_ctxt.page_size;
> +else
> +dom->acpi_modules[0].guest_addr_out = 0x10 - 64;
>
> dom->acpi_modules[1].data = (void *)config.infop;
> dom->acpi_modules[1].length = 4096;
> diff --git a/xen/include/public/features.h b/xen/include/public/features.h
> index 1a989b8bf9..c5319fbfbf 100644
> --- a/xen/include/public/features.h
> +++ b/xen/include/public/features.h
> @@ -105,6 +105,14 @@
> /* arm: Hypervisor supports ARM SMC calling convention. */
> #define XENFEAT_ARM_SMCCC_supported 14
>
> +/*
> + * x86/PVH: If set, ACPI RSDP can be placed at any address. Otherwise RSDP
> + * must be located in lower 1MB, as required by ACPI Specification for IA-PC
> + * systems.
> + * This feature flag is only consulted for Linux guests.
I would slightly change the above to be more explicit:
This feature flag is only consulted if XEN_ELFNOTE_GUEST_OS contains
the "linux" string.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 05 April 2018 23:34
> To: Paul Durrant ; x...@kernel.org; xen-
> de...@lists.xenproject.org; linux-ker...@vger.kernel.org
> Cc: Juergen Gross ; Thomas Gleixner
> ; Ingo Molnar
> Subject: Re: [PATCH v2] xen/privcmd: add
> IOCTL_PRIVCMD_MMAP_RESOURCE
>
> On 04/05/2018 11:42 AM, Paul Durrant wrote:
> > My recent Xen patch series introduces a new HYPERVISOR_memory_op to
> > support direct priv-mapping of certain guest resources (such as ioreq
> > pages, used by emulators) by a tools domain, rather than having to access
> > such resources via the guest P2M.
> >
> > This patch adds the necessary infrastructure to the privcmd driver and
> > Xen MMU code to support direct resource mapping.
> >
> > NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now
> > allow a PV tools domain to map guest pages either by GFN or MFN, thus
> > the term 'mfn' has been swapped for 'pfn' in the lower layers of the
> > remap code.
> >
> > Signed-off-by: Paul Durrant
> > ---
> > Cc: Boris Ostrovsky
> > Cc: Juergen Gross
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> >
> > v2:
> > - Fix bug when mapping multiple pages of a resource
>
>
> Only a few nits below.
>
> > ---
> > arch/x86/xen/mmu.c | 50 +++-
> > drivers/xen/privcmd.c | 130
> +
> > include/uapi/xen/privcmd.h | 11
> > include/xen/interface/memory.h | 66 +
> > include/xen/interface/xen.h| 7 ++-
> > include/xen/xen-ops.h | 24 +++-
> > 6 files changed, 270 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > index d33e7dbe3129..8453d7be415c 100644
> > --- a/arch/x86/xen/mmu.c
> > +++ b/arch/x86/xen/mmu.c
> > @@ -65,37 +65,42 @@ static void xen_flush_tlb_all(void)
> > #define REMAP_BATCH_SIZE 16
> >
> > struct remap_data {
> > - xen_pfn_t *mfn;
> > + xen_pfn_t *pfn;
> > bool contiguous;
> > + bool no_translate;
> > pgprot_t prot;
> > struct mmu_update *mmu_update;
> > };
> >
> > -static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
> > +static int remap_area_pfn_pte_fn(pte_t *ptep, pgtable_t token,
> > unsigned long addr, void *data)
> > {
> > struct remap_data *rmd = data;
> > - pte_t pte = pte_mkspecial(mfn_pte(*rmd->mfn, rmd->prot));
> > + pte_t pte = pte_mkspecial(mfn_pte(*rmd->pfn, rmd->prot));
> >
> > /* If we have a contiguous range, just update the mfn itself,
> >else update pointer to be "next mfn". */
>
> This probably also needs to be updated (and while at it, comment style
> fixed)
>
Ok.
> > if (rmd->contiguous)
> > - (*rmd->mfn)++;
> > + (*rmd->pfn)++;
> > else
> > - rmd->mfn++;
> > + rmd->pfn++;
> >
> > - rmd->mmu_update->ptr = virt_to_machine(ptep).maddr |
> MMU_NORMAL_PT_UPDATE;
> > + rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
> > + rmd->mmu_update->ptr |= rmd->no_translate ?
> > + MMU_PT_UPDATE_NO_TRANSLATE :
> > + MMU_NORMAL_PT_UPDATE;
> > rmd->mmu_update->val = pte_val_ma(pte);
> > rmd->mmu_update++;
> >
> > return 0;
> > }
> >
> > -static int do_remap_gfn(struct vm_area_struct *vma,
> > +static int do_remap_pfn(struct vm_area_struct *vma,
> > unsigned long addr,
> > - xen_pfn_t *gfn, int nr,
> > + xen_pfn_t *pfn, int nr,
> > int *err_ptr, pgprot_t prot,
> > - unsigned domid,
> > + unsigned int domid,
> > + bool no_translate,
> > struct page **pages)
> > {
> > int err = 0;
> > @@ -106,11 +111,12 @@ static int do_remap_gfn(struct vm_area_struct
> *vma,
> >
> > BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) ==
> (VM_PFNMAP | VM_IO)));
> >
> > - rmd.mfn = gfn;
> > + rmd.pfn = pfn;
> > rmd.prot = prot;
> > /* We use the err_ptr to indicate if there we are doing a contiguous
> > * mapping or a discontigious mapping. */
>
> Style.
>
I'm not modifying this comment but I'll fix it.
> > rmd.contiguous = !err_ptr;
> > + rmd.no_translate = no_translate;
> >
> > while (nr) {
> > int index = 0;
> > @@ -121,7 +127,7 @@ static int do_remap_gfn(struct vm_area_struct
> *vma,
> >
> > rmd.mmu_update = mmu_update;
> > err = apply_to_page_range(vma->vm_mm, addr, range,
> > - remap_area_mfn_pte_fn, &rmd);
> > + remap_area_pfn_pte_fn, &rmd);
> > if (err)
> > goto out;
> >
> > @@ -175,7 +181,8 @@ int xen_remap_domain_gfn_range(struct
> vm_area_struct *vma,
> > if (xen_feature(XENFEAT_auto_translated_physmap))
> > return -EOPNOTSUPP;
> >
> > - return do_re
[Xen-devel] [xen-unstable-smoke test] 122122: regressions - FAIL
flight 122122 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122122/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 121876 build-armhf 6 xen-buildfail REGR. vs. 121876 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen e62e140daa393c89342f7ca19906e303ebedf8db baseline version: xen 451004603247205467ec34b366b4cfa3814a5d95 Last test of basis 121876 2018-04-05 10:04:25 Z3 days Failing since121889 2018-04-05 13:02:10 Z3 days 34 attempts Testing same since 122036 2018-04-07 15:01:18 Z1 days 16 attempts People who touched revisions under test: Amit Singh Tomar Andre Przywara Andre Pzywara Andrew Cooper George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Marcello Seri Marcus of Wetware Labs Marek Marczykowski-Górecki Petre Eftime Razvan Cojocaru Stefano Stabellini Tim Deegan Wei Liu jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 712 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
