[Xen-devel] [xen-4.5-testing baseline-only test] 72359: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72359 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72359/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 15 guest-saverestore fail REGR. vs. 72233

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate fail REGR. vs. 72233

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds  7 xen-boot fail   like 72233
 test-xtf-amd64-amd64-4   60 leak-check/check fail   like 72233
 test-xtf-amd64-amd64-3   60 leak-check/check fail   like 72233
 test-xtf-amd64-amd64-5   60 leak-check/check fail   like 72233
 test-xtf-amd64-amd64-1   60 leak-check/check fail   like 72233
 test-xtf-amd64-amd64-2   60 leak-check/check fail   like 72233
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 72233
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 72233
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install  fail like 72233
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 72233
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 72233
 test-amd64-amd64-xl-qemut-winxpsp3 10 windows-install  fail like 72233
 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-ws16-amd64 10 windows-install fail never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-3   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-xtf-amd64-amd64-1   59 xtf/test-hvm64-xsa-195   fail   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-xtf-amd64-amd64-2   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-libvirt-raw 11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 13 guest-saverestore  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass

version targeted for testing:
 xen  08aa260dd172de625ecc2b64b78b1aa68de1f472
baseline version:
 xen  03b06d38c785ec89817a608470b443d8de2e1b9e

Last test of basis72233  2017-10-14 02:16:35 Z   13 days
Testing same since72359  2017-10-26 15:14:21 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass

Re: [Xen-devel] [PATCH 0/6] Intel Processor Trace virtulization enabling

[Kang, Luwei]

> >>> Hi All,
> >>>
> >>> Here is a patch-series which adding Processor Trace enabling in XEN 
> >>> guest. You can get It's software developer manuals from:
> >>> https://software.intel.com/sites/default/files/managed/c5/15/archite
> >>> ct ure-instruction-set-extensions-programming-reference.pdf
> >>> In Chapter 5 INTEL PROCESSOR TRACE: VMX IMPROVEMENTS.
> >>>
> >>> Introduction:
> >>> Intel Processor Trace (Intel PT) is an extension of Intel
> >>> Architecture that captures information about software execution
> >>> using
> >> dedicated hardware facilities that cause only minimal performance
> >> perturbation to the software being traced. Details on the Intel PT 
> >> infrastructure and trace capabilities can be found in the Intel 64
> and IA-32 Architectures Software Developer’s Manual, Volume 3C.
> >>> The suite of architecture changes serve to simplify the process of
> >>> virtualizing Intel PT for use by a guest software. There are two
> >> primary elements to this new architecture support for VMX support 
> >> improvements made for Intel PT.
> >>> 1. Addition of a new guest IA32_RTIT_CTL value field to the VMCS.
> >>>   — This serves to speed and simplify the process of disabling trace on 
> >>> VM exit, and restoring it on VM entry.
> >>> 2. Enabling use of EPT to redirect PT output.
> >>>   — This enables the VMM to elect to virtualize the PT output buffer
> >>> using EPT. In this mode, the CPU will treat PT output
> >> addresses as Guest Physical Addresses (GPAs) and translate them using
> >> EPT. This means that Intel PT output reads (of the ToPA
> >> table) and writes (of trace output) can cause EPT violations, and other 
> >> output events.
> >>
> >> Hello,
> >>
> >> Having read the new proposed extensions, I've got some architecture 
> >> questions before diving into the patches themselves.
> >>
> >> First of all, is this technology expected to end up in Icelake, or 
> >> something later?
> > Yes, this would be enabled on Icelake.
> 
> Thanks.
> 
> >
> >> In Vol 3, the existing VMX support describes a number of scenarios
> >> (system wide, VMM-only, VM-only, guest aware), which require the use of 
> >> MSR load lists to atomically alter the IA32_RTIT_*
> msrs.
> > Currently, I just enabling the guest only mode(VM-only) in my patches.
> 
> That is fine.  I'm not asking you to implement these modes; I am just trying 
> to work out how they would interact.

System-Wide: trace Xen hypervisor and guest and output to host buffer; 
VMM-only: trace Xen hypervisor only and output to host buffer.;
VM-only: trace guest only and output to guest buffer;

> 
> >
> >> Obviously, system wide mode is incompatible with also allowing the
> >> guest to use PT itself,
> > Yes, system mode(collect trace packets of the entire system) can't work 
> > with guest only mode at the same time.
> >
> >> but what about Xen wanting to use PT for itself, and for the guest to use 
> >> PT as well?
> > I think this can be named by host-guest mode. This may need add new command 
> > or interface to enable PT in Xen hypervisor.
> Trace vmm-only and guest simultaneous and output to their respective buffer.
> >
> >> Previously, this appears to be possible using the MSR load lists
> >> (albeit with Xen needing to shadow the ToPA records to cause the packet 
> >> stream to end up in the right place).
> > Yes.
> >
> >> However, the new VM consistency checks require that using EPT
> >> redirection requires clear/load CTL on exit/entry be set, and having load 
> >> on entry set requires the host TraceEn to be clear.
> > Yes. New bits added in VMCS can make sure PT be disabled before VM exit and 
> > IA32_RTIT_CTL MSR will be written with the value
> of the associated Guest State field of the VMCS on VM entry.
> 
> I am not sure I explained myself clearly.
> 
> It appears that it is possible to implement host-guest mode using MSR load 
> lists, because all the host configuration gets replaced by
> guest configuration on vmentry, and host configuration gets restored at 
> vmexit.

Yes, correct.

> 
> However with these PT extension, a new restriction is that a vmentry failure 
> will occur if we try to load the guest RTIT_CTL value
> while the current RTIT_CTL.TraceEn is set.

Yes, as description in "Intel® architecture instruction set extensions 
programming reference" 5.2.3. 
If the “Load IA32_RTIT_CTL on entry” is 1, IA32_RTIT_CTL.TraceEn must be zero. 
Otherwise will VM entry fails by loading processor state from the guest-state 
area of the VMCS.

> 
> As far as I can tell, this prohibits host-guest mode from working, unless we 
> tolerate having Xen clear RTIT_CTL before restoring guest
> GPR state.

Yes. If implement host-guest mode we should clear RTIT_CTL first and restore 
the guest state before VM-entry .
1. Clear RTIT_CTL before configuration MSRs. A WRMSR to any of these 
configuration MSRs that begins and ends with IA32_RTIT_CTL.TraceEn set will #GP 
fault. Packet generation must be disabled before the configuration MSRs 

Re: [Xen-devel] [RFC XEN PATCH v3 00/39] Add vNVDIMM support to HVM domains

[Haozhong Zhang]

On 10/27/17 11:26 +0800, Chao Peng wrote:
> On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote:
> > Overview
> > ==
> > 
> > > (RFC v2 can be found at https://lists.xen.org/archives/html/xen-
> devel/2017-03/msg02401.html)
> > 
> > Well, this RFC v3 changes and inflates a lot from previous versions.
> > The primary changes are listed below, most of which are to simplify
> > the first implementation and avoid additional inflation.
> > 
> > 1. Drop the support to maintain the frametable and M2P table of PMEM
> >    in RAM. In the future, we may add this support back.
> 
> I don't find any discussion in v2 about this, but I'm thinking putting
> those Xen data structures in RAM sometimes is useful (e.g. when
> performance is important). It's better not making hard restriction on
> this.

Well, this is to reduce the complexity, as you see the current patch
size is already too big. In addition, the size of NVDIMM can be very
large, e.g. several tera-bytes or even more, which would require a
large RAM space to store its frametable and M2P (~10 MB per 1 GB) and
leave fewer RAM for guest usage.

> 
> > 
> > 2. Hide host NFIT and deny access to host PMEM from Dom0. In other
> >    words, the kernel NVDIMM driver is loaded in Dom 0 and existing
> >    management utilities (e.g. ndctl) do not work in Dom0 anymore. This
> >    is to workaround the inferences of PMEM access between Dom0 and Xen
> >    hypervisor. In the future, we may add a stub driver in Dom0 which
> >    will hold the PMEM pages being used by Xen hypervisor and/or other
> >    domains.
> > 
> > 3. As there is no NVDIMM driver and management utilities in Dom0 now,
> > >    we cannot easily specify an area of host NVDIMM (e.g., by
> /dev/pmem0)
> >    and manage NVDIMM in Dom0 (e.g., creating labels).  Instead, we
> >    have to specify the exact MFNs of host PMEM pages in xl domain
> >    configuration files and the newly added Xen NVDIMM management
> >    utility xen-ndctl.
> > 
> >    If there are indeed some tasks that have to be handled by existing
> >    driver and management utilities, such as recovery from hardware
> >    failures, they have to be accomplished out of Xen environment.
> 
> What kind of recovery can happen and does the recovery can happen at
> runtime? For example, can we recover a portion of NVDIMM assigned to a
> certain VM while keep other VMs still using NVDIMM?

For example, evaluate ACPI _DSM (maybe vendor specific) for error
recovery and/or scrubbing bad blocks, etc.

> 
> > 
> >    After 2. is solved in the future, we would be able to make existing
> >    driver and management utilities work in Dom0 again.
> 
> Is there any reason why we can't do it now? If existing ndctl (with
> additional patches) can work then we don't need introduce xen-ndctl
> anymore? I think that keeps user interface clearer.

The simple reason is I want to reduce the components (Xen/kernel/QEMU)
touched by the first patchset (whose primary target is to implement
the basic functionality, i.e. mapping host NVDIMM to guest as a
virtual NVDIMM). As you said, leaving a driver (the nvdimm driver
and/or a stub driver) in Dom0 would make the user interface
clearer. Let's see what I can get in the next version.

Thanks,
Haozhong

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC XEN PATCH v3 00/39] Add vNVDIMM support to HVM domains

[Chao Peng]

On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote:
> Overview
> ==
> 
> > (RFC v2 can be found at https://lists.xen.org/archives/html/xen-
devel/2017-03/msg02401.html)
> 
> Well, this RFC v3 changes and inflates a lot from previous versions.
> The primary changes are listed below, most of which are to simplify
> the first implementation and avoid additional inflation.
> 
> 1. Drop the support to maintain the frametable and M2P table of PMEM
>    in RAM. In the future, we may add this support back.

I don't find any discussion in v2 about this, but I'm thinking putting
those Xen data structures in RAM sometimes is useful (e.g. when
performance is important). It's better not making hard restriction on
this.

> 
> 2. Hide host NFIT and deny access to host PMEM from Dom0. In other
>    words, the kernel NVDIMM driver is loaded in Dom 0 and existing
>    management utilities (e.g. ndctl) do not work in Dom0 anymore. This
>    is to workaround the inferences of PMEM access between Dom0 and Xen
>    hypervisor. In the future, we may add a stub driver in Dom0 which
>    will hold the PMEM pages being used by Xen hypervisor and/or other
>    domains.
> 
> 3. As there is no NVDIMM driver and management utilities in Dom0 now,
> >    we cannot easily specify an area of host NVDIMM (e.g., by
/dev/pmem0)
>    and manage NVDIMM in Dom0 (e.g., creating labels).  Instead, we
>    have to specify the exact MFNs of host PMEM pages in xl domain
>    configuration files and the newly added Xen NVDIMM management
>    utility xen-ndctl.
> 
>    If there are indeed some tasks that have to be handled by existing
>    driver and management utilities, such as recovery from hardware
>    failures, they have to be accomplished out of Xen environment.

What kind of recovery can happen and does the recovery can happen at
runtime? For example, can we recover a portion of NVDIMM assigned to a
certain VM while keep other VMs still using NVDIMM?

> 
>    After 2. is solved in the future, we would be able to make existing
>    driver and management utilities work in Dom0 again.

Is there any reason why we can't do it now? If existing ndctl (with
additional patches) can work then we don't need introduce xen-ndctl
anymore? I think that keeps user interface clearer.

Chao___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 115247: tolerable all pass - PUSHED

[osstest service owner]

flight 115247 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115247/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114825
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114825
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114825
 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 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  f4973d1ea88b2e807fc2c52a5fc281a1c289d50e
baseline version:
 libvirt  08d4e16f88f9cb0e078b544f49a0647c8847fe95

Last test of basis   114825  2017-10-21 04:47:31 Z5 days
Failing since115172  2017-10-24 04:20:11 Z2 days3 attempts
Testing same since   115202  2017-10-25 04:30:44 Z1 days2 attempts


People who touched revisions under test:
  Jiri Denemark 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-i386-libvirt-qcow2pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd 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 :

+ branch=libvirt
+ revision=f4973d1ea88b2e807fc2c52a5fc281a1c289d50e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ 

[Xen-devel] [qemu-mainline test] 115263: regressions - FAIL

[osstest service owner]

flight 115263 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115263/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 114507
 build-amd64-xsm   6 xen-buildfail REGR. vs. 114507
 build-i386-xsm6 xen-buildfail REGR. vs. 114507
 build-amd64   6 xen-buildfail REGR. vs. 114507
 build-armhf-xsm   6 xen-buildfail REGR. vs. 114507
 build-armhf   6 xen-buildfail REGR. vs. 114507

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 

Re: [Xen-devel] [PATCH V3 8/29] tools/libxl: create vIOMMU during domain construction

[Lan Tianyu]

On 2017年10月26日 20:05, Wei Liu wrote:
> On Thu, Oct 19, 2017 at 11:13:57AM +0100, Roger Pau Monné wrote:
>>> +
>>> +if (viommu->type == LIBXL_VIOMMU_TYPE_INTEL_VTD) {
>>> +ret = xc_viommu_create(ctx->xch, domid, 
>>> VIOMMU_TYPE_INTEL_VTD,
>>> +   viommu->base_addr, viommu->cap, 
>>> );
>>
>> As said in another patch: this will break compilation because
>> xc_viommu_create is introduced in patch 9.
>>
>> Please organize the patches in a way that the code always compiles and
>> works fine. Keep in mind that the Xen tree should be bisectable
>> always.
>>
> 
> +10 to this.
> 
> We rely heavily on our test system's bisector to tell us what is wrong.
> The bisector works on patch level. Please make sure every patch builds,
> otherwise the test system will just give up.
> 
> If triaging can be done automatically by computers, maintainers can
> spend less time doing tedious work and more time reviewing patches
> (yours included).

Sure. Will pay more attention on this.

> 
> Normally I use git-rebase to build every commit, but I figured that's a
> bit too dangerous so I wrote a script.
> 
> Please check out:
> 
>   [PATCH v3 for-4.10] scripts: introduce a script for build test
> 
> It is still under review, but you can fish out some of the runes to do
> build tests.

This is very helpful. Thanks.
-- 
Best regards
Tianyu Lan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-linus test] 115244: regressions - FAIL

[osstest service owner]

flight 115244 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115244/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114682
 test-amd64-i386-libvirt-qcow2 10 debian-di-install   fail REGR. vs. 114682

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114682
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114682
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114682
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114682
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 114682
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114682
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114682
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114682
 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  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-credit2  14 saverestore-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-libvirt-xsm 13 migrate-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-qemut-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-qemut-win10-i386 10 windows-installfail 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-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass

version targeted for testing:
 linuxf34157878d3b17641ad2366988600c23c89d98b2
baseline version:
 linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb

Last test of basis   114682  2017-10-18 09:54:11 Z8 days
Failing since114781  2017-10-20 01:00:47 Z7 days   11 attempts
Testing same since   115244  2017-10-26 02:09:01 Z0 days1 attempts


323 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvops   

Re: [Xen-devel] [Qemu-devel] [PATCH] x86: Skip check apic_id_limit for Xen

[Lan Tianyu]

On 2017年10月26日 22:27, Michael S. Tsirkin wrote:
> On Thu, Oct 26, 2017 at 02:19:43PM +0200, Eduardo Habkost wrote:
>> On Mon, Aug 21, 2017 at 10:22:15AM +0800, Lan Tianyu wrote:
>>> On 2017年08月19日 00:38, Eduardo Habkost wrote:
 On Thu, Aug 17, 2017 at 09:37:10AM +0800, Lan Tianyu wrote:
> On 2017年08月16日 19:21, Paolo Bonzini wrote:
>> On 16/08/2017 02:22, Lan Tianyu wrote:
>>> Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
>>> check for Xen here when vcpu number is more than 255.
>>
>> I think you still need to do a check for vIOMMU being enabled.
>
> Yes, this will be done in the Xen tool stack and Qemu doesn't have such
> knowledge. Operations of create, destroy Xen vIOMMU will be done in the
> Xen tool stack.

 Shouldn't we make QEMU have knowledge of the vIOMMU device, then?
 Won't QEMU need to know about it eventually?

>>>
>>> Hi Eduardo:
>>>  Thanks for your review.
>>>  Xen has some guest modes which doesn't use Qemu and we tried to
>>> make Xen vIOMMU framework compatible with all guest modes. So far, we
>>> are adding interrupt remapping function for Xen vIOMMU and find qemu
>>> doesn't need to know Xen vIOMMU. The check of vcpu number > 255 here
>>> will be done in Xen side and so skip the check in Qemu to avoid blocking
>>> Xen creating >255 vcpus.
>>>  We may make Qemu have knowledge of the vIOMMU device if it's
>>> necessary when adding new function.
>>
>> I was expecting it to go through the PC tree, but I will queue it
>> on x86-next instead.
> 
> I was waiting for an ack from you or Paolo as you participated in the
> discussion. But sure, go ahead
> 
> Acked-by: Michael S. Tsirkin 
> 

Great. Thanks.
-- 
Best regards
Tianyu Lan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-4.9 test] 115242: regressions - FAIL

[osstest service owner]

flight 115242 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115242/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114814

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 114766
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114814
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114814
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114814
 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-i386-libvirt  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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-i386-libvirt-qcow2 12 migrate-support-checkfail  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-libvirt 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-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 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-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-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-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-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-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux4d4a6a3f8a12602ce8dc800123715fe7b5c1c3a1
baseline version:
 linux5d7a76acad403638f635c918cc63d1d44ffa4065

Last test of basis   114814  2017-10-20 20:51:56 Z6 days
Testing same since   114845  2017-10-21 16:14:17 Z5 days9 attempts


People who touched revisions under test:
  Alex Deucher 
  Alexandre Belloni 
  Andrew Morton 
  Anoob Soman 
  Arnd Bergmann 
  Bart Van Assche 
  Ben Skeggs 
  Bin Liu 
  Borislav Petkov 
  Christoph Lameter 
  Christophe JAILLET 
  Coly Li 
  Dan Carpenter 
  David Rientjes 
  David S. Miller 
  Dennis Dalessandro 
  Dmitry V. Levin 
  Doug Ledford 

[Xen-devel] [xen-4.7-testing baseline-only test] 72355: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72355 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72355/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail blocked 
in 72337
 test-amd64-i386-freebsd10-amd64 11 guest-start fail like 72337
 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-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-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-libvirt 14 saverestore-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-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 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-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-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-qemuu-nested-intel 18 capture-logs/l1(18) fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass

version targeted for testing:
 xen  830224431b67fd2afad9bdc532dc1bede20032d5
baseline version:
 xen  df0949d197cc753871f5df1a0358b43edd2fd365

Last test of basis72337  2017-10-21 04:15:02 Z5 days
Testing same since72355  

[Xen-devel] [PULL 2/3] xen: dont try setting max grants multiple times

[Stefano Stabellini]

From: Juergen Gross 

Trying to call xengnttab_set_max_grants() with the same file handle
might fail on some kernels, as this operation is allowed only once.

This is a problem for the qdisk backend as blk_connect() can be
called multiple times for a domain, e.g. in case grub-xen is being
used to boot it.

So instead of letting the generic backend code open the gnttab device
do it in blk_connect() and close it again in blk_disconnect.

Signed-off-by: Juergen Gross 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_disk.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 62506e3..e431bd8 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -1220,6 +1220,12 @@ static int blk_connect(struct XenDevice *xendev)
 /* Add on the number needed for the ring pages */
 max_grants += blkdev->nr_ring_ref;
 
+blkdev->xendev.gnttabdev = xengnttab_open(NULL, 0);
+if (blkdev->xendev.gnttabdev == NULL) {
+xen_pv_printf(xendev, 0, "xengnttab_open failed: %s\n",
+  strerror(errno));
+return -1;
+}
 if (xengnttab_set_max_grants(blkdev->xendev.gnttabdev, max_grants)) {
 xen_pv_printf(xendev, 0, "xengnttab_set_max_grants failed: %s\n",
   strerror(errno));
@@ -1327,6 +1333,11 @@ static void blk_disconnect(struct XenDevice *xendev)
 }
 blkdev->feature_persistent = false;
 }
+
+if (blkdev->xendev.gnttabdev) {
+xengnttab_close(blkdev->xendev.gnttabdev);
+blkdev->xendev.gnttabdev = NULL;
+}
 }
 
 static int blk_free(struct XenDevice *xendev)
@@ -1334,9 +1345,7 @@ static int blk_free(struct XenDevice *xendev)
 struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
 struct ioreq *ioreq;
 
-if (blkdev->blk || blkdev->sring) {
-blk_disconnect(xendev);
-}
+blk_disconnect(xendev);
 
 while (!QLIST_EMPTY(>freelist)) {
 ioreq = QLIST_FIRST(>freelist);
@@ -1363,7 +1372,6 @@ static void blk_event(struct XenDevice *xendev)
 
 struct XenDevOps xen_blkdev_ops = {
 .size   = sizeof(struct XenBlkDev),
-.flags  = DEVOPS_FLAG_NEED_GNTDEV,
 .alloc  = blk_alloc,
 .init   = blk_init,
 .initialise= blk_connect,
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PULL 0/3] xen-20171026-tag

[Stefano Stabellini]

The following changes since commit 325a084c1ebccb265a3c8f1dd092ffbbfb448a00:

  Merge remote-tracking branch 
'remotes/stefanberger/tags/pull-tpm-2017-10-24-1' into staging (2017-10-26 
09:20:11 +0100)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20171026-tag

for you to fetch changes up to 7cdcca725b6bfc96634c15e3f74ae4b148cf9c40:

  xen: Log errno rather than return value (2017-10-26 14:26:48 -0700)


Xen 2017/10/26


Juergen Gross (2):
  xen: add a global indicator for grant copy being available
  xen: dont try setting max grants multiple times

Ross Lagerwall (1):
  xen: Log errno rather than return value

 hw/block/xen_disk.c  | 34 ++
 hw/i386/xen/xen-hvm.c|  2 +-
 hw/xen/xen_backend.c | 11 +++
 include/hw/xen/xen_backend.h |  1 +
 4 files changed, 31 insertions(+), 17 deletions(-)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PULL 3/3] xen: Log errno rather than return value

[Stefano Stabellini]

From: Ross Lagerwall 

xen_modified_memory() sets errno to communicate what went wrong so log
this rather than the return value which is not interesting.

Signed-off-by: Ross Lagerwall 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/i386/xen/xen-hvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index d9ccd5d..8028bed 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1446,7 +1446,7 @@ void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t 
length)
 if (rc) {
 fprintf(stderr,
 "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n",
-__func__, start, nb_pages, rc, strerror(-rc));
+__func__, start, nb_pages, errno, strerror(errno));
 }
 }
 }
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PULL 1/3] xen: add a global indicator for grant copy being available

[Stefano Stabellini]

From: Juergen Gross 

The Xen qdisk backend needs to test whether grant copy operations is
available in the kernel. Unfortunately this collides with using
xengnttab_set_max_grants() on some kernels as this operation has to
be the first one after opening the gnttab device.

In order to solve this problem test for the availability of grant copy
in xen_be_init() opening the gnttab device just for that purpose and
closing it again afterwards. Advertise the availability via a global
flag and use that flag in the qdisk backend.

Signed-off-by: Juergen Gross 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_disk.c  | 18 ++
 hw/xen/xen_backend.c | 11 +++
 include/hw/xen/xen_backend.h |  1 +
 3 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 536e2ee..62506e3 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -121,9 +121,6 @@ struct XenBlkDev {
 unsigned intpersistent_gnt_count;
 unsigned intmax_grants;
 
-/* Grant copy */
-gbooleanfeature_grant_copy;
-
 /* qemu block driver */
 DriveInfo   *dinfo;
 BlockBackend*blk;
@@ -616,7 +613,7 @@ static void qemu_aio_complete(void *opaque, int ret)
 return;
 }
 
-if (ioreq->blkdev->feature_grant_copy) {
+if (xen_feature_grant_copy) {
 switch (ioreq->req.operation) {
 case BLKIF_OP_READ:
 /* in case of failure ioreq->aio_errors is increased */
@@ -638,7 +635,7 @@ static void qemu_aio_complete(void *opaque, int ret)
 }
 
 ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
-if (!ioreq->blkdev->feature_grant_copy) {
+if (!xen_feature_grant_copy) {
 ioreq_unmap(ioreq);
 }
 ioreq_finish(ioreq);
@@ -698,7 +695,7 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
 
-if (ioreq->blkdev->feature_grant_copy) {
+if (xen_feature_grant_copy) {
 ioreq_init_copy_buffers(ioreq);
 if (ioreq->req.nr_segments && (ioreq->req.operation == BLKIF_OP_WRITE 
||
 ioreq->req.operation == BLKIF_OP_FLUSH_DISKCACHE) &&
@@ -750,7 +747,7 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 }
 default:
 /* unknown operation (shouldn't happen -- parse catches this) */
-if (!ioreq->blkdev->feature_grant_copy) {
+if (!xen_feature_grant_copy) {
 ioreq_unmap(ioreq);
 }
 goto err;
@@ -1010,18 +1007,15 @@ static int blk_init(struct XenDevice *xendev)
 
 blkdev->file_blk  = BLOCK_SIZE;
 
-blkdev->feature_grant_copy =
-(xengnttab_grant_copy(blkdev->xendev.gnttabdev, 0, NULL) == 0);
-
 xen_pv_printf(>xendev, 3, "grant copy operation %s\n",
-  blkdev->feature_grant_copy ? "enabled" : "disabled");
+  xen_feature_grant_copy ? "enabled" : "disabled");
 
 /* fill info
  * blk_connect supplies sector-size and sectors
  */
 xenstore_write_be_int(>xendev, "feature-flush-cache", 1);
 xenstore_write_be_int(>xendev, "feature-persistent",
-  !blkdev->feature_grant_copy);
+  !xen_feature_grant_copy);
 xenstore_write_be_int(>xendev, "info", info);
 
 xenstore_write_be_int(>xendev, "max-ring-page-order",
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index c46cbb0..0f849a2 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -44,6 +44,7 @@ BusState *xen_sysbus;
 /* public */
 struct xs_handle *xenstore = NULL;
 const char *xen_protocol;
+bool xen_feature_grant_copy;
 
 /* private */
 static int debug;
@@ -519,6 +520,8 @@ void xenstore_update_fe(char *watch, struct XenDevice 
*xendev)
 
 int xen_be_init(void)
 {
+xengnttab_handle *gnttabdev;
+
 xenstore = xs_daemon_open();
 if (!xenstore) {
 xen_pv_printf(NULL, 0, "can't connect to xenstored\n");
@@ -532,6 +535,14 @@ int xen_be_init(void)
 goto err;
 }
 
+gnttabdev = xengnttab_open(NULL, 0);
+if (gnttabdev != NULL) {
+if (xengnttab_grant_copy(gnttabdev, 0, NULL) == 0) {
+xen_feature_grant_copy = true;
+}
+xengnttab_close(gnttabdev);
+}
+
 xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
 qdev_init_nofail(xen_sysdev);
 xen_sysbus = qbus_create(TYPE_XENSYSBUS, DEVICE(xen_sysdev), "xen-sysbus");
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 8a6fbcb..3a27692 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -16,6 +16,7 @@
 /* variables */
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
+extern bool xen_feature_grant_copy;
 extern DeviceState *xen_sysdev;
 extern BusState *xen_sysbus;
 
-- 
1.9.1

Re: [Xen-devel] [PATCH v5.1 5/8] xen: move xc_interface compatibility fallback further up the file

[Stefano Stabellini]

On Fri, 20 Oct 2017, Ian Jackson wrote:
> We are going to want to use the dummy xendevicemodel_handle type in
> new stub functions in the CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
> section.  So we need to provide that definition, or (as applicable)
> include the appropriate header, earlier in the file.
> 
> (Ideally the newer compatibility layers would be at the bottom of the
> file, so that they can naturally benefit from the compatibility layers
> for earlier version.  But that's rather too much for this series.)
> 
> No functional change.
> 
> Signed-off-by: Ian Jackson 
> Acked-by: Anthony PERARD 

Acked-by: Stefano Stabellini 


> ---
> v2: New patch in v2 of the series
> ---
>  include/hw/xen/xen_common.h | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 3f44a63..8efdb8a 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -78,6 +78,17 @@ static inline void *xenforeignmemory_map(xc_interface *h, 
> uint32_t dom,
>  
>  extern xenforeignmemory_handle *xen_fmem;
>  
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
> +
> +typedef xc_interface xendevicemodel_handle;
> +
> +#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
> +
> +#undef XC_WANT_COMPAT_DEVICEMODEL_API
> +#include 
> +
> +#endif
> +
>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
>  
>  #define XEN_COMPAT_PHYSMAP
> @@ -105,8 +116,6 @@ static inline int xentoolcore_restrict_all(domid_t domid)
>  
>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
>  
> -typedef xc_interface xendevicemodel_handle;
> -
>  static inline xendevicemodel_handle *xendevicemodel_open(
>  struct xentoollog_logger *logger, unsigned int open_flags)
>  {
> @@ -228,11 +237,6 @@ static inline int xendevicemodel_set_mem_type(
>  return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
>  }
>  
> -#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
> -
> -#undef XC_WANT_COMPAT_DEVICEMODEL_API
> -#include 
> -
>  #endif
>  
>  extern xendevicemodel_handle *xen_dmod;
> -- 
> 2.1.4
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] arm/xen: don't inclide rwlock.h directly.1~B

[Boris Ostrovsky]

On 10/05/2017 03:58 PM, Stefano Stabellini wrote:
> On Thu, 5 Oct 2017, Sebastian Andrzej Siewior wrote:
>> rwlock.h should not be included directly. Instead linux/splinlock.h
>> should be included. One thing it does is to break the RT build.
>>
>> Cc: Stefano Stabellini 
>> Cc: xen-de...@lists.xenproject.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Signed-off-by: Sebastian Andrzej Siewior 
> Reviewed-by: Stefano Stabellini 


Applied to for-linus-4.14c.

-boris



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen: fix booting ballooned down hvm guest

[Boris Ostrovsky]

On 10/26/2017 10:12 AM, Boris Ostrovsky wrote:
> On 10/26/2017 05:50 AM, Juergen Gross wrote:
>> Commit 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't
>> online new memory initially") introduced a regression when booting a
>> HVM domain with memory less than mem-max: instead of ballooning down
>> immediately the system would try to use the memory up to mem-max
>> resulting in Xen crashing the domain.
>>
>> For HVM domains the current size will be reflected in Xenstore node
>> memory/static-max instead of memory/target.
>>
>> Additionally we have to trigger the ballooning process at once.
>>
>> Cc:  # 4.13
>> Fixes: 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't
>>online new memory initially")
>>
>> Reported-by: Simon Gaiser 
>> Suggested-by: Boris Ostrovsky 
>> Signed-off-by: Juergen Gross 
> Reviewed-by: Boris Ostrovsky 
>

Applied to for-linus-4.14c.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()

[Boris Ostrovsky]

On 10/25/2017 12:46 PM, Boris Ostrovsky wrote:
> On 10/25/2017 11:08 AM, Juergen Gross wrote:
>> In case gntdev_mmap() succeeds only partially in mapping grant pages
>> it will leave some vital information uninitialized needed later for
>> cleanup. This will lead to an out of bounds array access when unmapping
>> the already mapped pages.
>>
>> So just initialize the data needed for unmapping the pages a little bit
>> earlier.
>>
>> Cc: 
>> Reported-by: Arthur Borsboom 
>> Signed-off-by: Juergen Gross 
> Reviewed-by: Boris Ostrovsky 
>


Applied to for-linus-4.14c.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5.1 1/8] xen: link against xentoolcore

[Stefano Stabellini]

On Fri, 20 Oct 2017, Ian Jackson wrote:
> From: Anthony PERARD 
> 
> Xen libraries in 4.10 include a new xentoolcore library.  This
> contains the xentoolcore_restrict_all function which we are about to
> want to use.
> 
> Signed-off-by: Ian Jackson 
> ---
> v5: More truthful commit message.
> ---
>  configure | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/configure b/configure
> index fd7e3a5..6f691df 100755
> --- a/configure
> +++ b/configure
> @@ -2072,7 +2072,7 @@ if test "$xen" != "no" ; then
>$($pkg_config --modversion xencontrol | sed 's/\./ /g') )"
>  xen=yes
>  xen_pc="xencontrol xenstore xenguest xenforeignmemory xengnttab"
> -xen_pc="$xen_pc xenevtchn xendevicemodel"
> +xen_pc="$xen_pc xenevtchn xendevicemodel xentoolcore"
>  QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
>  libs_softmmu="$($pkg_config --libs $xen_pc) $libs_softmmu"
>  LDFLAGS="$($pkg_config --libs $xen_pc) $LDFLAGS"
> @@ -2104,18 +2104,20 @@ EOF
>  cat > $TMPC <  #undef XC_WANT_COMPAT_MAP_FOREIGN_API
>  #include 
> +#include 
>  int main(void) {
>xenforeignmemory_handle *xfmem;
>  
>xfmem = xenforeignmemory_open(0, 0);
>xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
> +  xentoolcore_restrict_all(0);
>  
>return 0;
>  }
>  EOF
> -compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
> +compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs 
> -lxentoolcore"
>then
> -  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
> +  xen_stable_libs="-lxendevicemodel $xen_stable_libs -lxentoolcore"

Is it on purpose that -lxentoolcore is at the end of this string rather
than before $xen_stable_libs?

In any case

Acked-by: Stefano Stabellini 


>xen_ctrl_version=41000
>xen=yes
>  elif
> -- 
> 2.1.4
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5.1 7/8] os-posix: Provide new -runas : facility

[Stefano Stabellini]

CC'ing the maintainers (scripts/get_maintainer.pl is your friend)

On Fri, 20 Oct 2017, Ian Jackson wrote:
> This allows the caller to specify a uid and gid to use, even if there
> is no corresponding password entry.  This will be useful in certain
> Xen configurations.
> 
> We don't support just -runas  because: (i) deprivileging without
> calling setgroups would be ineffective (ii) given only a uid we don't
> know what gid we ought to use (since uids may eppear in multiple
> passwd file entries with different gids).
> 
> Signed-off-by: Ian Jackson 
> ---
> v5: Use : rather than . to separate uid from gid
> v4: Changed to reuse option -runas
> v3: Error messages fixed.  Thanks to Peter Maydell and Ross Lagerwall.
> v2: Coding style fixes.
> 
> squash! os-posix: Provide new -runas . facility
> ---
>  os-posix.c  | 64 
> +++--
>  qemu-options.hx |  3 ++-
>  2 files changed, 55 insertions(+), 12 deletions(-)
> 
> diff --git a/os-posix.c b/os-posix.c
> index 92e9d85..f95b7bf 100644
> --- a/os-posix.c
> +++ b/os-posix.c
> @@ -43,6 +43,8 @@
>  #endif
>  
>  static struct passwd *user_pwd;
> +static uid_t user_uid = (uid_t)-1;
> +static gid_t user_gid = (gid_t)-1;
>  static const char *chroot_dir;
>  static int daemonize;
>  static int daemon_pipe;
> @@ -128,6 +130,34 @@ void os_set_proc_name(const char *s)
>  #endif
>  }
>  
> +
> +static bool os_parse_runas_uid_gid(const char *optarg)
> +{
> +unsigned long lv;
> +char *ep;
> +uid_t got_uid;
> +gid_t got_gid;
> +int rc;
> +
> +errno = 0;
> +lv = strtoul(optarg, , 0); /* can't qemu_strtoul, want *ep==':' */
> +got_uid = lv; /* overflow here is ID in C99 */
> +if (errno || *ep != ':' || got_uid != lv || got_uid == (uid_t)-1) {
> +return false;
> +}
> +
> +lv = 0;
> +rc = qemu_strtoul(ep + 1, 0, 0, );
> +got_gid = lv; /* overflow here is ID in C99 */
> +if (rc || got_gid != lv || got_gid == (gid_t)-1) {
> +return false;
> +}
> +
> +user_uid = got_uid;
> +user_gid = got_gid;
> +return true;
> +}
> +
>  /*
>   * Parse OS specific command line options.
>   * return 0 if option handled, -1 otherwise
> @@ -145,8 +175,10 @@ void os_parse_cmd_args(int index, const char *optarg)
>  #endif
>  case QEMU_OPTION_runas:
>  user_pwd = getpwnam(optarg);
> -if (!user_pwd) {
> -fprintf(stderr, "User \"%s\" doesn't exist\n", optarg);
> +if (!user_pwd && !os_parse_runas_uid_gid(optarg)) {
> +fprintf(stderr,
> +"User \"%s\" doesn't exist (and is not .)\n",
> +optarg);
>  exit(1);
>  }
>  break;
> @@ -166,18 +198,28 @@ void os_parse_cmd_args(int index, const char *optarg)
>  
>  static void change_process_uid(void)
>  {
> -if (user_pwd) {
> -if (setgid(user_pwd->pw_gid) < 0) {
> -fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid);
> +if (user_pwd || user_uid != (uid_t)-1) {
> +gid_t intended_gid = user_pwd ? user_pwd->pw_gid : user_gid;
> +uid_t intended_uid = user_pwd ? user_pwd->pw_uid : user_uid;
> +if (setgid(intended_gid) < 0) {
> +fprintf(stderr, "Failed to setgid(%d)\n", intended_gid);
>  exit(1);
>  }
> -if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) {
> -fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n",
> -user_pwd->pw_name, user_pwd->pw_gid);
> -exit(1);
> +if (user_pwd) {
> +if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) {
> +fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n",
> +user_pwd->pw_name, user_pwd->pw_gid);
> +exit(1);
> +}
> +} else {
> +if (setgroups(1, _gid) < 0) {
> +fprintf(stderr, "Failed to setgroups(1, [%d])",
> +user_gid);
> +exit(1);
> +}
>  }
> -if (setuid(user_pwd->pw_uid) < 0) {
> -fprintf(stderr, "Failed to setuid(%d)\n", user_pwd->pw_uid);
> +if (setuid(intended_uid) < 0) {
> +fprintf(stderr, "Failed to setuid(%d)\n", intended_uid);
>  exit(1);
>  }
>  if (setuid(0) != -1) {
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 9f6e2ad..f707197e 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -3958,7 +3958,8 @@ ETEXI
>  
>  #ifndef _WIN32
>  DEF("runas", HAS_ARG, QEMU_OPTION_runas, \
> -"-runas user change to user id user just before starting the VM\n",
> +"-runas user change to user id user just before starting the VM\n" \
> +"user can be numeric uid:gid instead\n",
>  QEMU_ARCH_ALL)
>  #endif
>  STEXI
> -- 
> 2.1.4
> 

___
Xen-devel mailing list

Re: [Xen-devel] [PATCH v5.1 8/8] configure: do_compiler: Dump some extra info under bash

[Stefano Stabellini]

CC'ing the maintainers for this.

On Fri, 20 Oct 2017, Ian Jackson wrote:
> This makes it much easier to find a particular thing in config.log.
> 
> The information may be lacking in other shells, resulting in harmless
> empty output.  (This is why we don't use the proper ${FUNCNAME[*]}
> array syntax - other shells will choke on that.)
> 
> The extra output is only printed if configure is run with bash.  The
> something), it is necessary to say   bash ./configure  to get the extra
> debug info in the log.
> 
> Signed-off-by: Ian Jackson 
> ---
> v4: No longer tag this patch RFC.
> ---
>  configure | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/configure b/configure
> index 6f691df..21a2b15 100755
> --- a/configure
> +++ b/configure
> @@ -60,6 +60,10 @@ do_compiler() {
>  # is compiler binary to execute.
>  local compiler="$1"
>  shift
> +echo >>config.log "
> +funcs: ${FUNCNAME}
> +lines: ${BASH_LINENO}
> +files: ${BASH_SOURCE}"
>  echo $compiler "$@" >> config.log
>  $compiler "$@" >> config.log 2>&1 || return $?
>  # Test passed. If this is an --enable-werror build, rerun
> -- 
> 2.1.4
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Some Xen pci-passthrough questions

[Boris Ostrovsky]

On 10/26/2017 04:48 PM, Sander Eikelenboom wrote:
> Hi Boris / Andrew,
>
> In the aftermath of the linux mmap path I have some questions regarding 
> pci-passthrough:
>
> - Is pci-passthrough in combination with an auto-ballooning dom0 supposed to 
> be a supported combination ?

I thought it is. I haven't done passthrough recently (and can't do it
right now) but I when I did I am pretty sure I was running with
auto-ballooning dom0.

Our production does passthrough but they always run with dom0's memory
limited.

>
> I have used dom0_maxmem settings for dom0 since ages and that works fine 
> and stable, 
> but while doing some testing around the linux mmap patch i also thought 
> to try an auto-ballooning dom0.
>
> That ended up in a crashing PV guest with pci-passthrough and a strange 
> error on two HVM's with pci-passthrough,
> about vcpu's (while no configurations where changed).
>
> So if it is supported i probably have some more testing and reporting to 
> do ...
>
>
> - While adding some extra logging and enabling the logging on xen pt in qemu,
>   i wonder if it wouldn't be beneficial to have at least some basic logging 
> permanently enabled ? 
>
> - Enabling the xen pt logging in qemu spit out some things, i wonder if they 
> are normal:
>
> qemu-system-i386: -serial pty: char device redirected to /dev/pts/16 
> (label serial0)
> [00:05.0] xen_pt_realize: Assigning real physical device 08:00.0 to 
> devfn 0x28
> [00:05.0] xen_pt_register_regions: IO region 0 registered 
> (size=0x2000 base_addr=0xfe1fe000 type: 0x4)
>
> Are these somehow expected / benign (they also occur when pci passthrough 
> is succesful) ?:
> [00:05.0] xen_pt_config_reg_init: Offset 0x000e mismatch! 
> Emulated=0x0080, host=0x, syncing to 0x0080.
> [00:05.0] xen_pt_config_reg_init: Offset 0x0010 mismatch! 
> Emulated=0x, host=0xfe1fe004, syncing to 0xfe1fe004.
> [00:05.0] xen_pt_config_reg_init: Offset 0x0052 mismatch! 
> Emulated=0x, host=0x4803, syncing to 0x0003.
> [00:05.0] xen_pt_config_reg_init: Offset 0x0072 mismatch! 
> Emulated=0x, host=0x0086, syncing to 0x0080.
> [00:05.0] xen_pt_config_reg_init: Offset 0x00a4 mismatch! 
> Emulated=0x, host=0x8fc0, syncing to 0x8fc0.
> [00:05.0] xen_pt_config_reg_init: Offset 0x00b2 mismatch! 
> Emulated=0x, host=0x1012, syncing to 0x1012.
>
> [00:05.0] xen_pt_msix_init: get MSI-X table BAR base 0xfe1fe000
> [00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8
> [00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8, 
> PCI_MSIX_ENTRY_SIZE = 0x10,  msix->table_offset_adjust = 0,  msix->table_base 
> = 0xfe1fe000
> [00:05.0] xen_pt_msix_init: Error: Can't map physical MSI-X table: 
> Invalid argument

That's mmap() of /dev/mem failing:

mmap(NULL,
 total_entries * PCI_MSIX_ENTRY_SIZE +
msix->table_offset_adjust,
 PROT_READ,
 MAP_SHARED | MAP_LOCKED,
 fd,
 msix->table_base + table_off - msix->table_offset_adjust);


Are you running with Craig Bergstrom's patch?

-boris


> [00:05.0] xen_pt_msix_size_init: Error: Internal error: Invalid 
> xen_pt_msix_init.
> Failed to initialize 12/15, type = 0x1, rc: -22
> [00:05.0] xen_pt_msi_set_enable: disabling MSI.
>
> This crash seems to indicate the above disabling of MSI isn't handled 
> well enough to prevent this from happening: 
> *** Error in `/usr/local/lib/xen/bin/qemu-system-i386': corrupted 
> size vs. prev_size: 0x55ce13565570 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f700ab7ebcb]
> /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f700ab84f96]
> 
>
> --
> Sander


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5.1 6/8] xen: destroy_hvm_domain: Try xendevicemodel_shutdown

[Stefano Stabellini]

On Fri, 20 Oct 2017, Ian Jackson wrote:
> xc_interface_open etc. is not going to work if we have dropped
> privilege, but xendevicemodel_shutdown will if everything is new
> enough.
> 
> xendevicemodel_shutdown is only availabe in Xen 4.10 and later, so
> provide a stub for earlier versions.
> 
> Signed-off-by: Ian Jackson 
> Reviewed-by: Anthony PERARD 
> ---
> v2: Add compatibility stub for Xen < 4.10.
> Fix coding style.
> ---
>  hw/i386/xen/xen-hvm.c   | 10 ++
>  include/hw/xen/xen_common.h |  7 +++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index 83420cd..25b8b14 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -1386,9 +1386,19 @@ void destroy_hvm_domain(bool reboot)
>  {
>  xc_interface *xc_handle;
>  int sts;
> +int rc;
>  
>  unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
>  
> +if (xen_dmod) {
> +rc = xendevicemodel_shutdown(xen_dmod, xen_domid, reason);
> +if (!rc) {
> +return;
> +}
> +perror("xendevicemodel_shutdown failed");

I don't think is a good idea to print an error because this is actually
a normal condition when QEMU is build and run against an older Xen.
Users might get confused when looking at the logs.

But it would be correct to print an error if errno != ENOTTY.


> +/* well, try the old thing then */
> +}
> +
>  xc_handle = xc_interface_open(0, 0, 0);
>  if (xc_handle == NULL) {
>  fprintf(stderr, "Cannot acquire xenctrl handle\n");
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 8efdb8a..1d6fb57 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -108,6 +108,13 @@ static inline int xentoolcore_restrict_all(domid_t domid)
>  return -1;
>  }
>  
> +static inline int xendevicemodel_shutdown(xendevicemodel_handle *dmod,
> +  domid_t domid, unsigned int reason)
> +{
> +errno = ENOTTY;
> +return -1;
> +}
> +
>  #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 41000 */
>  
>  #include 
> -- 
> 2.1.4
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5.1 4/8] xen: destroy_hvm_domain: Move reason into a variable

[Stefano Stabellini]

On Fri, 20 Oct 2017, Ian Jackson wrote:
> We are going to want to reuse this.
> 
> No functional change.
> 
> Signed-off-by: Ian Jackson 
> Reviewed-by: Anthony PERARD 

Acked-by: Stefano Stabellini 


> ---
>  hw/i386/xen/xen-hvm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index 7b60ec6..83420cd 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -1387,12 +1387,13 @@ void destroy_hvm_domain(bool reboot)
>  xc_interface *xc_handle;
>  int sts;
>  
> +unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
> +
>  xc_handle = xc_interface_open(0, 0, 0);
>  if (xc_handle == NULL) {
>  fprintf(stderr, "Cannot acquire xenctrl handle\n");
>  } else {
> -sts = xc_domain_shutdown(xc_handle, xen_domid,
> - reboot ? SHUTDOWN_reboot : 
> SHUTDOWN_poweroff);
> +sts = xc_domain_shutdown(xc_handle, xen_domid, reason);
>  if (sts != 0) {
>  fprintf(stderr, "xc_domain_shutdown failed to issue %s, "
>  "sts %d, %s\n", reboot ? "reboot" : "poweroff",
> -- 
> 2.1.4
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5.1 3/8] xen: defer call to xen_restrict until just before os_setup_post

[Stefano Stabellini]

This patch affects non-Xen components. CC'ing the relevant maintainers.

On Fri, 20 Oct 2017, Ian Jackson wrote:
> We need to restrict *all* the control fds that qemu opens.  Looking in
> /proc/PID/fd shows there are many; their allocation seems scattered
> throughout Xen support code in qemu.
> 
> We must postpone the restrict call until roughly the same time as qemu
> changes its uid, chroots (if applicable), and so on.
> 
> There doesn't seem to be an appropriate hook already.  The RunState
> change hook fires at different times depending on exactly what mode
> qemu is operating in.
> 
> And it appears that no-one but the Xen code wants a hook at this phase
> of execution.  So, introduce a bare call to a new function
> xen_setup_post, just before os_setup_post.  Also provide the
> appropriate stub for when Xen compilation is disabled.
> 
> We do the restriction before rather than after os_setup_post, because
> xen_restrict may need to open /dev/null, and os_setup_post might have
> called chroot.
> 
> Currently this does not work with migration, because when running as
> the Xen device model qemu needs to signal to the toolstack that it is
> ready.  It currently does this using xenstore, and for incoming
> migration (but not for ordinary startup) that happens after
> os_setup_post.
> 
> It is correct that this happens late: we want the incoming migration
> stream to be processed by a restricted qemu.  The fix for this will be
> to do the startup notification a different way, without using
> xenstore.  (QMP is probably a reasonable choice.)
> 
> So for now this restriction feature cannot be used in conjunction with
> migration.  (Note that this is not a regression in this patch, because
> previously the -xen-restrict-domid call was, in fact, simply
> ineffective!)  We will revisit this in the Xen 4.11 release cycle.
> 
> Signed-off-by: Ian Jackson 
> Reviewed-by: Anthony PERARD 
> ---
> v5: Discuss problems with migration startup notification
> in the commit message.
> v3: Do xen_setup_post just before, not just after, os_setup_post,
> to improve interaction with chroot.  Thanks to Ross Lagerwall.
> ---
>  hw/i386/xen/xen-hvm.c   |  8 
>  hw/xen/xen-common.c | 13 +
>  include/sysemu/sysemu.h |  2 ++
>  stubs/xen-hvm.c |  5 +
>  vl.c|  1 +
>  5 files changed, 21 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index d9ccd5d..7b60ec6 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -1254,14 +1254,6 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
> **ram_memory)
>  goto err;
>  }
>  
> -if (xen_domid_restrict) {
> -rc = xen_restrict(xen_domid);
> -if (rc < 0) {
> -error_report("failed to restrict: error %d", errno);
> -goto err;
> -}
> -}
> -
>  xen_create_ioreq_server(xen_domid, >ioservid);
>  
>  state->exit.notify = xen_exit_notifier;
> diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
> index 632a938..4056420 100644
> --- a/hw/xen/xen-common.c
> +++ b/hw/xen/xen-common.c
> @@ -117,6 +117,19 @@ static void xen_change_state_handler(void *opaque, int 
> running,
>  }
>  }
>  
> +void xen_setup_post(void)
> +{
> +int rc;
> +
> +if (xen_domid_restrict) {
> +rc = xen_restrict(xen_domid);
> +if (rc < 0) {
> +perror("xen: failed to restrict");
> +exit(1);
> +}
> +}
> +}
> +
>  static int xen_init(MachineState *ms)
>  {
>  xen_xc = xc_interface_open(0, 0, 0);
> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> index b213696..b064a55 100644
> --- a/include/sysemu/sysemu.h
> +++ b/include/sysemu/sysemu.h
> @@ -93,6 +93,8 @@ void qemu_remove_machine_init_done_notifier(Notifier 
> *notify);
>  
>  void qemu_announce_self(void);
>  
> +void xen_setup_post(void);
> +
>  extern int autostart;
>  
>  typedef enum {
> diff --git a/stubs/xen-hvm.c b/stubs/xen-hvm.c
> index 3ca6c51..9701feb 100644
> --- a/stubs/xen-hvm.c
> +++ b/stubs/xen-hvm.c
> @@ -13,6 +13,7 @@
>  #include "hw/xen/xen.h"
>  #include "exec/memory.h"
>  #include "qmp-commands.h"
> +#include "sysemu/sysemu.h"
>  
>  int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
>  {
> @@ -61,3 +62,7 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
> **ram_memory)
>  void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
>  {
>  }
> +
> +void xen_setup_post(void)
> +{
> +}
> diff --git a/vl.c b/vl.c
> index fb1f05b..ca06553 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4792,6 +4792,7 @@ int main(int argc, char **argv, char **envp)
>  vm_start();
>  }
>  
> +xen_setup_post();
>  os_setup_post();
>  
>  main_loop();
> -- 
> 2.1.4
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5.1 2/8] xen: restrict: use xentoolcore_restrict_all

[Stefano Stabellini]

On Fri, 20 Oct 2017, Ian Jackson wrote:
> And insist that it works.
> 
> Drop individual use of xendevicemodel_restrict and
> xenforeignmemory_restrict.  These are not actually effective in this
> version of qemu, because qemu has a large number of fds open onto
> various Xen control devices.
> 
> The restriction arrangements are still not right, because the
> restriction needs to be done very late - after qemu has opened all of
> its control fds.
> 
> xentoolcore_restrict_all and xentoolcore.h are available in Xen 4.10
> and later, only.  Provide a compatibility stub.  And drop the
> compatibility stubs for the old functions.
> 
> Signed-off-by: Ian Jackson 
> Reviewed-by: Anthony PERARD 
> ---
> v2: Modify the compatibility code, too.
> Bump this patch ahead of "defer call to xen_restrict until running"
> Retain call to xentoolcore_restrict_all
> ---
>  include/hw/xen/xen_common.h | 46 
> +++--
>  1 file changed, 11 insertions(+), 35 deletions(-)
> 
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 86c7f26..3f44a63 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -91,6 +91,16 @@ static inline void 
> *xenforeignmemory_map2(xenforeignmemory_handle *h,
>  return xenforeignmemory_map(h, dom, prot, pages, arr, err);
>  }
>  
> +static inline int xentoolcore_restrict_all(domid_t domid)
> +{
> +errno = ENOTTY;
> +return -1;

Wait, if the compat stub returns error, and this patch removed the code
to check for ENOTTY, doesn't it prevent any QEMU compiled against older
Xen from working?

Or am I missing something?


> +}
> +
> +#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 41000 */
> +
> +#include 
> +
>  #endif
>  
>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
> @@ -218,20 +228,6 @@ static inline int xendevicemodel_set_mem_type(
>  return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
>  }
>  
> -static inline int xendevicemodel_restrict(
> -xendevicemodel_handle *dmod, domid_t domid)
> -{
> -errno = ENOTTY;
> -return -1;
> -}
> -
> -static inline int xenforeignmemory_restrict(
> -xenforeignmemory_handle *fmem, domid_t domid)
> -{
> -errno = ENOTTY;
> -return -1;
> -}
> -
>  #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
>  
>  #undef XC_WANT_COMPAT_DEVICEMODEL_API
> @@ -290,28 +286,8 @@ static inline int xen_modified_memory(domid_t domid, 
> uint64_t first_pfn,
>  static inline int xen_restrict(domid_t domid)
>  {
>  int rc;
> -
> -/* Attempt to restrict devicemodel operations */
> -rc = xendevicemodel_restrict(xen_dmod, domid);
> +rc = xentoolcore_restrict_all(domid);
>  trace_xen_domid_restrict(rc ? errno : 0);
> -
> -if (rc < 0) {
> -/*
> - * If errno is ENOTTY then restriction is not implemented so
> - * there's no point in trying to restrict other types of
> - * operation, but it should not be treated as a failure.
> - */
> -if (errno == ENOTTY) {
> -return 0;
> -}
> -
> -return rc;
> -}
> -
> -/* Restrict foreignmemory operations */
> -rc = xenforeignmemory_restrict(xen_fmem, domid);
> -trace_xen_domid_restrict(rc ? errno : 0);
> -
>  return rc;
>  }
>  
> -- 
> 2.1.4
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] x86/boot: fix early error display

[Doug Goldstein]

On 10/18/17 4:50 AM, Jan Beulich wrote:
 On 17.10.17 at 23:41,  wrote:
>> From: David Esler 
>>
>> In 9180f5365524 a change was made to the send_chr function to take in
>> C-strings and print out a character at a time until a NULL was
>> encountered. However there is no code to increment the current character
>> position resulting in an endless loop of the first character. This adds
>> a simple increment.
> 
> This description is not accurate (it should have changed together with
> the change to how you fix the issue) - with VGA the increment does
> happen. Hence "display" in the title is perhaps also at least misleading.
> I would be fine to adjust both while committing (and then adding my
> R-b), but feel free to propose an alternative.

Jan,

Can you queue this for 4.9 as well? That's where we ran into the issue
in the first place.

-- 
Doug Goldstein

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

[Boris Ostrovsky]

On 10/26/2017 04:49 PM, Stefano Stabellini wrote:
> On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
>> On 10/26/2017 04:16 PM, Stefano Stabellini wrote:
>>> On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
 On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
> Also add pvcalls-front to the Makefile.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
 Reviewed-by: Boris Ostrovsky 
>>> Thank you!!
>>>
>>> The series is fully acked now. I guess it could be added to xentip?
>>> Maybe for v4.15?
>>
>> Yes, that's the plan unless other reviews come in. I will probably
>> create the branch on Monday (assuming rc7 will be the last rc for 4.14).
>> It's later than usual but we haven't had anything for 4.15.
> Great, if you are going to do that, then please also add:
>
> https://marc.info/?l=linux-kernel=150723352018341=2
>
> and don't forget to update the linux-next branch :)


This one we can take in for 4.14 --- there are a couple of patches
targeted at rc7 that I will commit tomorrow once they pass the tests but
since I can't test this one anyway (except for building) I can add it too.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

[Stefano Stabellini]

On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
> On 10/26/2017 04:16 PM, Stefano Stabellini wrote:
> > On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
> >> On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
> >>> Also add pvcalls-front to the Makefile.
> >>>
> >>> Signed-off-by: Stefano Stabellini 
> >>> CC: boris.ostrov...@oracle.com
> >>> CC: jgr...@suse.com
> >> Reviewed-by: Boris Ostrovsky 
> > Thank you!!
> >
> > The series is fully acked now. I guess it could be added to xentip?
> > Maybe for v4.15?
> 
> 
> Yes, that's the plan unless other reviews come in. I will probably
> create the branch on Monday (assuming rc7 will be the last rc for 4.14).
> It's later than usual but we haven't had anything for 4.15.

Great, if you are going to do that, then please also add:

https://marc.info/?l=linux-kernel=150723352018341=2

and don't forget to update the linux-next branch :)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Some Xen pci-passthrough questions

[Sander Eikelenboom]

Hi Boris / Andrew,

In the aftermath of the linux mmap path I have some questions regarding 
pci-passthrough:

- Is pci-passthrough in combination with an auto-ballooning dom0 supposed to be 
a supported combination ?

I have used dom0_maxmem settings for dom0 since ages and that works fine 
and stable, 
but while doing some testing around the linux mmap patch i also thought to 
try an auto-ballooning dom0.

That ended up in a crashing PV guest with pci-passthrough and a strange 
error on two HVM's with pci-passthrough,
about vcpu's (while no configurations where changed).

So if it is supported i probably have some more testing and reporting to do 
...


- While adding some extra logging and enabling the logging on xen pt in qemu,
  i wonder if it wouldn't be beneficial to have at least some basic logging 
permanently enabled ? 

- Enabling the xen pt logging in qemu spit out some things, i wonder if they 
are normal:

qemu-system-i386: -serial pty: char device redirected to /dev/pts/16 
(label serial0)
[00:05.0] xen_pt_realize: Assigning real physical device 08:00.0 to 
devfn 0x28
[00:05.0] xen_pt_register_regions: IO region 0 registered 
(size=0x2000 base_addr=0xfe1fe000 type: 0x4)

Are these somehow expected / benign (they also occur when pci passthrough 
is succesful) ?:
[00:05.0] xen_pt_config_reg_init: Offset 0x000e mismatch! 
Emulated=0x0080, host=0x, syncing to 0x0080.
[00:05.0] xen_pt_config_reg_init: Offset 0x0010 mismatch! 
Emulated=0x, host=0xfe1fe004, syncing to 0xfe1fe004.
[00:05.0] xen_pt_config_reg_init: Offset 0x0052 mismatch! 
Emulated=0x, host=0x4803, syncing to 0x0003.
[00:05.0] xen_pt_config_reg_init: Offset 0x0072 mismatch! 
Emulated=0x, host=0x0086, syncing to 0x0080.
[00:05.0] xen_pt_config_reg_init: Offset 0x00a4 mismatch! 
Emulated=0x, host=0x8fc0, syncing to 0x8fc0.
[00:05.0] xen_pt_config_reg_init: Offset 0x00b2 mismatch! 
Emulated=0x, host=0x1012, syncing to 0x1012.

[00:05.0] xen_pt_msix_init: get MSI-X table BAR base 0xfe1fe000
[00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8
[00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8, 
PCI_MSIX_ENTRY_SIZE = 0x10,  msix->table_offset_adjust = 0,  msix->table_base = 
0xfe1fe000
[00:05.0] xen_pt_msix_init: Error: Can't map physical MSI-X table: 
Invalid argument
[00:05.0] xen_pt_msix_size_init: Error: Internal error: Invalid 
xen_pt_msix_init.
Failed to initialize 12/15, type = 0x1, rc: -22
[00:05.0] xen_pt_msi_set_enable: disabling MSI.

This crash seems to indicate the above disabling of MSI isn't handled well 
enough to prevent this from happening: 
*** Error in `/usr/local/lib/xen/bin/qemu-system-i386': corrupted size 
vs. prev_size: 0x55ce13565570 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f700ab7ebcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f700ab84f96]


--
Sander

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

[Boris Ostrovsky]

On 10/26/2017 04:16 PM, Stefano Stabellini wrote:
> On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
>> On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
>>> Also add pvcalls-front to the Makefile.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>> Reviewed-by: Boris Ostrovsky 
> Thank you!!
>
> The series is fully acked now. I guess it could be added to xentip?
> Maybe for v4.15?


Yes, that's the plan unless other reviews come in. I will probably
create the branch on Monday (assuming rc7 will be the last rc for 4.14).
It's later than usual but we haven't had anything for 4.15.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

[Stefano Stabellini]

On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
> On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
> > Also add pvcalls-front to the Makefile.
> >
> > Signed-off-by: Stefano Stabellini 
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> 
> Reviewed-by: Boris Ostrovsky 

Thank you!!

The series is fully acked now. I guess it could be added to xentip?
Maybe for v4.15?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

[Andrew Cooper]

On 26/10/17 20:29, Sander Eikelenboom wrote:
> On 26/10/17 19:49, Craig Bergstrom wrote:
>> Sander, thanks for the details, they've been very useful.
>>
>> I suspect that your host system's mem=2048M parameter is causing the
>> problem.  Any chance you can confirm by removing the parameter and
>> running the guest code path?
> I removed it, but kept the hypervisor limiting dom0 memory to 2046M intact 
> (in grub using the xen bootcmd: 
> "multiboot   /xen-4.10.gz  dom0_mem=2048M,max:2048M ."
>
> Unfortunately that doesn't change anything, the guest still fails to start 
> with the same errors.
>
>> More specifically, since you're telling the kernel that it's high
>> memory address is at 2048M and your device is at 0xfe1fe000 (~4G), the
>> new mmap() limits are preventing you from mapping addresses that are
>> explicitly disallowed by the parameter.
>>
> Which would probably mean the current patch prohibits hard limiting the dom0 
> memory to a certain value (below 4G)
> at least in combination with PCI-passthrough. So the only thing left would be 
> to have no hard memory restriction on dom0
> and rely on auto-ballooning, but I'm not a great fan of that.
>
> I don't know how KVM handles setting memory limits for the host system, but 
> perhaps it suffers from the same issue.
>
> I also tried the patch from one of your last mails to make the check "less 
> strict", 
> but still get the same errors (when using the hard memory limits).

dom0_mem=2048M,max:2048M is used to describe how much RAM the guest has,
not its maximum address.  (Whether this is how PVops actually interprets
the information and passes it into Linux is a different matter.  I will
have to defer to Boris/Juergen on that side of things.)

For RAM, PV guests will get a scattering of frames wherever Xen chooses
to allocate them, and are likely to not be contiguous or adjacent.

For devices, PV guests do get mappings to the real system BARs, which
will be the real low and high MMIO holes.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

[Boris Ostrovsky]

On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
> Also add pvcalls-front to the Makefile.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com

Reviewed-by: Boris Ostrovsky 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 12/13] xen/pvcalls: implement release command

[Boris Ostrovsky]

On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
> Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
> in_mutex and out_mutex to avoid concurrent accesses. Then, free the
> socket.
>
> For passive sockets, check whether we have already pre-allocated an
> active socket for the purpose of being accepted. If so, free that as
> well.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com

Reviewed-by: Boris Ostrovsky 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 02/13] xen/pvcalls: implement frontend disconnect

[Boris Ostrovsky]

On 10/26/2017 03:11 PM, Stefano Stabellini wrote:
> Introduce a data structure named pvcalls_bedata. It contains pointers to
> the command ring, the event channel, a list of active sockets and a list
> of passive sockets. Lists accesses are protected by a spin_lock.
>
> Introduce a waitqueue to allow waiting for a response on commands sent
> to the backend.
>
> Introduce an array of struct xen_pvcalls_response to store commands
> responses.
>
> Introduce a new struct sock_mapping to keep track of sockets.  In this
> patch the struct sock_mapping is minimal, the fields will be added by
> the next patches.
>
> pvcalls_refcount is used to keep count of the outstanding pvcalls users.
> Only remove connections once the refcount is zero.
>
> Implement pvcalls frontend removal function. Go through the list of
> active and passive sockets and free them all, one at a time.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com

Reviewed-by: Boris Ostrovsky 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 115235: regressions - FAIL

[osstest service owner]

flight 115235 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115235/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 114644
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114644
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114644

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114644
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114644
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114644
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114644
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114644
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114644
 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-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-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-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 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-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  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-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-qemut-win10-i386 10 windows-install 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
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  03dd1e2a5414faf86f743ae96c2b63dbc81f27f6
baseline version:
 xen  24fb44e971a62b345c7b6ca3c03b454a1e150abe

Last test of basis   114644  2017-10-17 10:49:11 Z9 days
Failing since114670  2017-10-18 05:03:38 Z8 days   12 attempts
Testing same since   115235  2017-10-25 19:25:31 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Chao Gao 
  David Esler 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monne 
  Roger Pau Monné 
  Stefano Stabellini 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm 

Re: [Xen-devel] ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

[Sander Eikelenboom]

On 26/10/17 19:49, Craig Bergstrom wrote:
> Sander, thanks for the details, they've been very useful.
> 
> I suspect that your host system's mem=2048M parameter is causing the
> problem.  Any chance you can confirm by removing the parameter and
> running the guest code path?

I removed it, but kept the hypervisor limiting dom0 memory to 2046M intact (in 
grub using the xen bootcmd: 
"multiboot   /xen-4.10.gz  dom0_mem=2048M,max:2048M ."

Unfortunately that doesn't change anything, the guest still fails to start with 
the same errors.

> More specifically, since you're telling the kernel that it's high
> memory address is at 2048M and your device is at 0xfe1fe000 (~4G), the
> new mmap() limits are preventing you from mapping addresses that are
> explicitly disallowed by the parameter.
> 

Which would probably mean the current patch prohibits hard limiting the dom0 
memory to a certain value (below 4G)
at least in combination with PCI-passthrough. So the only thing left would be 
to have no hard memory restriction on dom0
and rely on auto-ballooning, but I'm not a great fan of that.

I don't know how KVM handles setting memory limits for the host system, but 
perhaps it suffers from the same issue.

I also tried the patch from one of your last mails to make the check "less 
strict", 
but still get the same errors (when using the hard memory limits).

--
Sander

 
> 
> On Thu, Oct 26, 2017 at 10:39 AM, Ingo Molnar  wrote:
>>
>> * Craig Bergstrom  wrote:
>>
>>> Yes, not much time left for 4.14, it might be reasonable to pull the
>>> change out since it's causing problems. [...]
>>
>> Ok, I'll queue up a revert tomorrow morning and send it to Linus ASAP if 
>> there's
>> no good fix by then. In hindsight I should have queued it for v4.15 ...
>>
>> Thanks,
>>
>> Ingo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 06/13] xen/pvcalls: implement bind command

[Stefano Stabellini]

Send PVCALLS_BIND to the backend. Introduce a new structure, part of
struct sock_mapping, to store information specific to passive sockets.

Introduce a status field to keep track of the status of the passive
socket.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 66 +
 drivers/xen/pvcalls-front.h |  3 +++
 2 files changed, 69 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 2b4c2bc..6358ae1 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -70,6 +70,13 @@ struct sock_mapping {
 
wait_queue_head_t inflight_conn_req;
} active;
+   struct {
+   /* Socket status */
+#define PVCALLS_STATUS_UNINITALIZED  0
+#define PVCALLS_STATUS_BIND  1
+#define PVCALLS_STATUS_LISTEN2
+   uint8_t status;
+   } passive;
};
 };
 
@@ -346,6 +353,65 @@ int pvcalls_front_connect(struct socket *sock, struct 
sockaddr *addr,
return ret;
 }
 
+int pvcalls_front_bind(struct socket *sock, struct sockaddr *addr, int 
addr_len)
+{
+   struct pvcalls_bedata *bedata;
+   struct sock_mapping *map = NULL;
+   struct xen_pvcalls_request *req;
+   int notify, req_id, ret;
+
+   if (addr->sa_family != AF_INET || sock->type != SOCK_STREAM)
+   return -EOPNOTSUPP;
+
+   pvcalls_enter();
+   if (!pvcalls_front_dev) {
+   pvcalls_exit();
+   return -ENOTCONN;
+   }
+   bedata = dev_get_drvdata(_front_dev->dev);
+
+   map = (struct sock_mapping *) sock->sk->sk_send_head;
+   if (map == NULL) {
+   pvcalls_exit();
+   return -ENOTSOCK;
+   }
+
+   spin_lock(>socket_lock);
+   ret = get_request(bedata, _id);
+   if (ret < 0) {
+   spin_unlock(>socket_lock);
+   pvcalls_exit();
+   return ret;
+   }
+   req = RING_GET_REQUEST(>ring, req_id);
+   req->req_id = req_id;
+   map->sock = sock;
+   req->cmd = PVCALLS_BIND;
+   req->u.bind.id = (uint64_t)map;
+   memcpy(req->u.bind.addr, addr, sizeof(*addr));
+   req->u.bind.len = addr_len;
+
+   map->active_socket = false;
+
+   bedata->ring.req_prod_pvt++;
+   RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(>ring, notify);
+   spin_unlock(>socket_lock);
+   if (notify)
+   notify_remote_via_irq(bedata->irq);
+
+   wait_event(bedata->inflight_req,
+  READ_ONCE(bedata->rsp[req_id].req_id) == req_id);
+
+   /* read req_id, then the content */
+   smp_rmb();
+   ret = bedata->rsp[req_id].ret;
+   bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
+
+   map->passive.status = PVCALLS_STATUS_BIND;
+   pvcalls_exit();
+   return 0;
+}
+
 static const struct xenbus_device_id pvcalls_front_ids[] = {
{ "pvcalls" },
{ "" }
diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
index 63b0417..8b0a274 100644
--- a/drivers/xen/pvcalls-front.h
+++ b/drivers/xen/pvcalls-front.h
@@ -6,5 +6,8 @@
 int pvcalls_front_socket(struct socket *sock);
 int pvcalls_front_connect(struct socket *sock, struct sockaddr *addr,
  int addr_len, int flags);
+int pvcalls_front_bind(struct socket *sock,
+  struct sockaddr *addr,
+  int addr_len);
 
 #endif
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 05/13] xen/pvcalls: implement connect command

[Stefano Stabellini]

Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for
the active socket.

Introduce fields in struct sock_mapping to keep track of active sockets.
Introduce a waitqueue to allow the frontend to wait on data coming from
the backend on the active socket (recvmsg command).

Two mutexes (one of reads and one for writes) will be used to protect
the active socket in and out rings from concurrent accesses.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 158 
 drivers/xen/pvcalls-front.h |   2 +
 2 files changed, 160 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 1cb1e92..2b4c2bc 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -59,6 +59,18 @@ struct sock_mapping {
bool active_socket;
struct list_head list;
struct socket *sock;
+   union {
+   struct {
+   int irq;
+   grant_ref_t ref;
+   struct pvcalls_data_intf *ring;
+   struct pvcalls_data data;
+   struct mutex in_mutex;
+   struct mutex out_mutex;
+
+   wait_queue_head_t inflight_conn_req;
+   } active;
+   };
 };
 
 static inline int get_request(struct pvcalls_bedata *bedata, int *req_id)
@@ -121,6 +133,18 @@ static void pvcalls_front_free_map(struct pvcalls_bedata 
*bedata,
 {
 }
 
+static irqreturn_t pvcalls_front_conn_handler(int irq, void *sock_map)
+{
+   struct sock_mapping *map = sock_map;
+
+   if (map == NULL)
+   return IRQ_HANDLED;
+
+   wake_up_interruptible(>active.inflight_conn_req);
+
+   return IRQ_HANDLED;
+}
+
 int pvcalls_front_socket(struct socket *sock)
 {
struct pvcalls_bedata *bedata;
@@ -196,6 +220,132 @@ int pvcalls_front_socket(struct socket *sock)
return ret;
 }
 
+static int create_active(struct sock_mapping *map, int *evtchn)
+{
+   void *bytes;
+   int ret = -ENOMEM, irq = -1, i;
+
+   *evtchn = -1;
+   init_waitqueue_head(>active.inflight_conn_req);
+
+   map->active.ring = (struct pvcalls_data_intf *)
+   __get_free_page(GFP_KERNEL | __GFP_ZERO);
+   if (map->active.ring == NULL)
+   goto out_error;
+   map->active.ring->ring_order = PVCALLS_RING_ORDER;
+   bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
+   PVCALLS_RING_ORDER);
+   if (bytes == NULL)
+   goto out_error;
+   for (i = 0; i < (1 << PVCALLS_RING_ORDER); i++)
+   map->active.ring->ref[i] = gnttab_grant_foreign_access(
+   pvcalls_front_dev->otherend_id,
+   pfn_to_gfn(virt_to_pfn(bytes) + i), 0);
+
+   map->active.ref = gnttab_grant_foreign_access(
+   pvcalls_front_dev->otherend_id,
+   pfn_to_gfn(virt_to_pfn((void *)map->active.ring)), 0);
+
+   map->active.data.in = bytes;
+   map->active.data.out = bytes +
+   XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
+
+   ret = xenbus_alloc_evtchn(pvcalls_front_dev, evtchn);
+   if (ret)
+   goto out_error;
+   irq = bind_evtchn_to_irqhandler(*evtchn, pvcalls_front_conn_handler,
+   0, "pvcalls-frontend", map);
+   if (irq < 0) {
+   ret = irq;
+   goto out_error;
+   }
+
+   map->active.irq = irq;
+   map->active_socket = true;
+   mutex_init(>active.in_mutex);
+   mutex_init(>active.out_mutex);
+
+   return 0;
+
+out_error:
+   if (irq >= 0)
+   unbind_from_irqhandler(irq, map);
+   else if (*evtchn >= 0)
+   xenbus_free_evtchn(pvcalls_front_dev, *evtchn);
+   kfree(map->active.data.in);
+   kfree(map->active.ring);
+   return ret;
+}
+
+int pvcalls_front_connect(struct socket *sock, struct sockaddr *addr,
+   int addr_len, int flags)
+{
+   struct pvcalls_bedata *bedata;
+   struct sock_mapping *map = NULL;
+   struct xen_pvcalls_request *req;
+   int notify, req_id, ret, evtchn;
+
+   if (addr->sa_family != AF_INET || sock->type != SOCK_STREAM)
+   return -EOPNOTSUPP;
+
+   pvcalls_enter();
+   if (!pvcalls_front_dev) {
+   pvcalls_exit();
+   return -ENOTCONN;
+   }
+
+   bedata = dev_get_drvdata(_front_dev->dev);
+
+   map = (struct sock_mapping *)sock->sk->sk_send_head;
+   if (!map) {
+   pvcalls_exit();
+   return -ENOTSOCK;
+   }
+
+   spin_lock(>socket_lock);
+   ret = get_request(bedata, _id);
+   if (ret < 0) {
+   spin_unlock(>socket_lock);
+   

[Xen-devel] [PATCH v7 09/13] xen/pvcalls: implement sendmsg

[Stefano Stabellini]

Send data to an active socket by copying data to the "out" ring. Take
the active socket out_mutex so that only one function can access the
ring at any given time.

If not enough room is available on the ring, rather than returning
immediately or sleep-waiting, spin for up to 5000 cycles. This small
optimization turns out to improve performance significantly.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 118 
 drivers/xen/pvcalls-front.h |   3 ++
 2 files changed, 121 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index f790abc..f0541d1 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -29,6 +29,7 @@
 #define PVCALLS_INVALID_ID UINT_MAX
 #define PVCALLS_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
 #define PVCALLS_NR_RSP_PER_RING __CONST_RING_SIZE(xen_pvcalls, XEN_PAGE_SIZE)
+#define PVCALLS_FRONT_MAX_SPIN 5000
 
 struct pvcalls_bedata {
struct xen_pvcalls_front_ring ring;
@@ -99,6 +100,23 @@ static inline int get_request(struct pvcalls_bedata 
*bedata, int *req_id)
return 0;
 }
 
+static bool pvcalls_front_write_todo(struct sock_mapping *map)
+{
+   struct pvcalls_data_intf *intf = map->active.ring;
+   RING_IDX cons, prod, size = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
+   int32_t error;
+
+   error = intf->out_error;
+   if (error == -ENOTCONN)
+   return false;
+   if (error != 0)
+   return true;
+
+   cons = intf->out_cons;
+   prod = intf->out_prod;
+   return !!(size - pvcalls_queued(prod, cons, size));
+}
+
 static irqreturn_t pvcalls_front_event_handler(int irq, void *dev_id)
 {
struct xenbus_device *dev = dev_id;
@@ -363,6 +381,106 @@ int pvcalls_front_connect(struct socket *sock, struct 
sockaddr *addr,
return ret;
 }
 
+static int __write_ring(struct pvcalls_data_intf *intf,
+   struct pvcalls_data *data,
+   struct iov_iter *msg_iter,
+   int len)
+{
+   RING_IDX cons, prod, size, masked_prod, masked_cons;
+   RING_IDX array_size = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
+   int32_t error;
+
+   error = intf->out_error;
+   if (error < 0)
+   return error;
+   cons = intf->out_cons;
+   prod = intf->out_prod;
+   /* read indexes before continuing */
+   virt_mb();
+
+   size = pvcalls_queued(prod, cons, array_size);
+   if (size >= array_size)
+   return -EINVAL;
+   if (len > array_size - size)
+   len = array_size - size;
+
+   masked_prod = pvcalls_mask(prod, array_size);
+   masked_cons = pvcalls_mask(cons, array_size);
+
+   if (masked_prod < masked_cons) {
+   copy_from_iter(data->out + masked_prod, len, msg_iter);
+   } else {
+   if (len > array_size - masked_prod) {
+   copy_from_iter(data->out + masked_prod,
+  array_size - masked_prod, msg_iter);
+   copy_from_iter(data->out,
+  len - (array_size - masked_prod),
+  msg_iter);
+   } else {
+   copy_from_iter(data->out + masked_prod, len, msg_iter);
+   }
+   }
+   /* write to ring before updating pointer */
+   virt_wmb();
+   intf->out_prod += len;
+
+   return len;
+}
+
+int pvcalls_front_sendmsg(struct socket *sock, struct msghdr *msg,
+ size_t len)
+{
+   struct pvcalls_bedata *bedata;
+   struct sock_mapping *map;
+   int sent, tot_sent = 0;
+   int count = 0, flags;
+
+   flags = msg->msg_flags;
+   if (flags & (MSG_CONFIRM|MSG_DONTROUTE|MSG_EOR|MSG_OOB))
+   return -EOPNOTSUPP;
+
+   pvcalls_enter();
+   if (!pvcalls_front_dev) {
+   pvcalls_exit();
+   return -ENOTCONN;
+   }
+   bedata = dev_get_drvdata(_front_dev->dev);
+
+   map = (struct sock_mapping *) sock->sk->sk_send_head;
+   if (!map) {
+   pvcalls_exit();
+   return -ENOTSOCK;
+   }
+
+   mutex_lock(>active.out_mutex);
+   if ((flags & MSG_DONTWAIT) && !pvcalls_front_write_todo(map)) {
+   mutex_unlock(>active.out_mutex);
+   pvcalls_exit();
+   return -EAGAIN;
+   }
+   if (len > INT_MAX)
+   len = INT_MAX;
+
+again:
+   count++;
+   sent = __write_ring(map->active.ring,
+   >active.data, >msg_iter,
+   len);
+   if (sent > 0) {
+   len -= sent;
+   tot_sent += sent;
+   notify_remote_via_irq(map->active.irq);
+   }
+   if (sent >= 

[Xen-devel] [PATCH v7 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend

[Stefano Stabellini]

Introduce a xenbus frontend for the pvcalls protocol, as defined by
https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.

This patch only adds the stubs, the code will be added by the following
patches.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 61 +
 1 file changed, 61 insertions(+)
 create mode 100644 drivers/xen/pvcalls-front.c

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
new file mode 100644
index 000..a8d38c2
--- /dev/null
+++ b/drivers/xen/pvcalls-front.c
@@ -0,0 +1,61 @@
+/*
+ * (c) 2017 Stefano Stabellini 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct xenbus_device_id pvcalls_front_ids[] = {
+   { "pvcalls" },
+   { "" }
+};
+
+static int pvcalls_front_remove(struct xenbus_device *dev)
+{
+   return 0;
+}
+
+static int pvcalls_front_probe(struct xenbus_device *dev,
+ const struct xenbus_device_id *id)
+{
+   return 0;
+}
+
+static void pvcalls_front_changed(struct xenbus_device *dev,
+   enum xenbus_state backend_state)
+{
+}
+
+static struct xenbus_driver pvcalls_front_driver = {
+   .ids = pvcalls_front_ids,
+   .probe = pvcalls_front_probe,
+   .remove = pvcalls_front_remove,
+   .otherend_changed = pvcalls_front_changed,
+};
+
+static int __init pvcalls_frontend_init(void)
+{
+   if (!xen_domain())
+   return -ENODEV;
+
+   pr_info("Initialising Xen pvcalls frontend driver\n");
+
+   return xenbus_register_frontend(_front_driver);
+}
+
+module_init(pvcalls_frontend_init);
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 07/13] xen/pvcalls: implement listen command

[Stefano Stabellini]

Send PVCALLS_LISTEN to the backend.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 57 +
 drivers/xen/pvcalls-front.h |  1 +
 2 files changed, 58 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 6358ae1..a2d876e 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -412,6 +412,63 @@ int pvcalls_front_bind(struct socket *sock, struct 
sockaddr *addr, int addr_len)
return 0;
 }
 
+int pvcalls_front_listen(struct socket *sock, int backlog)
+{
+   struct pvcalls_bedata *bedata;
+   struct sock_mapping *map;
+   struct xen_pvcalls_request *req;
+   int notify, req_id, ret;
+
+   pvcalls_enter();
+   if (!pvcalls_front_dev) {
+   pvcalls_exit();
+   return -ENOTCONN;
+   }
+   bedata = dev_get_drvdata(_front_dev->dev);
+
+   map = (struct sock_mapping *) sock->sk->sk_send_head;
+   if (!map) {
+   pvcalls_exit();
+   return -ENOTSOCK;
+   }
+
+   if (map->passive.status != PVCALLS_STATUS_BIND) {
+   pvcalls_exit();
+   return -EOPNOTSUPP;
+   }
+
+   spin_lock(>socket_lock);
+   ret = get_request(bedata, _id);
+   if (ret < 0) {
+   spin_unlock(>socket_lock);
+   pvcalls_exit();
+   return ret;
+   }
+   req = RING_GET_REQUEST(>ring, req_id);
+   req->req_id = req_id;
+   req->cmd = PVCALLS_LISTEN;
+   req->u.listen.id = (uint64_t) map;
+   req->u.listen.backlog = backlog;
+
+   bedata->ring.req_prod_pvt++;
+   RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(>ring, notify);
+   spin_unlock(>socket_lock);
+   if (notify)
+   notify_remote_via_irq(bedata->irq);
+
+   wait_event(bedata->inflight_req,
+  READ_ONCE(bedata->rsp[req_id].req_id) == req_id);
+
+   /* read req_id, then the content */
+   smp_rmb();
+   ret = bedata->rsp[req_id].ret;
+   bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
+
+   map->passive.status = PVCALLS_STATUS_LISTEN;
+   pvcalls_exit();
+   return ret;
+}
+
 static const struct xenbus_device_id pvcalls_front_ids[] = {
{ "pvcalls" },
{ "" }
diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
index 8b0a274..aa8fe10 100644
--- a/drivers/xen/pvcalls-front.h
+++ b/drivers/xen/pvcalls-front.h
@@ -9,5 +9,6 @@ int pvcalls_front_connect(struct socket *sock, struct sockaddr 
*addr,
 int pvcalls_front_bind(struct socket *sock,
   struct sockaddr *addr,
   int addr_len);
+int pvcalls_front_listen(struct socket *sock, int backlog);
 
 #endif
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

[Stefano Stabellini]

Also add pvcalls-front to the Makefile.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/Kconfig  | 11 +++
 drivers/xen/Makefile |  1 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 4545561..d8dd546 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -196,6 +196,17 @@ config XEN_PCIDEV_BACKEND
 
  If in doubt, say m.
 
+config XEN_PVCALLS_FRONTEND
+   tristate "XEN PV Calls frontend driver"
+   depends on INET && XEN
+   default n
+   select XEN_XENBUS_FRONTEND
+   help
+ Experimental frontend for the Xen PV Calls protocol
+ (https://xenbits.xen.org/docs/unstable/misc/pvcalls.html). It
+ sends a small set of POSIX calls to the backend, which
+ implements them.
+
 config XEN_PVCALLS_BACKEND
bool "XEN PV Calls backend driver"
depends on INET && XEN && XEN_BACKEND
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 480b928..afb9e03 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_XEN_EFI) += efi.o
 obj-$(CONFIG_XEN_SCSI_BACKEND) += xen-scsiback.o
 obj-$(CONFIG_XEN_AUTO_XLATE)   += xlate_mmu.o
 obj-$(CONFIG_XEN_PVCALLS_BACKEND)  += pvcalls-back.o
+obj-$(CONFIG_XEN_PVCALLS_FRONTEND) += pvcalls-front.o
 xen-evtchn-y   := evtchn.o
 xen-gntdev-y   := gntdev.o
 xen-gntalloc-y := gntalloc.o
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 02/13] xen/pvcalls: implement frontend disconnect

[Stefano Stabellini]

Introduce a data structure named pvcalls_bedata. It contains pointers to
the command ring, the event channel, a list of active sockets and a list
of passive sockets. Lists accesses are protected by a spin_lock.

Introduce a waitqueue to allow waiting for a response on commands sent
to the backend.

Introduce an array of struct xen_pvcalls_response to store commands
responses.

Introduce a new struct sock_mapping to keep track of sockets.  In this
patch the struct sock_mapping is minimal, the fields will be added by
the next patches.

pvcalls_refcount is used to keep count of the outstanding pvcalls users.
Only remove connections once the refcount is zero.

Implement pvcalls frontend removal function. Go through the list of
active and passive sockets and free them all, one at a time.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 71 +
 1 file changed, 71 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index a8d38c2..aae23d0 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -20,6 +20,51 @@
 #include 
 #include 
 
+#define PVCALLS_INVALID_ID UINT_MAX
+#define PVCALLS_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
+#define PVCALLS_NR_RSP_PER_RING __CONST_RING_SIZE(xen_pvcalls, XEN_PAGE_SIZE)
+
+struct pvcalls_bedata {
+   struct xen_pvcalls_front_ring ring;
+   grant_ref_t ref;
+   int irq;
+
+   struct list_head socket_mappings;
+   spinlock_t socket_lock;
+
+   wait_queue_head_t inflight_req;
+   struct xen_pvcalls_response rsp[PVCALLS_NR_RSP_PER_RING];
+};
+/* Only one front/back connection supported. */
+static struct xenbus_device *pvcalls_front_dev;
+static atomic_t pvcalls_refcount;
+
+/* first increment refcount, then proceed */
+#define pvcalls_enter() {   \
+   atomic_inc(_refcount);  \
+}
+
+/* first complete other operations, then decrement refcount */
+#define pvcalls_exit() {\
+   atomic_dec(_refcount);  \
+}
+
+struct sock_mapping {
+   bool active_socket;
+   struct list_head list;
+   struct socket *sock;
+};
+
+static irqreturn_t pvcalls_front_event_handler(int irq, void *dev_id)
+{
+   return IRQ_HANDLED;
+}
+
+static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
+  struct sock_mapping *map)
+{
+}
+
 static const struct xenbus_device_id pvcalls_front_ids[] = {
{ "pvcalls" },
{ "" }
@@ -27,6 +72,32 @@
 
 static int pvcalls_front_remove(struct xenbus_device *dev)
 {
+   struct pvcalls_bedata *bedata;
+   struct sock_mapping *map = NULL, *n;
+
+   bedata = dev_get_drvdata(_front_dev->dev);
+   dev_set_drvdata(>dev, NULL);
+   pvcalls_front_dev = NULL;
+   if (bedata->irq >= 0)
+   unbind_from_irqhandler(bedata->irq, dev);
+
+   smp_mb();
+   while (atomic_read(_refcount) > 0)
+   cpu_relax();
+   list_for_each_entry_safe(map, n, >socket_mappings, list) {
+   if (map->active_socket) {
+   /* No need to lock, refcount is 0 */
+   pvcalls_front_free_map(bedata, map);
+   } else {
+   list_del(>list);
+   kfree(map);
+   }
+   }
+   if (bedata->ref >= 0)
+   gnttab_end_foreign_access(bedata->ref, 0, 0);
+   kfree(bedata->ring.sring);
+   kfree(bedata);
+   xenbus_switch_state(dev, XenbusStateClosed);
return 0;
 }
 
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 04/13] xen/pvcalls: implement socket command and handle events

[Stefano Stabellini]

Send a PVCALLS_SOCKET command to the backend, use the masked
req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0
and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array
ready for the response, and there cannot be two outstanding responses
with the same req_id.

Wait for the response by waiting on the inflight_req waitqueue and
check for the req_id field in rsp[req_id]. Use atomic accesses and
barriers to read the field. Note that the barriers are simple smp
barriers (as opposed to virt barriers) because they are for internal
frontend synchronization, not frontend<->backend communication.

Once a response is received, clear the corresponding rsp slot by setting
req_id to PVCALLS_INVALID_ID. Note that PVCALLS_INVALID_ID is invalid
only from the frontend point of view. It is not part of the PVCalls
protocol.

pvcalls_front_event_handler is in charge of copying responses from the
ring to the appropriate rsp slot. It is done by copying the body of the
response first, then by copying req_id atomically. After the copies,
wake up anybody waiting on waitqueue.

socket_lock protects accesses to the ring.

Convert the pointer to sock_mapping into an uint64_t and use it as
id for the new socket to pass to the backend. The struct will be fully
initialized later on connect or bind.

sock->sk->sk_send_head is not used for ip sockets: reuse the field to
store a pointer to the struct sock_mapping corresponding to the socket.
This way, we can easily get the struct sock_mapping from the struct
socket.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 131 
 drivers/xen/pvcalls-front.h |   8 +++
 2 files changed, 139 insertions(+)
 create mode 100644 drivers/xen/pvcalls-front.h

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 1618502..1cb1e92 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -13,6 +13,10 @@
  */
 
 #include 
+#include 
+#include 
+
+#include 
 
 #include 
 #include 
@@ -20,6 +24,8 @@
 #include 
 #include 
 
+#include "pvcalls-front.h"
+
 #define PVCALLS_INVALID_ID UINT_MAX
 #define PVCALLS_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
 #define PVCALLS_NR_RSP_PER_RING __CONST_RING_SIZE(xen_pvcalls, XEN_PAGE_SIZE)
@@ -55,8 +61,58 @@ struct sock_mapping {
struct socket *sock;
 };
 
+static inline int get_request(struct pvcalls_bedata *bedata, int *req_id)
+{
+   *req_id = bedata->ring.req_prod_pvt & (RING_SIZE(>ring) - 1);
+   if (RING_FULL(>ring) ||
+   bedata->rsp[*req_id].req_id != PVCALLS_INVALID_ID)
+   return -EAGAIN;
+   return 0;
+}
+
 static irqreturn_t pvcalls_front_event_handler(int irq, void *dev_id)
 {
+   struct xenbus_device *dev = dev_id;
+   struct pvcalls_bedata *bedata;
+   struct xen_pvcalls_response *rsp;
+   uint8_t *src, *dst;
+   int req_id = 0, more = 0, done = 0;
+
+   if (dev == NULL)
+   return IRQ_HANDLED;
+
+   pvcalls_enter();
+   bedata = dev_get_drvdata(>dev);
+   if (bedata == NULL) {
+   pvcalls_exit();
+   return IRQ_HANDLED;
+   }
+
+again:
+   while (RING_HAS_UNCONSUMED_RESPONSES(>ring)) {
+   rsp = RING_GET_RESPONSE(>ring, bedata->ring.rsp_cons);
+
+   req_id = rsp->req_id;
+   dst = (uint8_t *)>rsp[req_id] + sizeof(rsp->req_id);
+   src = (uint8_t *)rsp + sizeof(rsp->req_id);
+   memcpy(dst, src, sizeof(*rsp) - sizeof(rsp->req_id));
+   /*
+* First copy the rest of the data, then req_id. It is
+* paired with the barrier when accessing bedata->rsp.
+*/
+   smp_wmb();
+   bedata->rsp[req_id].req_id = rsp->req_id;
+
+   done = 1;
+   bedata->ring.rsp_cons++;
+   }
+
+   RING_FINAL_CHECK_FOR_RESPONSES(>ring, more);
+   if (more)
+   goto again;
+   if (done)
+   wake_up(>inflight_req);
+   pvcalls_exit();
return IRQ_HANDLED;
 }
 
@@ -65,6 +121,81 @@ static void pvcalls_front_free_map(struct pvcalls_bedata 
*bedata,
 {
 }
 
+int pvcalls_front_socket(struct socket *sock)
+{
+   struct pvcalls_bedata *bedata;
+   struct sock_mapping *map = NULL;
+   struct xen_pvcalls_request *req;
+   int notify, req_id, ret;
+
+   /*
+* PVCalls only supports domain AF_INET,
+* type SOCK_STREAM and protocol 0 sockets for now.
+*
+* Check socket type here, AF_INET and protocol checks are done
+* by the caller.
+*/
+   if (sock->type != SOCK_STREAM)
+   return -EOPNOTSUPP;
+
+   pvcalls_enter();
+   if (!pvcalls_front_dev) {
+   pvcalls_exit();
+   return -EACCES;
+   }
+

[Xen-devel] [PATCH v7 11/13] xen/pvcalls: implement poll command

[Stefano Stabellini]

For active sockets, check the indexes and use the inflight_conn_req
waitqueue to wait.

For passive sockets if an accept is outstanding
(PVCALLS_FLAG_ACCEPT_INFLIGHT), check if it has been answered by looking
at bedata->rsp[req_id]. If so, return POLLIN.  Otherwise use the
inflight_accept_req waitqueue.

If no accepts are inflight, send PVCALLS_POLL to the backend. If we have
outstanding POLL requests awaiting for a response use the inflight_req
waitqueue: inflight_req is awaken when a new response is received; on
wakeup we check whether the POLL response is arrived by looking at the
PVCALLS_FLAG_POLL_RET flag. We set the flag from
pvcalls_front_event_handler, if the response was for a POLL command.

In pvcalls_front_event_handler, get the struct sock_mapping from the
poll id (we previously converted struct sock_mapping* to uint64_t and
used it as id).

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 144 +---
 drivers/xen/pvcalls-front.h |   3 +
 2 files changed, 138 insertions(+), 9 deletions(-)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 9a505cb..eab70ce 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -83,6 +83,8 @@ struct sock_mapping {
 * Only one poll operation can be inflight for a given socket.
 */
 #define PVCALLS_FLAG_ACCEPT_INFLIGHT 0
+#define PVCALLS_FLAG_POLL_INFLIGHT   1
+#define PVCALLS_FLAG_POLL_RET2
uint8_t flags;
uint32_t inflight_req_id;
struct sock_mapping *accept_map;
@@ -154,15 +156,32 @@ static irqreturn_t pvcalls_front_event_handler(int irq, 
void *dev_id)
rsp = RING_GET_RESPONSE(>ring, bedata->ring.rsp_cons);
 
req_id = rsp->req_id;
-   dst = (uint8_t *)>rsp[req_id] + sizeof(rsp->req_id);
-   src = (uint8_t *)rsp + sizeof(rsp->req_id);
-   memcpy(dst, src, sizeof(*rsp) - sizeof(rsp->req_id));
-   /*
-* First copy the rest of the data, then req_id. It is
-* paired with the barrier when accessing bedata->rsp.
-*/
-   smp_wmb();
-   bedata->rsp[req_id].req_id = rsp->req_id;
+   if (rsp->cmd == PVCALLS_POLL) {
+   struct sock_mapping *map = (struct sock_mapping *)
+  rsp->u.poll.id;
+
+   clear_bit(PVCALLS_FLAG_POLL_INFLIGHT,
+ (void *)>passive.flags);
+   /*
+* clear INFLIGHT, then set RET. It pairs with
+* the checks at the beginning of
+* pvcalls_front_poll_passive.
+*/
+   smp_wmb();
+   set_bit(PVCALLS_FLAG_POLL_RET,
+   (void *)>passive.flags);
+   } else {
+   dst = (uint8_t *)>rsp[req_id] +
+ sizeof(rsp->req_id);
+   src = (uint8_t *)rsp + sizeof(rsp->req_id);
+   memcpy(dst, src, sizeof(*rsp) - sizeof(rsp->req_id));
+   /*
+* First copy the rest of the data, then req_id. It is
+* paired with the barrier when accessing bedata->rsp.
+*/
+   smp_wmb();
+   bedata->rsp[req_id].req_id = req_id;
+   }
 
done = 1;
bedata->ring.rsp_cons++;
@@ -840,6 +859,113 @@ int pvcalls_front_accept(struct socket *sock, struct 
socket *newsock, int flags)
return ret;
 }
 
+static unsigned int pvcalls_front_poll_passive(struct file *file,
+  struct pvcalls_bedata *bedata,
+  struct sock_mapping *map,
+  poll_table *wait)
+{
+   int notify, req_id, ret;
+   struct xen_pvcalls_request *req;
+
+   if (test_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
+(void *)>passive.flags)) {
+   uint32_t req_id = READ_ONCE(map->passive.inflight_req_id);
+
+   if (req_id != PVCALLS_INVALID_ID &&
+   READ_ONCE(bedata->rsp[req_id].req_id) == req_id)
+   return POLLIN | POLLRDNORM;
+
+   poll_wait(file, >passive.inflight_accept_req, wait);
+   return 0;
+   }
+
+   if (test_and_clear_bit(PVCALLS_FLAG_POLL_RET,
+  (void *)>passive.flags))
+   return POLLIN | POLLRDNORM;
+
+   /*
+* First check RET, then INFLIGHT. No barriers 

[Xen-devel] [PATCH v7 00/13] introduce the Xen PV Calls frontend

[Stefano Stabellini]

Hi all,

this series introduces the frontend for the newly introduced PV Calls
procotol.

PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them and
returns a value to the frontend and acts on the function call.

For more information about PV Calls, please read:

https://xenbits.xen.org/docs/unstable/misc/pvcalls.html

This patch series only implements the frontend driver. It doesn't
attempt to redirect POSIX calls to it. The functions exported in
pvcalls-front.h are meant to be used for that. A separate patch series
will be sent to use them and hook them into the system.


Changes in v7:
- define sock_mapping earlier
- make sure that every patch in the series builds
- call pvcalls_front_free_map(map->passive.accept_map) without the
  socket_lock
- remove now unused bool lock parameter to pvcalls_front_free_map
- XEN_PVCALLS_FRONTEND: default n and select XEN_XENBUS_FRONTEND


Stefano Stabellini (13):
  xen/pvcalls: introduce the pvcalls xenbus frontend
  xen/pvcalls: implement frontend disconnect
  xen/pvcalls: connect to the backend
  xen/pvcalls: implement socket command and handle events
  xen/pvcalls: implement connect command
  xen/pvcalls: implement bind command
  xen/pvcalls: implement listen command
  xen/pvcalls: implement accept command
  xen/pvcalls: implement sendmsg
  xen/pvcalls: implement recvmsg
  xen/pvcalls: implement poll command
  xen/pvcalls: implement release command
  xen: introduce a Kconfig option to enable the pvcalls frontend

 drivers/xen/Kconfig |   11 +
 drivers/xen/Makefile|1 +
 drivers/xen/pvcalls-front.c | 1271 +++
 drivers/xen/pvcalls-front.h |   28 +
 4 files changed, 1311 insertions(+)
 create mode 100644 drivers/xen/pvcalls-front.c
 create mode 100644 drivers/xen/pvcalls-front.h

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 10/13] xen/pvcalls: implement recvmsg

[Stefano Stabellini]

Implement recvmsg by copying data from the "in" ring. If not enough data
is available and the recvmsg call is blocking, then wait on the
inflight_conn_req waitqueue. Take the active socket in_mutex so that
only one function can access the ring at any given time.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 108 
 drivers/xen/pvcalls-front.h |   4 ++
 2 files changed, 112 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index f0541d1..9a505cb 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -117,6 +117,20 @@ static bool pvcalls_front_write_todo(struct sock_mapping 
*map)
return !!(size - pvcalls_queued(prod, cons, size));
 }
 
+static bool pvcalls_front_read_todo(struct sock_mapping *map)
+{
+   struct pvcalls_data_intf *intf = map->active.ring;
+   RING_IDX cons, prod;
+   int32_t error;
+
+   cons = intf->in_cons;
+   prod = intf->in_prod;
+   error = intf->in_error;
+   return (error != 0 ||
+   pvcalls_queued(prod, cons,
+  XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER)) != 0);
+}
+
 static irqreturn_t pvcalls_front_event_handler(int irq, void *dev_id)
 {
struct xenbus_device *dev = dev_id;
@@ -481,6 +495,100 @@ int pvcalls_front_sendmsg(struct socket *sock, struct 
msghdr *msg,
return tot_sent;
 }
 
+static int __read_ring(struct pvcalls_data_intf *intf,
+  struct pvcalls_data *data,
+  struct iov_iter *msg_iter,
+  size_t len, int flags)
+{
+   RING_IDX cons, prod, size, masked_prod, masked_cons;
+   RING_IDX array_size = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
+   int32_t error;
+
+   cons = intf->in_cons;
+   prod = intf->in_prod;
+   error = intf->in_error;
+   /* get pointers before reading from the ring */
+   virt_rmb();
+   if (error < 0)
+   return error;
+
+   size = pvcalls_queued(prod, cons, array_size);
+   masked_prod = pvcalls_mask(prod, array_size);
+   masked_cons = pvcalls_mask(cons, array_size);
+
+   if (size == 0)
+   return 0;
+
+   if (len > size)
+   len = size;
+
+   if (masked_prod > masked_cons) {
+   copy_to_iter(data->in + masked_cons, len, msg_iter);
+   } else {
+   if (len > (array_size - masked_cons)) {
+   copy_to_iter(data->in + masked_cons,
+array_size - masked_cons, msg_iter);
+   copy_to_iter(data->in,
+len - (array_size - masked_cons),
+msg_iter);
+   } else {
+   copy_to_iter(data->in + masked_cons, len, msg_iter);
+   }
+   }
+   /* read data from the ring before increasing the index */
+   virt_mb();
+   if (!(flags & MSG_PEEK))
+   intf->in_cons += len;
+
+   return len;
+}
+
+int pvcalls_front_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
+int flags)
+{
+   struct pvcalls_bedata *bedata;
+   int ret;
+   struct sock_mapping *map;
+
+   if (flags & (MSG_CMSG_CLOEXEC|MSG_ERRQUEUE|MSG_OOB|MSG_TRUNC))
+   return -EOPNOTSUPP;
+
+   pvcalls_enter();
+   if (!pvcalls_front_dev) {
+   pvcalls_exit();
+   return -ENOTCONN;
+   }
+   bedata = dev_get_drvdata(_front_dev->dev);
+
+   map = (struct sock_mapping *) sock->sk->sk_send_head;
+   if (!map) {
+   pvcalls_exit();
+   return -ENOTSOCK;
+   }
+
+   mutex_lock(>active.in_mutex);
+   if (len > XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER))
+   len = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
+
+   while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
+   wait_event_interruptible(map->active.inflight_conn_req,
+pvcalls_front_read_todo(map));
+   }
+   ret = __read_ring(map->active.ring, >active.data,
+ >msg_iter, len, flags);
+
+   if (ret > 0)
+   notify_remote_via_irq(map->active.irq);
+   if (ret == 0)
+   ret = (flags & MSG_DONTWAIT) ? -EAGAIN : 0;
+   if (ret == -ENOTCONN)
+   ret = 0;
+
+   mutex_unlock(>active.in_mutex);
+   pvcalls_exit();
+   return ret;
+}
+
 int pvcalls_front_bind(struct socket *sock, struct sockaddr *addr, int 
addr_len)
 {
struct pvcalls_bedata *bedata;
diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
index d937c24..de24041 100644
--- a/drivers/xen/pvcalls-front.h
+++ b/drivers/xen/pvcalls-front.h
@@ -16,5 

[Xen-devel] [PATCH v7 12/13] xen/pvcalls: implement release command

[Stefano Stabellini]

Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
in_mutex and out_mutex to avoid concurrent accesses. Then, free the
socket.

For passive sockets, check whether we have already pre-allocated an
active socket for the purpose of being accepted. If so, free that as
well.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 98 +
 drivers/xen/pvcalls-front.h |  1 +
 2 files changed, 99 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index eab70ce..8e7426083 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -199,6 +199,21 @@ static irqreturn_t pvcalls_front_event_handler(int irq, 
void *dev_id)
 static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
   struct sock_mapping *map)
 {
+   int i;
+
+   unbind_from_irqhandler(map->active.irq, map);
+
+   spin_lock(>socket_lock);
+   if (!list_empty(>list))
+   list_del_init(>list);
+   spin_unlock(>socket_lock);
+
+   for (i = 0; i < (1 << PVCALLS_RING_ORDER); i++)
+   gnttab_end_foreign_access(map->active.ring->ref[i], 0, 0);
+   gnttab_end_foreign_access(map->active.ref, 0, 0);
+   free_page((unsigned long)map->active.ring);
+
+   kfree(map);
 }
 
 static irqreturn_t pvcalls_front_conn_handler(int irq, void *sock_map)
@@ -966,6 +981,89 @@ unsigned int pvcalls_front_poll(struct file *file, struct 
socket *sock,
return ret;
 }
 
+int pvcalls_front_release(struct socket *sock)
+{
+   struct pvcalls_bedata *bedata;
+   struct sock_mapping *map;
+   int req_id, notify, ret;
+   struct xen_pvcalls_request *req;
+
+   if (sock->sk == NULL)
+   return 0;
+
+   pvcalls_enter();
+   if (!pvcalls_front_dev) {
+   pvcalls_exit();
+   return -EIO;
+   }
+
+   bedata = dev_get_drvdata(_front_dev->dev);
+
+   map = (struct sock_mapping *) sock->sk->sk_send_head;
+   if (map == NULL) {
+   pvcalls_exit();
+   return 0;
+   }
+
+   spin_lock(>socket_lock);
+   ret = get_request(bedata, _id);
+   if (ret < 0) {
+   spin_unlock(>socket_lock);
+   pvcalls_exit();
+   return ret;
+   }
+   sock->sk->sk_send_head = NULL;
+
+   req = RING_GET_REQUEST(>ring, req_id);
+   req->req_id = req_id;
+   req->cmd = PVCALLS_RELEASE;
+   req->u.release.id = (uint64_t)map;
+
+   bedata->ring.req_prod_pvt++;
+   RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(>ring, notify);
+   spin_unlock(>socket_lock);
+   if (notify)
+   notify_remote_via_irq(bedata->irq);
+
+   wait_event(bedata->inflight_req,
+  READ_ONCE(bedata->rsp[req_id].req_id) == req_id);
+
+   if (map->active_socket) {
+   /*
+* Set in_error and wake up inflight_conn_req to force
+* recvmsg waiters to exit.
+*/
+   map->active.ring->in_error = -EBADF;
+   wake_up_interruptible(>active.inflight_conn_req);
+
+   /*
+* Wait until there are no more waiters on the mutexes.
+* We know that no new waiters can be added because sk_send_head
+* is set to NULL -- we only need to wait for the existing
+* waiters to return.
+*/
+   while (!mutex_trylock(>active.in_mutex) ||
+  !mutex_trylock(>active.out_mutex))
+   cpu_relax();
+
+   pvcalls_front_free_map(bedata, map);
+   } else {
+   spin_lock(>socket_lock);
+   list_del(>list);
+   spin_unlock(>socket_lock);
+   if (READ_ONCE(map->passive.inflight_req_id) !=
+   PVCALLS_INVALID_ID) {
+   pvcalls_front_free_map(bedata,
+  map->passive.accept_map);
+   }
+   kfree(map);
+   }
+   WRITE_ONCE(bedata->rsp[req_id].req_id, PVCALLS_INVALID_ID);
+
+   pvcalls_exit();
+   return 0;
+}
+
 static const struct xenbus_device_id pvcalls_front_ids[] = {
{ "pvcalls" },
{ "" }
diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
index 25e05b8..3332978 100644
--- a/drivers/xen/pvcalls-front.h
+++ b/drivers/xen/pvcalls-front.h
@@ -23,5 +23,6 @@ int pvcalls_front_recvmsg(struct socket *sock,
 unsigned int pvcalls_front_poll(struct file *file,
struct socket *sock,
poll_table *wait);
+int pvcalls_front_release(struct socket *sock);
 
 #endif
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [PATCH v7 08/13] xen/pvcalls: implement accept command

[Stefano Stabellini]

Introduce a waitqueue to allow only one outstanding accept command at
any given time and to implement polling on the passive socket. Introduce
a flags field to keep track of in-flight accept and poll commands.

Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make
sure that only one accept command is executed at any given time by
setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on the
inflight_accept_req waitqueue.

Convert the new struct sock_mapping pointer into an uint64_t and use it
as id for the new socket to pass to the backend.

Check if the accept call is non-blocking: in that case after sending the
ACCEPT command to the backend store the sock_mapping pointer of the new
struct and the inflight req_id then return -EAGAIN (which will respond
only when there is something to accept). Next time accept is called,
we'll check if the ACCEPT command has been answered, if so we'll pick up
where we left off, otherwise we return -EAGAIN again.

Note that, differently from the other commands, we can use
wait_event_interruptible (instead of wait_event) in the case of accept
as we are able to track the req_id of the ACCEPT response that we are
waiting.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 145 
 drivers/xen/pvcalls-front.h |   3 +
 2 files changed, 148 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index a2d876e..f790abc 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -76,6 +76,16 @@ struct sock_mapping {
 #define PVCALLS_STATUS_BIND  1
 #define PVCALLS_STATUS_LISTEN2
uint8_t status;
+   /*
+* Internal state-machine flags.
+* Only one accept operation can be inflight for a socket.
+* Only one poll operation can be inflight for a given socket.
+*/
+#define PVCALLS_FLAG_ACCEPT_INFLIGHT 0
+   uint8_t flags;
+   uint32_t inflight_req_id;
+   struct sock_mapping *accept_map;
+   wait_queue_head_t inflight_accept_req;
} passive;
};
 };
@@ -391,6 +401,8 @@ int pvcalls_front_bind(struct socket *sock, struct sockaddr 
*addr, int addr_len)
memcpy(req->u.bind.addr, addr, sizeof(*addr));
req->u.bind.len = addr_len;
 
+   init_waitqueue_head(>passive.inflight_accept_req);
+
map->active_socket = false;
 
bedata->ring.req_prod_pvt++;
@@ -469,6 +481,139 @@ int pvcalls_front_listen(struct socket *sock, int backlog)
return ret;
 }
 
+int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int 
flags)
+{
+   struct pvcalls_bedata *bedata;
+   struct sock_mapping *map;
+   struct sock_mapping *map2 = NULL;
+   struct xen_pvcalls_request *req;
+   int notify, req_id, ret, evtchn, nonblock;
+
+   pvcalls_enter();
+   if (!pvcalls_front_dev) {
+   pvcalls_exit();
+   return -ENOTCONN;
+   }
+   bedata = dev_get_drvdata(_front_dev->dev);
+
+   map = (struct sock_mapping *) sock->sk->sk_send_head;
+   if (!map) {
+   pvcalls_exit();
+   return -ENOTSOCK;
+   }
+
+   if (map->passive.status != PVCALLS_STATUS_LISTEN) {
+   pvcalls_exit();
+   return -EINVAL;
+   }
+
+   nonblock = flags & SOCK_NONBLOCK;
+   /*
+* Backend only supports 1 inflight accept request, will return
+* errors for the others
+*/
+   if (test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
+(void *)>passive.flags)) {
+   req_id = READ_ONCE(map->passive.inflight_req_id);
+   if (req_id != PVCALLS_INVALID_ID &&
+   READ_ONCE(bedata->rsp[req_id].req_id) == req_id) {
+   map2 = map->passive.accept_map;
+   goto received;
+   }
+   if (nonblock) {
+   pvcalls_exit();
+   return -EAGAIN;
+   }
+   if (wait_event_interruptible(map->passive.inflight_accept_req,
+   !test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
+ (void *)>passive.flags))) {
+   pvcalls_exit();
+   return -EINTR;
+   }
+   }
+
+   spin_lock(>socket_lock);
+   ret = get_request(bedata, _id);
+   if (ret < 0) {
+   clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
+ (void *)>passive.flags);
+   spin_unlock(>socket_lock);
+   pvcalls_exit();
+   return ret;
+   }
+   map2 = kzalloc(sizeof(*map2), GFP_KERNEL);

[Xen-devel] [PATCH v7 03/13] xen/pvcalls: connect to the backend

[Stefano Stabellini]

Implement the probe function for the pvcalls frontend. Read the
supported versions, max-page-order and function-calls nodes from
xenstore.

Only one frontend<->backend connection is supported at any given time
for a guest. Store the active frontend device to a static pointer.

Introduce a stub functions for the event handler.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 132 
 1 file changed, 132 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index aae23d0..1618502 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -104,12 +104,144 @@ static int pvcalls_front_remove(struct xenbus_device 
*dev)
 static int pvcalls_front_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
 {
+   int ret = -ENOMEM, evtchn, i;
+   unsigned int max_page_order, function_calls, len;
+   char *versions;
+   grant_ref_t gref_head = 0;
+   struct xenbus_transaction xbt;
+   struct pvcalls_bedata *bedata = NULL;
+   struct xen_pvcalls_sring *sring;
+
+   if (pvcalls_front_dev != NULL) {
+   dev_err(>dev, "only one PV Calls connection supported\n");
+   return -EINVAL;
+   }
+
+   versions = xenbus_read(XBT_NIL, dev->otherend, "versions", );
+   if (!len)
+   return -EINVAL;
+   if (strcmp(versions, "1")) {
+   kfree(versions);
+   return -EINVAL;
+   }
+   kfree(versions);
+   max_page_order = xenbus_read_unsigned(dev->otherend,
+ "max-page-order", 0);
+   if (max_page_order < PVCALLS_RING_ORDER)
+   return -ENODEV;
+   function_calls = xenbus_read_unsigned(dev->otherend,
+ "function-calls", 0);
+   /* See XENBUS_FUNCTIONS_CALLS in pvcalls.h */
+   if (function_calls != 1)
+   return -ENODEV;
+   pr_info("%s max-page-order is %u\n", __func__, max_page_order);
+
+   bedata = kzalloc(sizeof(struct pvcalls_bedata), GFP_KERNEL);
+   if (!bedata)
+   return -ENOMEM;
+
+   dev_set_drvdata(>dev, bedata);
+   pvcalls_front_dev = dev;
+   init_waitqueue_head(>inflight_req);
+   INIT_LIST_HEAD(>socket_mappings);
+   spin_lock_init(>socket_lock);
+   bedata->irq = -1;
+   bedata->ref = -1;
+
+   for (i = 0; i < PVCALLS_NR_RSP_PER_RING; i++)
+   bedata->rsp[i].req_id = PVCALLS_INVALID_ID;
+
+   sring = (struct xen_pvcalls_sring *) __get_free_page(GFP_KERNEL |
+__GFP_ZERO);
+   if (!sring)
+   goto error;
+   SHARED_RING_INIT(sring);
+   FRONT_RING_INIT(>ring, sring, XEN_PAGE_SIZE);
+
+   ret = xenbus_alloc_evtchn(dev, );
+   if (ret)
+   goto error;
+
+   bedata->irq = bind_evtchn_to_irqhandler(evtchn,
+   pvcalls_front_event_handler,
+   0, "pvcalls-frontend", dev);
+   if (bedata->irq < 0) {
+   ret = bedata->irq;
+   goto error;
+   }
+
+   ret = gnttab_alloc_grant_references(1, _head);
+   if (ret < 0)
+   goto error;
+   bedata->ref = gnttab_claim_grant_reference(_head);
+   if (bedata->ref < 0) {
+   ret = bedata->ref;
+   goto error;
+   }
+   gnttab_grant_foreign_access_ref(bedata->ref, dev->otherend_id,
+   virt_to_gfn((void *)sring), 0);
+
+ again:
+   ret = xenbus_transaction_start();
+   if (ret) {
+   xenbus_dev_fatal(dev, ret, "starting transaction");
+   goto error;
+   }
+   ret = xenbus_printf(xbt, dev->nodename, "version", "%u", 1);
+   if (ret)
+   goto error_xenbus;
+   ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", bedata->ref);
+   if (ret)
+   goto error_xenbus;
+   ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
+   evtchn);
+   if (ret)
+   goto error_xenbus;
+   ret = xenbus_transaction_end(xbt, 0);
+   if (ret) {
+   if (ret == -EAGAIN)
+   goto again;
+   xenbus_dev_fatal(dev, ret, "completing transaction");
+   goto error;
+   }
+   xenbus_switch_state(dev, XenbusStateInitialised);
+
return 0;
+
+ error_xenbus:
+   xenbus_transaction_end(xbt, 1);
+   xenbus_dev_fatal(dev, ret, "writing xenstore");
+ error:
+   pvcalls_front_remove(dev);
+   return ret;
 }
 
 static void pvcalls_front_changed(struct xenbus_device *dev,
enum 

[Xen-devel] [xen-4.8-testing baseline-only test] 72353: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72353 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72353/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt  5 host-ping-check-nativefail REGR. vs. 72333
 test-amd64-i386-freebsd10-amd64 11 guest-startfail REGR. vs. 72333
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 14 guest-localmigrate fail REGR. 
vs. 72333
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail REGR. vs. 
72333
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 72333

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 72333
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 72333
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 72333
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 test-amd64-amd64-xl-pvh-intel 12 guest-start  fail  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-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 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-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop  fail never pass
 

Re: [Xen-devel] [PATCH v6 12/13] xen/pvcalls: implement release command

[Stefano Stabellini]

On Thu, 26 Oct 2017, Boris Ostrovsky wrote:
> On 10/25/2017 07:00 PM, Stefano Stabellini wrote:
> > On Wed, 25 Oct 2017, Boris Ostrovsky wrote:
> >> On 10/24/2017 01:33 PM, Stefano Stabellini wrote:
> >>> Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
> >>> in_mutex and out_mutex to avoid concurrent accesses. Then, free the
> >>> socket.
> >>>
> >>> For passive sockets, check whether we have already pre-allocated an
> >>> active socket for the purpose of being accepted. If so, free that as
> >>> well.
> >>>
> >>> Signed-off-by: Stefano Stabellini 
> >>> CC: boris.ostrov...@oracle.com
> >>> CC: jgr...@suse.com
> >>> ---
> >>>  drivers/xen/pvcalls-front.c | 100 
> >>> 
> >>>  drivers/xen/pvcalls-front.h |   1 +
> >>>  2 files changed, 101 insertions(+)
> >>>
> >>> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> >>> index 4a413ff..7abc039 100644
> >>> --- a/drivers/xen/pvcalls-front.c
> >>> +++ b/drivers/xen/pvcalls-front.c
> >>> @@ -199,6 +199,23 @@ static irqreturn_t pvcalls_front_event_handler(int 
> >>> irq, void *dev_id)
> >>>  static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
> >>>  struct sock_mapping *map, bool locked)
> >>>  {
> >>> + int i;
> >>> +
> >>> + unbind_from_irqhandler(map->active.irq, map);
> >>> +
> >>> + if (!locked)
> >>> + spin_lock(>socket_lock);
> >>> + if (!list_empty(>list))
> >>> + list_del_init(>list);
> >>> + if (!locked)
> >>> + spin_unlock(>socket_lock);
> >>> +
> >>> + for (i = 0; i < (1 << PVCALLS_RING_ORDER); i++)
> >>> + gnttab_end_foreign_access(map->active.ring->ref[i], 0, 0);
> >>> + gnttab_end_foreign_access(map->active.ref, 0, 0);
> >>> + free_page((unsigned long)map->active.ring);
> >>> +
> >>> + kfree(map);
> >>>  }
> >>>  
> >>>  static irqreturn_t pvcalls_front_conn_handler(int irq, void *sock_map)
> >>> @@ -966,6 +983,89 @@ unsigned int pvcalls_front_poll(struct file *file, 
> >>> struct socket *sock,
> >>>   return ret;
> >>>  }
> >>>  
> >>> +int pvcalls_front_release(struct socket *sock)
> >>> +{
> >>> + struct pvcalls_bedata *bedata;
> >>> + struct sock_mapping *map;
> >>> + int req_id, notify, ret;
> >>> + struct xen_pvcalls_request *req;
> >>> +
> >> ..
> >>
> >>> +
> >>> + if (map->active_socket) {
> >>> + /*
> >>> +  * Set in_error and wake up inflight_conn_req to force
> >>> +  * recvmsg waiters to exit.
> >>> +  */
> >>> + map->active.ring->in_error = -EBADF;
> >>> + wake_up_interruptible(>active.inflight_conn_req);
> >>> +
> >>> + /*
> >>> +  * Wait until there are no more waiters on the mutexes.
> >>> +  * We know that no new waiters can be added because sk_send_head
> >>> +  * is set to NULL -- we only need to wait for the existing
> >>> +  * waiters to return.
> >>> +  */
> >>> + while (!mutex_trylock(>active.in_mutex) ||
> >>> +!mutex_trylock(>active.out_mutex))
> >>> + cpu_relax();
> >>> +
> >>> + pvcalls_front_free_map(bedata, map, false);
> >>> + } else {
> >>> + spin_lock(>socket_lock);
> >>> + if (READ_ONCE(map->passive.inflight_req_id) !=
> >>> + PVCALLS_INVALID_ID) {
> >>> + pvcalls_front_free_map(bedata,
> >>> +map->passive.accept_map, true);
> >>> + }
> >>> + list_del(>list);
> >>> + kfree(map);
> >>> + spin_unlock(>socket_lock);
> >> We have different locking rules in pvcalls_front_free_map() for each of
> >> those clauses in that in the first case we are doing grant table
> >> operations and free_page() without the lock and in the second case we
> >> are holding it. Is it possible to restructure this so that we prune the
> >> lists under the lock (possibly in this routine) and call
> >> pvcalls_front_free_map() lock-less?
> > Yes, it is possible. However, pvcalls_front_free_map is called from a
> > couple of other places (pvcalls_front_accept and pvcalls_front_remove)
> > and we would have to add the code to remove the map from the list there
> > as well. I am not sure it is worth it.
> >
> > I don't have a strong opinion on this. Let me know which way you prefer.
> 
> 
> I didn't realize this is called from multiple places.
> 
> How about
> 
> spin_lock(>socket_lock);
> if (READ_ONCE(map->passive.inflight_req_id) !=
> PVCALLS_INVALID_ID) {
>if (!list_empty(>passive.accept_map->list))
>   list_del(>passive.accept_map->list);
> }
> list_del(>list);
> spin_unlock(>socket_lock);
> 
> pvcalls_front_free_map(bedata, map->passive.accept_map, true);
> kfree(map); 
> 
> 
> (I may have messed up list pointers here)
> 
> This would be slightly inefficient in that you drop the lock and then grab it 
> again (only to find that the list is empty, presumably) but it makes 
> 

[Xen-devel] [distros-debian-wheezy test] 72354: tolerable trouble: broken/pass

[Platform Team regression test user]

flight 72354 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72354/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 build-arm64   2 hosts-allocate   broken like 72331
 build-arm64-pvops 2 hosts-allocate   broken like 72331
 build-arm64   3 capture-logs broken like 72331
 build-arm64-pvops 3 capture-logs broken like 72331

baseline version:
 flight   72331

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-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  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.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/9] x86/vvmx: Read instruction operands correctly on VM exit

[Andrew Cooper]

On 26/10/17 18:03, Euan Harris wrote:
> decode_vmx_inst() does not read instruction operands correctly on VM exit:
>
>  * It incorrectly uses vmx_inst_info's address_size field to calculate
>the sizes of the exit-causing instruction's operands.  The sizes of
>the operands are specified in the SDM and might depend on whether the
>guest is running in 32-bit or 64-bit mode, but they have nothing to do
>with the address_size field.
>
>  * It includes its own segmentation logic, duplicating code elsewhere.
>This segmentation logic is also incorrect and will raise #GP fault
>rather than a #SS fault in response to an invalid memory access
>through the stack segment.
>  
> Patches 1-6 (up to 'Remove operand decoding from decode_vmx_inst()')
> refactor decode_vmx_inst() in preparation for fixing the bugs mentioned
> above.  They remove unnecessary code and extract the logic for reading
> operands from decode_vmx_inst() into a new operand_read() function.
> These patches should not cause any functional changes.
>
> Patch 7 ('Use correct sizes when reading operands') replaces the incorrect
> operand size calculations based on address_size with the correct sizes
> from the SDM.
>
> Patches 8 and 9 add new hvm_copy_{to,from}_guest_virt() helpers and use
> them to read memory operands in place of the incorrect segmentation
> logic in decode_vmx_inst().
>
> Euan Harris (9):
>   x86/vvmx: Remove enum vmx_regs_enc
>   x86/vvmx: Unify operands in struct vmx_inst_decoded
>   x86/vvmx: Extract operand reading logic into operand_read()
>   x86/vvmx: Remove unnecessary VMX operand reads
>   x86/vvmx: Replace direct calls to reg_read() with operand_read()
>   x86/vvmx: Remove operand reading from decode_vmx_inst()
>   x86/vvmx: Use correct sizes when reading operands
>   x86/hvm: Add hvm_copy_{to,from}_guest_virt() helpers
>   x86/vvmx: Use hvm_copy_{to,from}_guest_virt() to read operands

All Reviewed-by: Andrew Cooper .  I've
noticed a few trivial style issues which can be fixed up on commit if
there are no other issues.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Is that possible to merge MBA into Xen 4.10?

[Roger Pau Monné]

On Tue, Oct 24, 2017 at 10:10:14AM +0800, Yi Sun wrote:
> Hi, all,
> 
> As you may know, MBA patch set has got enough Reviewed-by/Acked-by in last 
> week.
> It is ready to be merged. 
> 
> This is a feature for Skylake, Intel has launched Skylake and KVM already
> supported MBA, so including it in Xen 4.10 will quickly fill this gap.
> 
> MBA missed the 4.10 feature freeze date for only a few days due to lack of
> timely review for earlier versions which slowed down the patch iteration 
> notably.
> It seems maintainers are very busy recently so that the review progress for 
> 4.10
> is slower than before. So I am wondering if it is possible to merge it into 
> 4.10?
> 
> This patch set mainly touches codes related to PSR in 
> tools/domctl/sysctl/hypervisor.
> It does not touch other features. So, the risk is low to merge it.

I agree that the risk is low, code is limited to PSR related bits, and
IIRC doesn't touch common code.

The main risk here would be breaking other Intel PSR features already
committed, but I guess Intel has made sure this new feature doesn't
break existing functionality.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

[Olaf Hering]

On Thu, Oct 26, Andrew Cooper wrote:

> I've never really understood why xenfs exists in the first place
> (although I expect the answer is "Because that is how someone did it in
> the past"), and I'm not aware of any other project which needs its own
> custom filesystem driver for device nodes.

Perhaps in the early days, before udev, new nodes would not magically
appear in /dev. It was likely easy to be compatible that way, just like
claiming /dev/hda to please existing installation programs.

> Is it possible to express a dependency on proc-xen.mount ||
> proc-xen.service?

As ordering yes, an additional After=proc-xen.service line is needed.
An existing Requires=proc-xen.mount can not be used anymore, I have not
verified that.

> If not, then out-of-tree packages are going to have compatibility
> problems with this change.

Only if they use Requires=proc-xen.mount.

> Right, but ISTR that Systemd deals with /etc/fstab by auto-generating
> *.mount targets, and from what is said here, it is the proc-xen.mount
> target which is now broken by the change in systemd behaviour.

No, existing fstab entries will continue to work. /dev/shm is
automounted, and my own fstab entry for /dev/shm always worked.

Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 6/9] x86/vvmx: Remove operand reading from decode_vmx_inst()

[Euan Harris]

Use operand_read() to read memory operands instead of using the value
read by decode_vmx_inst() in the following functions:

 * nvmx_handle_invept()
 * nvmx_handle_invvpid()
 * nvmx_handle_vmclear()
 * nvmx_handle_vmptrld()
 * nvmx_handle_vmxon()
 * nvmx_handle_vmwrite()

Signed-off-by: Euan Harris 
---
 xen/arch/x86/hvm/vmx/vvmx.c | 57 -
 1 file changed, 31 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 7cda37b136..fc2123c7c0 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -456,7 +456,7 @@ gp_fault:
 
 static int decode_vmx_inst(struct cpu_user_regs *regs,
struct vmx_inst_decoded *decode,
-   unsigned long *poperandS, int vmxon_check)
+   int vmxon_check)
 {
 struct vcpu *v = current;
 union vmx_inst_info info;
@@ -473,13 +473,6 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 if ( info.fields.memreg ) {
 decode->op[0].type = VMX_INST_MEMREG_TYPE_REG;
 decode->op[0].reg_idx = info.fields.reg1;
-if ( poperandS != NULL )
-{
-int rc = operand_read(poperandS, >op[0], regs,
-  decode->op[0].len);
-if ( rc != X86EMUL_OKAY )
-return rc;
-}
 }
 else
 {
@@ -516,14 +509,6 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 
 decode->op[0].mem = base;
 decode->op[0].len = size;
-
-if ( poperandS != NULL )
-{
-int rc = operand_read(poperandS, >op[0], regs,
-  decode->op[0].len);
-if ( rc != X86EMUL_OKAY )
-return rc;
-}
 }
 
 decode->op[1].type = VMX_INST_MEMREG_TYPE_REG;
@@ -1513,7 +1498,11 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
 uint32_t nvmcs_revid;
 int rc;
 
-rc = decode_vmx_inst(regs, , , 1);
+rc = decode_vmx_inst(regs, , 1);
+if ( rc != X86EMUL_OKAY )
+return rc;
+
+rc = operand_read(, [0], regs, decode.op[0].len);
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -1729,7 +1718,11 @@ int nvmx_handle_vmptrld(struct cpu_user_regs *regs)
 unsigned long gpa = 0;
 int rc;
 
-rc = decode_vmx_inst(regs, , , 0);
+rc = decode_vmx_inst(regs, , 0);
+if ( rc != X86EMUL_OKAY )
+return rc;
+
+rc = operand_read(, [0], regs, decode.op[0].len);
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -1801,7 +1794,7 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
 unsigned long gpa = 0;
 int rc;
 
-rc = decode_vmx_inst(regs, , NULL, 0);
+rc = decode_vmx_inst(regs, , 0);
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -1828,7 +1821,11 @@ int nvmx_handle_vmclear(struct cpu_user_regs *regs)
 void *vvmcs;
 int rc;
 
-rc = decode_vmx_inst(regs, , , 0);
+rc = decode_vmx_inst(regs, , 0);
+if ( rc != X86EMUL_OKAY )
+return rc;
+
+rc = operand_read(, [0], regs, decode.op[0].len);
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -1879,7 +1876,7 @@ int nvmx_handle_vmread(struct cpu_user_regs *regs)
 int rc;
 unsigned long vmcs_encoding = 0;
 
-rc = decode_vmx_inst(regs, , NULL, 0);
+rc = decode_vmx_inst(regs, , 0);
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -1928,10 +1925,13 @@ int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
 enum vmx_insn_errno err;
 int rc;
 
-if ( decode_vmx_inst(regs, , , 0)
- != X86EMUL_OKAY )
+if ( decode_vmx_inst(regs, , 0) != X86EMUL_OKAY )
 return X86EMUL_EXCEPTION;
 
+rc = operand_read(, [0], regs, decode.op[0].len);
+if ( rc != X86EMUL_OKAY )
+return rc;
+
 if ( vcpu_nestedhvm(v).nv_vvmcxaddr == INVALID_PADDR )
 {
 vmfail_invalid(regs);
@@ -1973,11 +1973,10 @@ int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
 int nvmx_handle_invept(struct cpu_user_regs *regs)
 {
 struct vmx_inst_decoded decode;
-unsigned long eptp;
 unsigned long invept_type = 0;
 int ret;
 
-if ( (ret = decode_vmx_inst(regs, , , 0)) != X86EMUL_OKAY )
+if ( (ret = decode_vmx_inst(regs, , 0)) != X86EMUL_OKAY )
 return ret;
 
 ret = operand_read(_type, [1], regs, decode.op[1].len);
@@ -1988,6 +1987,12 @@ int nvmx_handle_invept(struct cpu_user_regs *regs)
 {
 case INVEPT_SINGLE_CONTEXT:
 {
+unsigned long eptp;
+
+ret = operand_read(, [0], regs, decode.op[0].len);
+if ( ret )
+return ret;
+
 np2m_flush_base(current, eptp);
 break;
 }
@@ -2009,7 +2014,7 @@ int nvmx_handle_invvpid(struct cpu_user_regs *regs)
 unsigned long invvpid_type = 0;
 int ret;
 
-if ( (ret = decode_vmx_inst(regs, , NULL, 0)) != X86EMUL_OKAY )
+if ( (ret = decode_vmx_inst(regs, , 0)) != X86EMUL_OKAY )
  

[Xen-devel] [PATCH 1/9] x86/vvmx: Remove enum vmx_regs_enc

[Euan Harris]

This is the standard register encoding, is not VVMX-specific and is only
used in a couple of places.

Signed-off-by: Euan Harris 
---
 xen/arch/x86/hvm/vmx/vvmx.c|  8 
 xen/include/asm-x86/hvm/vmx/vvmx.h | 22 --
 2 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index dde02c076b..9d87786894 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -201,10 +201,10 @@ struct vmx_inst_decoded {
 unsigned long mem;
 unsigned int  len;
 };
-enum vmx_regs_enc reg1;
+unsigned int reg1;
 };
 
-enum vmx_regs_enc reg2;
+unsigned int reg2;
 };
 
 enum vmx_ops_result {
@@ -345,7 +345,7 @@ enum vmx_insn_errno set_vvmcs_real_safe(const struct vcpu 
*v, u32 encoding,
 }
 
 static unsigned long reg_read(struct cpu_user_regs *regs,
-  enum vmx_regs_enc index)
+  unsigned int index)
 {
 unsigned long *pval = decode_register(index, regs, 0);
 
@@ -353,7 +353,7 @@ static unsigned long reg_read(struct cpu_user_regs *regs,
 }
 
 static void reg_write(struct cpu_user_regs *regs,
-  enum vmx_regs_enc index,
+  unsigned int index,
   unsigned long value)
 {
 unsigned long *pval = decode_register(index, regs, 0);
diff --git a/xen/include/asm-x86/hvm/vmx/vvmx.h 
b/xen/include/asm-x86/hvm/vmx/vvmx.h
index 3285b03bbb..9ea35eb795 100644
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h
@@ -64,28 +64,6 @@ struct nestedvmx {
 /* bit 0-8, and 12 must be 1 */
 #define VMX_ENTRY_CTLS_DEFAULT10x11ff
 
-/*
- * Encode of VMX instructions base on Table 24-11 & 24-12 of SDM 3B
- */
-
-enum vmx_regs_enc {
-VMX_REG_RAX,
-VMX_REG_RCX,
-VMX_REG_RDX,
-VMX_REG_RBX,
-VMX_REG_RSP,
-VMX_REG_RBP,
-VMX_REG_RSI,
-VMX_REG_RDI,
-VMX_REG_R8,
-VMX_REG_R9,
-VMX_REG_R10,
-VMX_REG_R11,
-VMX_REG_R12,
-VMX_REG_R13,
-VMX_REG_R14,
-VMX_REG_R15,
-};
 
 union vmx_inst_info {
 struct {
-- 
2.13.6


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 5/9] x86/vvmx: Replace direct calls to reg_read() with operand_read()

[Euan Harris]

Use operand_read() to read register operands in the following functions:

 * nvmx_handle_vmread()
 * nvmx_handle_vmwrite()
 * nvmx_handle_invept()

Direct reading of memory operands will be replaced in a separate patch.

Signed-off-by: Euan Harris 
---
 xen/arch/x86/hvm/vmx/vvmx.c | 29 -
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 32c07eca3d..7cda37b136 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1877,6 +1877,7 @@ int nvmx_handle_vmread(struct cpu_user_regs *regs)
 pagefault_info_t pfinfo;
 u64 value = 0;
 int rc;
+unsigned long vmcs_encoding = 0;
 
 rc = decode_vmx_inst(regs, , NULL, 0);
 if ( rc != X86EMUL_OKAY )
@@ -1888,7 +1889,11 @@ int nvmx_handle_vmread(struct cpu_user_regs *regs)
 return X86EMUL_OKAY;
 }
 
-rc = get_vvmcs_safe(v, reg_read(regs, decode.op[1].reg_idx), );
+rc = operand_read(_encoding, [1], regs, decode.op[1].len);
+if ( rc != X86EMUL_OKAY )
+return rc;
+
+rc = get_vvmcs_safe(v, vmcs_encoding, );
 if ( rc != VMX_INSN_SUCCEED )
 {
 vmfail(regs, rc);
@@ -1918,9 +1923,10 @@ int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
 struct vcpu *v = current;
 struct vmx_inst_decoded decode;
 unsigned long operand; 
-u64 vmcs_encoding;
+unsigned long vmcs_encoding = 0;
 bool_t okay = 1;
 enum vmx_insn_errno err;
+int rc;
 
 if ( decode_vmx_inst(regs, , , 0)
  != X86EMUL_OKAY )
@@ -1932,7 +1938,10 @@ int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
 return X86EMUL_OKAY;
 }
 
-vmcs_encoding = reg_read(regs, decode.op[1].reg_idx);
+rc = operand_read(_encoding, [1], regs, decode.op[1].len);
+if ( rc != X86EMUL_OKAY )
+return rc;
+
 err = set_vvmcs_safe(v, vmcs_encoding, operand);
 if ( err != VMX_INSN_SUCCEED )
 {
@@ -1965,12 +1974,17 @@ int nvmx_handle_invept(struct cpu_user_regs *regs)
 {
 struct vmx_inst_decoded decode;
 unsigned long eptp;
+unsigned long invept_type = 0;
 int ret;
 
 if ( (ret = decode_vmx_inst(regs, , , 0)) != X86EMUL_OKAY )
 return ret;
 
-switch ( reg_read(regs, decode.op[1].reg_idx) )
+ret = operand_read(_type, [1], regs, decode.op[1].len);
+if ( ret != X86EMUL_OKAY )
+return ret;
+
+switch ( invept_type )
 {
 case INVEPT_SINGLE_CONTEXT:
 {
@@ -1992,12 +2006,17 @@ int nvmx_handle_invept(struct cpu_user_regs *regs)
 int nvmx_handle_invvpid(struct cpu_user_regs *regs)
 {
 struct vmx_inst_decoded decode;
+unsigned long invvpid_type = 0;
 int ret;
 
 if ( (ret = decode_vmx_inst(regs, , NULL, 0)) != X86EMUL_OKAY )
 return ret;
 
-switch ( reg_read(regs, decode.op[1].reg_idx) )
+ret = operand_read(_type, [1], regs, decode.op[1].len);
+if ( ret != X86EMUL_OKAY )
+return ret;
+
+switch ( invvpid_type )
 {
 /* Just invalidate all tlb entries for all types! */
 case INVVPID_INDIVIDUAL_ADDR:
-- 
2.13.6


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 4/9] x86/vvmx: Remove unnecessary VMX operand reads

[Euan Harris]

 * vpid is never used in nvmx_handle_invept() so there is no point in
   reading it.

 * vmptrst's operand is the memory address to which to write the VMCS
   pointer.   gpa is the pointer to write.   Reading the address into
   gpa is meaningless.

Signed-off-by: Euan Harris 
---
 xen/arch/x86/hvm/vmx/vvmx.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index df84592490..32c07eca3d 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1801,7 +1801,7 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
 unsigned long gpa = 0;
 int rc;
 
-rc = decode_vmx_inst(regs, , , 0);
+rc = decode_vmx_inst(regs, , NULL, 0);
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -1992,10 +1992,9 @@ int nvmx_handle_invept(struct cpu_user_regs *regs)
 int nvmx_handle_invvpid(struct cpu_user_regs *regs)
 {
 struct vmx_inst_decoded decode;
-unsigned long vpid;
 int ret;
 
-if ( (ret = decode_vmx_inst(regs, , , 0)) != X86EMUL_OKAY )
+if ( (ret = decode_vmx_inst(regs, , NULL, 0)) != X86EMUL_OKAY )
 return ret;
 
 switch ( reg_read(regs, decode.op[1].reg_idx) )
-- 
2.13.6


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 9/9] x86/vvmx: Use hvm_copy_{to, from}_guest_virt() to read operands

[Euan Harris]

decode_vmx_inst() contains its own segmentation logic.This
unnecessarily duplicates segmentation code used elsewhere and contains
errors: it raises a #GP fault instead of an #SS fault for an invalid
memory access through the stack segment.

Replace this logic with hvm_copy_{to,from}_guest_virt(), which use
well-tested memory access code used in various other parts of the
hypervisor.

Signed-off-by: Euan Harris 
---
 xen/arch/x86/hvm/vmx/vvmx.c | 80 +++--
 1 file changed, 26 insertions(+), 54 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 9a4e6177ad..f0a2242711 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -199,7 +199,10 @@ struct vmx_inst_decoded {
 int type;
 unsigned int bytes;
 union {
-unsigned long mem;
+struct {
+enum x86_segment seg;
+unsigned long offset;
+};
 unsigned int reg_idx;
 };
 } op[2];
@@ -380,17 +383,7 @@ static int operand_read(void *buf, struct vmx_inst_op *op,
 return X86EMUL_OKAY;
 }
 else
-{
-pagefault_info_t pfinfo;
-int rc = hvm_copy_from_guest_linear(buf, op->mem, bytes, 0, );
-
-if ( rc == HVMTRANS_bad_linear_to_gfn )
-hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
-if ( rc != HVMTRANS_okay )
-return X86EMUL_EXCEPTION;
-
-return X86EMUL_OKAY;
-}
+return hvm_copy_from_guest_virt(buf, op->seg, op->offset, bytes, 0);
 }
 
 static inline u32 __n2_pin_exec_control(struct vcpu *v)
@@ -458,9 +451,8 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 {
 struct vcpu *v = current;
 union vmx_inst_info info;
-struct segment_register seg;
-unsigned long base, index, seg_base, disp, offset;
-int scale, size;
+unsigned long base, index, disp, offset;
+int scale;
 
 unsigned int bytes = vmx_guest_x86_mode(v);
 
@@ -477,14 +469,11 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 }
 else
 {
-bool mode_64bit = (bytes == 8);
-
-decode->op[0].type = VMX_INST_MEMREG_TYPE_MEMORY;
-
 if ( info.fields.segment > x86_seg_gs )
-goto gp_fault;
-hvm_get_segment_register(v, info.fields.segment, );
-seg_base = seg.base;
+{
+ASSERT_UNREACHABLE();
+return X86EMUL_UNHANDLEABLE;
+}
 
 base = info.fields.base_reg_invalid ? 0 :
 reg_read(regs, info.fields.base_reg);
@@ -496,19 +485,12 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 
 __vmread(EXIT_QUALIFICATION, );
 
-size = 1 << (info.fields.addr_size + 1);
-
-offset = base + index * scale + disp;
-base = !mode_64bit || info.fields.segment >= x86_seg_fs ?
-   seg_base + offset : offset;
-if ( offset + size - 1 < offset ||
- (mode_64bit ?
-  !is_canonical_address((long)base < 0 ? base :
-base + size - 1) :
-  offset + size - 1 > seg.limit) )
-goto gp_fault;
+decode->op[0].type = VMX_INST_MEMREG_TYPE_MEMORY;
+decode->op[0].seg = info.fields.segment;
+decode->op[0].offset = base + index * scale + disp;
+if ( info.fields.addr_size < 2 )
+decode->op[0].offset = (uint32_t)decode->op[0].offset;
 
-decode->op[0].mem = base;
 decode->op[0].bytes = bytes;
 }
 
@@ -517,10 +499,6 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 decode->op[1].bytes = bytes;
 
 return X86EMUL_OKAY;
-
-gp_fault:
-hvm_inject_hw_exception(TRAP_gp_fault, 0);
-return X86EMUL_EXCEPTION;
 }
 
 static void vmsucceed(struct cpu_user_regs *regs)
@@ -1792,8 +1770,7 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
 struct vcpu *v = current;
 struct vmx_inst_decoded decode;
 struct nestedvcpu *nvcpu = _nestedhvm(v);
-pagefault_info_t pfinfo;
-unsigned long gpa = 0;
+uint64_t gpa;
 int rc;
 
 rc = decode_vmx_inst(regs, , 0);
@@ -1802,12 +1779,10 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
 
 gpa = nvcpu->nv_vvmcxaddr;
 
-rc = hvm_copy_to_guest_linear(decode.op[0].mem, ,
-  decode.op[0].bytes, 0, );
-if ( rc == HVMTRANS_bad_linear_to_gfn )
-hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
-if ( rc != HVMTRANS_okay )
-return X86EMUL_EXCEPTION;
+rc = hvm_copy_to_guest_virt(decode.op[0].seg, decode.op[0].offset, 
+, sizeof(gpa), 0);
+if ( rc != X86EMUL_OKAY )
+return rc;
 
 vmsucceed(regs);
 return X86EMUL_OKAY;
@@ -1873,8 +1848,7 @@ int nvmx_handle_vmread(struct cpu_user_regs *regs)
 {
 struct vcpu *v = current;
 struct vmx_inst_decoded decode;
-pagefault_info_t pfinfo;
-u64 

[Xen-devel] [PATCH 2/9] x86/vvmx: Unify operands in struct vmx_inst_decoded

[Euan Harris]

This change prepares the way for abstracting the code which reads
memory and register operands into a generic operand_read() function in
a future patch.

Operand 1 may either be a memory location or a register, depending on
the instruction being handled.   Operand 2 may only be a register, but
it is now represented in the same way as operand 1 and so has a type
field.   This will always equal VMX_INST_MEMREG_TYPE_REG.

References to the old structure map to the new one as follows:

  mem  -> op[0].mem
  len  -> op[0].len
  reg1 -> op[0].reg
  reg2 -> op[1].reg

References to type always map to op[0].type in this patch because
previously operand 2 could only be a register and so type was never
checked when accessing it.

Signed-off-by: Euan Harris 
---
 xen/arch/x86/hvm/vmx/vvmx.c | 52 -
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 9d87786894..20e5e29031 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -195,16 +195,16 @@ bool_t nvmx_ept_enabled(struct vcpu *v)
 struct vmx_inst_decoded {
 #define VMX_INST_MEMREG_TYPE_MEMORY 0
 #define VMX_INST_MEMREG_TYPE_REG1
-int type;
-union {
-struct {
-unsigned long mem;
-unsigned int  len;
+struct vmx_inst_op {
+int type;
+union {
+struct {
+unsigned long mem;
+unsigned int  len;
+};
+unsigned int reg_idx;
 };
-unsigned int reg1;
-};
-
-unsigned int reg2;
+} op[2];
 };
 
 enum vmx_ops_result {
@@ -437,16 +437,16 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 info.word = offset;
 
 if ( info.fields.memreg ) {
-decode->type = VMX_INST_MEMREG_TYPE_REG;
-decode->reg1 = info.fields.reg1;
+decode->op[0].type = VMX_INST_MEMREG_TYPE_REG;
+decode->op[0].reg_idx = info.fields.reg1;
 if ( poperandS != NULL )
-*poperandS = reg_read(regs, decode->reg1);
+*poperandS = reg_read(regs, decode->op[0].reg_idx);
 }
 else
 {
 bool mode_64bit = (vmx_guest_x86_mode(v) == 8);
 
-decode->type = VMX_INST_MEMREG_TYPE_MEMORY;
+decode->op[0].type = VMX_INST_MEMREG_TYPE_MEMORY;
 
 if ( info.fields.segment > x86_seg_gs )
 goto gp_fault;
@@ -486,11 +486,13 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 if ( rc != HVMTRANS_okay )
 return X86EMUL_EXCEPTION;
 }
-decode->mem = base;
-decode->len = size;
+
+decode->op[0].mem = base;
+decode->op[0].len = size;
 }
 
-decode->reg2 = info.fields.reg2;
+decode->op[1].type = VMX_INST_MEMREG_TYPE_REG;
+decode->op[1].reg_idx = info.fields.reg2;
 
 return X86EMUL_OKAY;
 
@@ -1770,7 +1772,8 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
 
 gpa = nvcpu->nv_vvmcxaddr;
 
-rc = hvm_copy_to_guest_linear(decode.mem, , decode.len, 0, );
+rc = hvm_copy_to_guest_linear(decode.op[0].mem, ,
+  decode.op[0].len, 0, );
 if ( rc == HVMTRANS_bad_linear_to_gfn )
 hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
 if ( rc != HVMTRANS_okay )
@@ -1850,23 +1853,24 @@ int nvmx_handle_vmread(struct cpu_user_regs *regs)
 return X86EMUL_OKAY;
 }
 
-rc = get_vvmcs_safe(v, reg_read(regs, decode.reg2), );
+rc = get_vvmcs_safe(v, reg_read(regs, decode.op[1].reg_idx), );
 if ( rc != VMX_INSN_SUCCEED )
 {
 vmfail(regs, rc);
 return X86EMUL_OKAY;
 }
 
-switch ( decode.type ) {
+switch ( decode.op[0].type ) {
 case VMX_INST_MEMREG_TYPE_MEMORY:
-rc = hvm_copy_to_guest_linear(decode.mem, , decode.len, 0, 
);
+rc = hvm_copy_to_guest_linear(decode.op[0].mem, ,
+  decode.op[0].len, 0, );
 if ( rc == HVMTRANS_bad_linear_to_gfn )
 hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
 if ( rc != HVMTRANS_okay )
 return X86EMUL_EXCEPTION;
 break;
 case VMX_INST_MEMREG_TYPE_REG:
-reg_write(regs, decode.reg1, value);
+reg_write(regs, decode.op[0].reg_idx, value);
 break;
 }
 
@@ -1893,7 +1897,7 @@ int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
 return X86EMUL_OKAY;
 }
 
-vmcs_encoding = reg_read(regs, decode.reg2);
+vmcs_encoding = reg_read(regs, decode.op[1].reg_idx);
 err = set_vvmcs_safe(v, vmcs_encoding, operand);
 if ( err != VMX_INSN_SUCCEED )
 {
@@ -1931,7 +1935,7 @@ int nvmx_handle_invept(struct cpu_user_regs *regs)
 if ( (ret = decode_vmx_inst(regs, , , 0)) != X86EMUL_OKAY )
 return ret;
 
-switch ( reg_read(regs, decode.reg2) )
+switch ( reg_read(regs, decode.op[1].reg_idx) )
 {
 case INVEPT_SINGLE_CONTEXT:
 

[Xen-devel] [PATCH 0/9] x86/vvmx: Read instruction operands correctly on VM exit

[Euan Harris]

decode_vmx_inst() does not read instruction operands correctly on VM exit:

 * It incorrectly uses vmx_inst_info's address_size field to calculate
   the sizes of the exit-causing instruction's operands.  The sizes of
   the operands are specified in the SDM and might depend on whether the
   guest is running in 32-bit or 64-bit mode, but they have nothing to do
   with the address_size field.

 * It includes its own segmentation logic, duplicating code elsewhere.
   This segmentation logic is also incorrect and will raise #GP fault
   rather than a #SS fault in response to an invalid memory access
   through the stack segment.
 
Patches 1-6 (up to 'Remove operand decoding from decode_vmx_inst()')
refactor decode_vmx_inst() in preparation for fixing the bugs mentioned
above.  They remove unnecessary code and extract the logic for reading
operands from decode_vmx_inst() into a new operand_read() function.
These patches should not cause any functional changes.

Patch 7 ('Use correct sizes when reading operands') replaces the incorrect
operand size calculations based on address_size with the correct sizes
from the SDM.

Patches 8 and 9 add new hvm_copy_{to,from}_guest_virt() helpers and use
them to read memory operands in place of the incorrect segmentation
logic in decode_vmx_inst().

Euan Harris (9):
  x86/vvmx: Remove enum vmx_regs_enc
  x86/vvmx: Unify operands in struct vmx_inst_decoded
  x86/vvmx: Extract operand reading logic into operand_read()
  x86/vvmx: Remove unnecessary VMX operand reads
  x86/vvmx: Replace direct calls to reg_read() with operand_read()
  x86/vvmx: Remove operand reading from decode_vmx_inst()
  x86/vvmx: Use correct sizes when reading operands
  x86/hvm: Add hvm_copy_{to,from}_guest_virt() helpers
  x86/vvmx: Use hvm_copy_{to,from}_guest_virt() to read operands

 xen/arch/x86/hvm/hvm.c |  57 ++
 xen/arch/x86/hvm/vmx/vvmx.c| 216 +
 xen/include/asm-x86/hvm/support.h  |  12 +++
 xen/include/asm-x86/hvm/vmx/vvmx.h |  22 
 4 files changed, 195 insertions(+), 112 deletions(-)

-- 
2.13.6


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 7/9] x86/vvmx: Use correct sizes when reading operands

[Euan Harris]

The sizes of VMX operands are defined in the Intel SDM and have nothing
to do with the addr_size field of struct vmx_inst_info:

invept:   r32/r64, m128
invvpid:  r32/r64, m128
vmclear:  m64
vmptrld:  m64
vmptrst:  m64
vmread:   r32/64 or m32/64, r32/64
vmwrite:  r32/r64, r32/64 or m32/64
vmon: m64

* Register operands are 32-bit or 64-bit depending on the guest mode.

* Memory operands are almost always of fixed size, usually 64-bit, but
  for vmread and vmwrite their size depends on the guest mode.

* invept has a 128-bit memory operand but the upper 64 bits are reserved
  and therefore need not be read.

* invvpid has a 128-bit memory operand but we only require the VPID value
  which lies in the lower 64 bits.

When reading variable-size operands, we pass the operand size calculated
by decode_vmx_inst() and stored in strcut vmx_inst_op.   When reading
fixed-size operands, we pass the size of the variable into which the
operand is to be read.

Signed-off-by: Euan Harris 
---
 xen/arch/x86/hvm/vmx/vvmx.c | 48 +++--
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index fc2123c7c0..9a4e6177ad 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -197,11 +197,9 @@ struct vmx_inst_decoded {
 #define VMX_INST_MEMREG_TYPE_REG1
 struct vmx_inst_op {
 int type;
+unsigned int bytes;
 union {
-struct {
-unsigned long mem;
-unsigned int  len;
-};
+unsigned long mem;
 unsigned int reg_idx;
 };
 } op[2];
@@ -464,6 +462,8 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 unsigned long base, index, seg_base, disp, offset;
 int scale, size;
 
+unsigned int bytes = vmx_guest_x86_mode(v);
+
 if ( vmx_inst_check_privilege(regs, vmxon_check) != X86EMUL_OKAY )
 return X86EMUL_EXCEPTION;
 
@@ -473,10 +473,11 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 if ( info.fields.memreg ) {
 decode->op[0].type = VMX_INST_MEMREG_TYPE_REG;
 decode->op[0].reg_idx = info.fields.reg1;
+decode->op[0].bytes = bytes;
 }
 else
 {
-bool mode_64bit = (vmx_guest_x86_mode(v) == 8);
+bool mode_64bit = (bytes == 8);
 
 decode->op[0].type = VMX_INST_MEMREG_TYPE_MEMORY;
 
@@ -508,11 +509,12 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 goto gp_fault;
 
 decode->op[0].mem = base;
-decode->op[0].len = size;
+decode->op[0].bytes = bytes;
 }
 
 decode->op[1].type = VMX_INST_MEMREG_TYPE_REG;
 decode->op[1].reg_idx = info.fields.reg2;
+decode->op[1].bytes = bytes;
 
 return X86EMUL_OKAY;
 
@@ -1494,7 +1496,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
 struct nestedvmx *nvmx = _2_nvmx(v);
 struct nestedvcpu *nvcpu = _nestedhvm(v);
 struct vmx_inst_decoded decode;
-unsigned long gpa = 0;
+uint64_t gpa;
 uint32_t nvmcs_revid;
 int rc;
 
@@ -1502,7 +1504,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
 if ( rc != X86EMUL_OKAY )
 return rc;
 
-rc = operand_read(, [0], regs, decode.op[0].len);
+rc = operand_read(, [0], regs, sizeof(gpa));
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -1715,14 +1717,14 @@ int nvmx_handle_vmptrld(struct cpu_user_regs *regs)
 struct vcpu *v = current;
 struct vmx_inst_decoded decode;
 struct nestedvcpu *nvcpu = _nestedhvm(v);
-unsigned long gpa = 0;
+uint64_t gpa;
 int rc;
 
 rc = decode_vmx_inst(regs, , 0);
 if ( rc != X86EMUL_OKAY )
 return rc;
 
-rc = operand_read(, [0], regs, decode.op[0].len);
+rc = operand_read(, [0], regs, sizeof(gpa));
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -1801,7 +1803,7 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
 gpa = nvcpu->nv_vvmcxaddr;
 
 rc = hvm_copy_to_guest_linear(decode.op[0].mem, ,
-  decode.op[0].len, 0, );
+  decode.op[0].bytes, 0, );
 if ( rc == HVMTRANS_bad_linear_to_gfn )
 hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
 if ( rc != HVMTRANS_okay )
@@ -1817,7 +1819,7 @@ int nvmx_handle_vmclear(struct cpu_user_regs *regs)
 struct vmx_inst_decoded decode;
 struct nestedvcpu *nvcpu = _nestedhvm(v);
 struct nestedvmx *nvmx = _2_nvmx(v);
-unsigned long gpa = 0;
+uint64_t gpa;
 void *vvmcs;
 int rc;
 
@@ -1825,7 +1827,7 @@ int nvmx_handle_vmclear(struct cpu_user_regs *regs)
 if ( rc != X86EMUL_OKAY )
 return rc;
 
-rc = operand_read(, [0], regs, decode.op[0].len);
+rc = operand_read(, [0], regs, sizeof(gpa));
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -1886,7 +1888,7 @@ int nvmx_handle_vmread(struct 

[Xen-devel] [PATCH 3/9] x86/vvmx: Extract operand reading logic into operand_read()

[Euan Harris]

Extract the logic for reading operands from decode_vmx_inst() into
operand_read().   Future patches will replace operand reading logic
in elsewhere with calls to operand_read().

operand_read() must explicitly handle different operand sizes to avoid
corrupting the caller's stack.   This patch should not change the overall
behaviour of the code.

Signed-off-by: Euan Harris 
---
 xen/arch/x86/hvm/vmx/vvmx.c | 59 -
 1 file changed, 47 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 20e5e29031..df84592490 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -361,6 +361,40 @@ static void reg_write(struct cpu_user_regs *regs,
 *pval = value;
 }
 
+static int operand_read(void *buf, struct vmx_inst_op *op,
+struct cpu_user_regs *regs, unsigned int bytes)
+{
+if ( op->type == VMX_INST_MEMREG_TYPE_REG )
+{
+switch ( bytes )
+{
+case 4:
+*(uint32_t *)buf = reg_read(regs, op->reg_idx);
+
+case 8:
+*(uint64_t *)buf = reg_read(regs, op->reg_idx);
+
+default:
+ASSERT_UNREACHABLE();
+return X86EMUL_UNHANDLEABLE;
+}
+
+return X86EMUL_OKAY;
+}
+else
+{
+pagefault_info_t pfinfo;
+int rc = hvm_copy_from_guest_linear(buf, op->mem, bytes, 0, );
+
+if ( rc == HVMTRANS_bad_linear_to_gfn )
+hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
+if ( rc != HVMTRANS_okay )
+return X86EMUL_EXCEPTION;
+
+return X86EMUL_OKAY;
+}
+}
+
 static inline u32 __n2_pin_exec_control(struct vcpu *v)
 {
 return get_vvmcs(v, PIN_BASED_VM_EXEC_CONTROL);
@@ -440,7 +474,12 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
 decode->op[0].type = VMX_INST_MEMREG_TYPE_REG;
 decode->op[0].reg_idx = info.fields.reg1;
 if ( poperandS != NULL )
-*poperandS = reg_read(regs, decode->op[0].reg_idx);
+{
+int rc = operand_read(poperandS, >op[0], regs,
+  decode->op[0].len);
+if ( rc != X86EMUL_OKAY )
+return rc;
+}
 }
 else
 {
@@ -475,20 +514,16 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
   offset + size - 1 > seg.limit) )
 goto gp_fault;
 
+decode->op[0].mem = base;
+decode->op[0].len = size;
+
 if ( poperandS != NULL )
 {
-pagefault_info_t pfinfo;
-int rc = hvm_copy_from_guest_linear(poperandS, base, size,
-0, );
-
-if ( rc == HVMTRANS_bad_linear_to_gfn )
-hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
-if ( rc != HVMTRANS_okay )
-return X86EMUL_EXCEPTION;
+int rc = operand_read(poperandS, >op[0], regs,
+  decode->op[0].len);
+if ( rc != X86EMUL_OKAY )
+return rc;
 }
-
-decode->op[0].mem = base;
-decode->op[0].len = size;
 }
 
 decode->op[1].type = VMX_INST_MEMREG_TYPE_REG;
-- 
2.13.6


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 8/9] x86/hvm: Add hvm_copy_{to, from}_guest_virt() helpers

[Euan Harris]

hvm_copy_{to,from}_guest_virt() copy data to and from a guest, performing
segmentatino and paging checks on the provided seg:offset virtual address.

Signed-off-by: Euan Harris 
---
 xen/arch/x86/hvm/hvm.c| 57 +++
 xen/include/asm-x86/hvm/support.h | 12 +
 2 files changed, 69 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 205b4cb685..5d2bdd6b2b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3312,6 +3312,63 @@ unsigned long copy_from_user_hvm(void *to, const void 
*from, unsigned len)
 return rc ? len : 0; /* fake a copy_from_user() return code */
 }
 
+static int _hvm_copy_guest_virt(
+enum x86_segment seg, unsigned long offset, void *buf, unsigned int bytes,
+uint32_t pfec, unsigned int flags)
+{
+struct vcpu *curr = current;
+struct segment_register sreg, cs;
+enum hvm_translation_result res;
+pagefault_info_t pfinfo;
+unsigned long linear;
+
+ASSERT(is_x86_user_segment(seg));
+
+hvm_get_segment_register(curr, seg, );
+hvm_get_segment_register(curr, x86_seg_cs, );
+
+if ( !hvm_virtual_to_linear_addr(
+ seg, , offset, bytes,
+ flags & HVMCOPY_to_guest ? hvm_access_write : hvm_access_read,
+ , ) )
+{
+hvm_inject_hw_exception(
+(seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault, 0);
+return X86EMUL_EXCEPTION;
+}
+
+if ( flags & HVMCOPY_to_guest )
+res = hvm_copy_to_guest_linear(linear, buf, bytes, pfec, );
+else
+res = hvm_copy_from_guest_linear(buf, linear, bytes, pfec, );
+
+if ( res == HVMTRANS_bad_linear_to_gfn )
+{
+hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
+return X86EMUL_EXCEPTION;
+}
+else if ( res )
+return X86EMUL_RETRY;
+
+return X86EMUL_OKAY;
+}
+
+int hvm_copy_to_guest_virt(
+enum x86_segment seg, unsigned long offset, void *buf, unsigned int bytes,
+uint32_t pfec)
+{
+return _hvm_copy_guest_virt(seg, offset, buf, bytes, pfec,
+HVMCOPY_to_guest);
+}
+
+int hvm_copy_from_guest_virt(
+void *buf, enum x86_segment seg, unsigned long offset, unsigned int bytes,
+uint32_t pfec)
+{
+return _hvm_copy_guest_virt(seg, offset, buf, bytes, pfec,
+HVMCOPY_from_guest);
+}
+
 bool hvm_check_cpuid_faulting(struct vcpu *v)
 {
 const struct msr_vcpu_policy *vp = v->arch.msr;
diff --git a/xen/include/asm-x86/hvm/support.h 
b/xen/include/asm-x86/hvm/support.h
index d784fc1856..9af2ae77b7 100644
--- a/xen/include/asm-x86/hvm/support.h
+++ b/xen/include/asm-x86/hvm/support.h
@@ -115,6 +115,18 @@ enum hvm_translation_result hvm_translate_get_page(
 pagefault_info_t *pfinfo, struct page_info **page_p,
 gfn_t *gfn_p, p2m_type_t *p2mt_p);
 
+/*
+ * Copy data to and from a guest, performing segmentation and paging checks
+ * on the provided seg:offset virtual address.
+ * Returns X86EMUL_* and raises exceptions with the current vcpu.
+ */
+int hvm_copy_to_guest_virt(
+enum x86_segment seg, unsigned long offset, void *buf, unsigned int bytes,
+uint32_t pfec);
+int hvm_copy_from_guest_virt(
+void *buf, enum x86_segment seg, unsigned long offset, unsigned int bytes,
+uint32_t pfec);
+
 #define HVM_HCALL_completed  0 /* hypercall completed - no further action */
 #define HVM_HCALL_preempted  1 /* hypercall preempted - re-execute VMCALL */
 int hvm_hypercall(struct cpu_user_regs *regs);
-- 
2.13.6


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

[Andrew Cooper]

On 26/10/17 16:59, Olaf Hering wrote:
> On Thu, Oct 26, Andrew Cooper wrote:
>
>> Can't all information be obtained from /sys/hypervisor?  If not, how
>> hard would it be to make happen?
> Likely not that hard. Not sure why that was not added in the first place.

I've never really understood why xenfs exists in the first place
(although I expect the answer is "Because that is how someone did it in
the past"), and I'm not aware of any other project which needs its own
custom filesystem driver for device nodes.

These days, /dev/xen/ is the preferred location for devices anyway.

Either way, I don't mean to bikeshed the issue, but we should at least
consider whether cleaning this up fully is the easiest course of action.

>
>> What happens to all the software which currently has a dependency on
>> proc-xen.mount ?
> All software gets converted by this change.

Is it possible to express a dependency on proc-xen.mount ||
proc-xen.service?

If not, then out-of-tree packages are going to have compatibility
problems with this change.

>
>> Independently, how does this interact with having a xenfs entries in
>> /etc/fstab, which might plausibly still exist for compatibility with
>> other init systems?
> mount(1) will continue to consider them.

Right, but ISTR that Systemd deals with /etc/fstab by auto-generating
*.mount targets, and from what is said here, it is the proc-xen.mount
target which is now broken by the change in systemd behaviour.

~Andrew`

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

[Olaf Hering]

On Thu, Oct 26, Andrew Cooper wrote:

> Can't all information be obtained from /sys/hypervisor?  If not, how
> hard would it be to make happen?

Likely not that hard. Not sure why that was not added in the first place.

> What happens to all the software which currently has a dependency on
> proc-xen.mount ?

All software gets converted by this change.

> Independently, how does this interact with having a xenfs entries in
> /etc/fstab, which might plausibly still exist for compatibility with
> other init systems?

mount(1) will continue to consider them.


Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 for-next 02/12] pci: introduce a type to store a SBDF

[Jan Beulich]

>>> On 18.10.17 at 13:40,  wrote:
> That provides direct access to all the members that constitute a SBDF.
> The only function switched to use it is hvm_pci_decode_addr, because
> it makes following patches simpler.
> 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Paul Durrant 

Acked-by: Jan Beulich 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v12 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

[Jan Beulich]

>>> On 17.10.17 at 15:24,  wrote:
> v12:
>  - Dropped limit checks as requested by Jan.

Thanks, but ...

> +int gnttab_get_status_frame(struct domain *d, unsigned long idx,
> +mfn_t *mfn)
> +{
> +struct grant_table *gt = d->grant_table;
> +int rc;
> +
> +/* write lock required as version may change and/or table may grow */
> +grant_write_lock(gt);
> +rc = gnttab_get_frame(d, idx | XENMAPIDX_grant_table_status, mfn);

... this ORing won't work then. You need to pass the function a
separate bool, which would likely call for a prereq patch.

> @@ -965,12 +966,49 @@ static long xatp_permission_check(struct domain *d, 
> unsigned int space)
>  return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
>  }
>  
> +static int acquire_grant_table(struct domain *d, unsigned int id,
> +   unsigned long frame,
> +   unsigned int nr_frames,
> +   unsigned long mfn_list[])
> +{
> +unsigned int i = nr_frames;
> +
> +/* Iterate backwards in case table needs to grow */
> +while ( i-- != 0 )
> +{
> +mfn_t mfn = INVALID_MFN;
> +int rc;
> +
> +switch ( id )
> +{
> +case XENMEM_resource_grant_table_id_grant:
> +rc = gnttab_get_grant_frame(d, frame + i, );
> +break;
> +
> +case XENMEM_resource_grant_table_id_status:
> +rc = gnttab_get_status_frame(d, frame + i, );
> +break;
> +
> +default:
> +rc = -EINVAL;
> +break;
> +}
> +
> +if ( rc )
> +return rc;
> +
> +mfn_list[i] = mfn_x(mfn);
> +}
> +
> +return 0;
> +}
> +
>  static int acquire_resource(
>  XEN_GUEST_HANDLE_PARAM(xen_mem_acquire_resource_t) arg)
>  {
>  struct domain *d, *currd = current->domain;
>  xen_mem_acquire_resource_t xmar;
> -unsigned long mfn_list[2];
> +unsigned long mfn_list[32];

Together with the GFN array further down this makes up for 512
bytes of stack space, if my calculation wasn't wrong. That's quite
a lot and certainly something that shouldn't be further increased.
I can accept it remaining this way for now (provided ARM has a
large enough stack as well), but please add a comment indicating
that if further growth is needed, converting to e.g. per-CPU
arrays is going to be necessary.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

[Andrew Cooper]

On 26/10/17 16:25, Olaf Hering wrote:
> An upcoming change in systemd will mount xenfs right away, along with
> all other system mounts. This improves the detection of the
> virtualization environment, which is currently racy. Some parts of
> systemd rely on the presence of /proc/xen/capabilities, which will only
> exist if xenfs is mounted. Since xenfs is mounted by the proc-xen.mount
> unit, it will be processed very late. Other units may be processed
> earlier, and if they make use of ConditionVirtualization*= failures may
> occour.
>
> Unfortunately mounting xenfs by systemd as an API filesystem will lead
> to errors when proc-xen.mount is processed. Since that mount point
> already exists the unit is considered as failed, and other units that
> depend on proc-xen.mount will not start. To avoid this the existing
> proc-xen.mount will be converted into proc-xen.service, which just
> mounts xenfs manually. All dependencies are updated by this change.
>
> The existing conditionals in proc-xen.mount will prevent failures with
> existing systemd based installations:
> ConditionPathExists=!/proc/xen/capabilities will prevent execution with
> a new systemd that mounts xenfs. And this conditional, in combination
> with ConditionPathExists=/proc/xen, will trigger execution with an old
> systemd.
>
> An absolute path to the mount binary has to be used. /bin/mount is
> expected to be universally available, nowaways it is a symlink to
> /usr/bin/mount.
>
> Signed-off-by: Olaf Hering 

Can't all information be obtained from /sys/hypervisor?  If not, how
hard would it be to make happen?

What happens to all the software which currently has a dependency on
proc-xen.mount ?

Independently, how does this interact with having a xenfs entries in
/etc/fstab, which might plausibly still exist for compatibility with
other init systems?

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen: fix booting ballooned down hvm guest

[HW42]

Juergen Gross:
> Commit 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't
> online new memory initially") introduced a regression when booting a
> HVM domain with memory less than mem-max: instead of ballooning down
> immediately the system would try to use the memory up to mem-max
> resulting in Xen crashing the domain.
> 
> For HVM domains the current size will be reflected in Xenstore node
> memory/static-max instead of memory/target.
> 
> Additionally we have to trigger the ballooning process at once.
> 
> Cc:  # 4.13
> Fixes: 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't
>online new memory initially")
> 
> Reported-by: Simon Gaiser 
> Suggested-by: Boris Ostrovsky 
> Signed-off-by: Juergen Gross 

Fixes the issues for me. Thanks.



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Jan Beulich]

>>> On 26.10.17 at 17:32,  wrote:
> On 26/10/17 16:26, Jan Beulich wrote:
> On 17.10.17 at 15:24,  wrote:
>>> +/* IN/OUT - If the tools domain is PV then, upon return, frame_list
>>> + *  will be populated with the MFNs of the resource.
>>> + *  If the tools domain is HVM then it is expected that, on
>>> + *  entry, frame_list will be populated with a list of GFNs
>>> + *  that will be mapped to the MFNs of the resource.
>>> + *  If -EIO is returned then the frame_list has only been
>>> + *  partially mapped and it is up to the caller to unmap all
>>> + *  the GFNs.
>>> + *  This parameter may be NULL if nr_frames is 0.
>>> + */
>>> +XEN_GUEST_HANDLE(xen_ulong_t) frame_list;
>> 
>> This is still xen_ulong_t, which I can live with, but then you shouldn't
>> copy into / out of arrays of other types in acquire_resource() (the
>> more that this is common code, and iirc xen_ulong_t and
>> unsigned long aren't the same thing on ARM32).
> 
> xen_ulong_t is always 64-bit on Arm (32-bit and 64-bit). But shouldn't 
> we use xen_pfn_t here?

I had put this question up earlier, but iirc Paul didn't like it.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-next] x86/pv: Factor out the calculation of LDT/GDT descriptor pointers

[Andrew Cooper]

On 26/10/17 16:06, Jan Beulich wrote:
 On 17.10.17 at 17:05,  wrote:
>> @@ -16,4 +17,14 @@ static inline int pv_emul_is_mem_write(const struct 
>> x86_emulate_state *state,
>>: X86EMUL_UNHANDLEABLE;
>>  }
>>  
>> +/* Return a pointer to the GDT/LDT descriptor referenced by sel. */
>> +static inline const struct desc_struct *gdt_ldt_desc_ptr(unsigned int sel)
> I guess returning a pointer to const here is on the assumption that
> you hope we would never have a need to fiddle with the descriptor?

PV guests only have a single method to alter the entries of exiting
descriptor tables, HYPERVISOR_update_descriptor(), and that is indexed
by machine address.

We don't even support updates via emulation, and I don't expect this to
change moving forwards.

Of course, we can drop the const if things do change in the future.

>
>> +{
>> +const struct vcpu *curr = current;
>> +const struct desc_struct *tbl = (void *)
>> +((sel & X86_XEC_TI) ? LDT_VIRT_START(curr) : GDT_VIRT_START(curr));
> While the two happen to match, using an error code related
> constant with something named "selector" doesn't look to be
> really correct. But given the match, I don't mind it being this
> way.
>
> Acked-by: Jan Beulich 

Thanks.

As some point, I was thinking of moving some of my XTF x86 library into
Xen, and clean up the multiple/inconsistent definitions we have of
various architectural bits, but that is a job for a different day.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v12 06/11] x86/hvm/ioreq: add a new mappable resource type...

[Jan Beulich]

>>> On 17.10.17 at 15:24,  wrote:
> @@ -777,6 +887,52 @@ int hvm_get_ioreq_server_info(struct domain *d, 
> ioservid_t id,
>  return rc;
>  }
>  
> +int hvm_get_ioreq_server_frame(struct domain *d, ioservid_t id,

There's another silent truncation issue here: Iirc ioservid_t is 16 bits.

> @@ -3866,6 +3867,27 @@ int xenmem_add_to_physmap_one(
>  return rc;
>  }
>  
> +int xenmem_acquire_ioreq_server(struct domain *d, unsigned int id,
> +unsigned long frame,
> +unsigned int nr_frames,
> +unsigned long mfn_list[])
> +{
> +unsigned int i;
> +
> +for ( i = 0; i < nr_frames; i++ )
> +{
> +mfn_t mfn;
> +int rc = hvm_get_ioreq_server_frame(d, id, frame + i, );

The caller here holds a 32-bit quantity in its hands, though. With
the upper half suitably checked in either place

Reviewed-by: Jan Beulich 

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Julien Grall]

On 26/10/17 16:26, Jan Beulich wrote:

On 17.10.17 at 15:24,  wrote:

+/* IN/OUT - If the tools domain is PV then, upon return, frame_list
+ *  will be populated with the MFNs of the resource.
+ *  If the tools domain is HVM then it is expected that, on
+ *  entry, frame_list will be populated with a list of GFNs
+ *  that will be mapped to the MFNs of the resource.
+ *  If -EIO is returned then the frame_list has only been
+ *  partially mapped and it is up to the caller to unmap all
+ *  the GFNs.
+ *  This parameter may be NULL if nr_frames is 0.
+ */
+XEN_GUEST_HANDLE(xen_ulong_t) frame_list;


This is still xen_ulong_t, which I can live with, but then you shouldn't
copy into / out of arrays of other types in acquire_resource() (the
more that this is common code, and iirc xen_ulong_t and
unsigned long aren't the same thing on ARM32).


xen_ulong_t is always 64-bit on Arm (32-bit and 64-bit). But shouldn't 
we use xen_pfn_t here?


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Jan Beulich]

>>> On 17.10.17 at 15:24,  wrote:
> @@ -535,6 +588,48 @@ int compat_memory_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) compat)
>  rc = -EFAULT;
>  break;
>  
> +case XENMEM_acquire_resource:
> +{
> +const xen_ulong_t *xen_frame_list =
> +(xen_ulong_t *)(nat.mar + 1);
> +compat_ulong_t *compat_frame_list =
> +(compat_ulong_t *)(nat.mar + 1);
> +
> +if ( cmp.mar.nr_frames == 0 )

Doesn't this need to be compat_handle_is_null(cmp.mar.frame_list), or
a combination of both?

> +{
> +DEFINE_XEN_GUEST_HANDLE(compat_mem_acquire_resource_t);
> +
> +if ( __copy_field_to_guest(
> + guest_handle_cast(compat,
> +   compat_mem_acquire_resource_t),
> + , nr_frames) )
> +return -EFAULT;
> +}
> +else
> +{
> +/*
> + * NOTE: the smaller compat array overwrites the native
> + *   array.
> + */

I think I had already asked for a respective BUILD_BUG_ON().

> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -965,6 +965,95 @@ static long xatp_permission_check(struct domain *d, 
> unsigned int space)
>  return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
>  }
>  
> +static int acquire_resource(
> +XEN_GUEST_HANDLE_PARAM(xen_mem_acquire_resource_t) arg)
> +{
> +struct domain *d, *currd = current->domain;
> +xen_mem_acquire_resource_t xmar;
> +unsigned long mfn_list[2];
> +int rc;
> +
> +if ( copy_from_guest(, arg, 1) )
> +return -EFAULT;
> +
> +if ( xmar.pad != 0 )
> +return -EINVAL;
> +
> +if ( guest_handle_is_null(xmar.frame_list) )
> +{
> +/* Special case for querying implementation limit */
> +if ( xmar.nr_frames == 0 )

Perhaps invert the condition to reduce ...

> +{
> +xmar.nr_frames = ARRAY_SIZE(mfn_list);
> +
> +if ( __copy_field_to_guest(arg, , nr_frames) )
> +return -EFAULT;
> +
> +return 0;
> +}

... overall indentation?

> +return -EINVAL;
> +}
> +
> +if ( xmar.nr_frames == 0 )
> +return -EINVAL;

Why? (Almost?) everywhere else zero counts are simply no-ops, which
result in success returns.

> +if ( xmar.nr_frames > ARRAY_SIZE(mfn_list) )
> +return -E2BIG;
> +
> +d = rcu_lock_domain_by_any_id(xmar.domid);

This being a tools only interface, why "by_any_id" instead of
"remote_domain_by_id"? In particular ...

> +if ( d == NULL )
> +return -ESRCH;
> +
> +rc = xsm_domain_resource_map(XSM_DM_PRIV, d);

... an unprivileged dm domain should probably not be permitted to
invoke this on itself.

> +if ( rc )
> +goto out;
> +
> +switch ( xmar.type )
> +{
> +default:
> +rc = -EOPNOTSUPP;
> +break;
> +}
> +
> +if ( rc )
> +goto out;
> +
> +if ( !paging_mode_translate(currd) )
> +{
> +if ( copy_to_guest(xmar.frame_list, mfn_list, xmar.nr_frames) )
> +rc = -EFAULT;
> +}
> +else
> +{
> +xen_pfn_t gfn_list[ARRAY_SIZE(mfn_list)];
> +unsigned int i;
> +
> +rc = -EFAULT;
> +if ( copy_from_guest(gfn_list, xmar.frame_list, xmar.nr_frames) )
> +goto out;
> +
> +for ( i = 0; i < xmar.nr_frames; i++ )
> +{
> +rc = set_foreign_p2m_entry(currd, gfn_list[i],
> +   _mfn(mfn_list[i]));
> +if ( rc )
> +{
> +/*
> + * Make sure rc is -EIO for any interation other than
> + * the first.

"iteration", but why is this important in the first place?

> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -599,6 +599,47 @@ struct xen_reserved_device_memory_map {
>  typedef struct xen_reserved_device_memory_map 
> xen_reserved_device_memory_map_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t);
>  
> +/*
> + * Get the pages for a particular guest resource, so that they can be
> + * mapped directly by a tools domain.
> + */
> +#define XENMEM_acquire_resource 28
> +struct xen_mem_acquire_resource {
> +/* IN - the domain whose resource is to be mapped */
> +domid_t domid;
> +/* IN - the type of resource */
> +uint16_t type;
> +/*
> + * IN - a type-specific resource identifier, which must be zero
> + *  unless stated otherwise.
> + */
> +uint32_t id;
> +/* IN/OUT - As an IN parameter number of frames of the resource
> + *  to be mapped. However, if the specified value is 0 and
> + *  frame_list is NULL then this field will be set to the
> + *  maximum value supported by 

[Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

[Olaf Hering]

An upcoming change in systemd will mount xenfs right away, along with
all other system mounts. This improves the detection of the
virtualization environment, which is currently racy. Some parts of
systemd rely on the presence of /proc/xen/capabilities, which will only
exist if xenfs is mounted. Since xenfs is mounted by the proc-xen.mount
unit, it will be processed very late. Other units may be processed
earlier, and if they make use of ConditionVirtualization*= failures may
occour.

Unfortunately mounting xenfs by systemd as an API filesystem will lead
to errors when proc-xen.mount is processed. Since that mount point
already exists the unit is considered as failed, and other units that
depend on proc-xen.mount will not start. To avoid this the existing
proc-xen.mount will be converted into proc-xen.service, which just
mounts xenfs manually. All dependencies are updated by this change.

The existing conditionals in proc-xen.mount will prevent failures with
existing systemd based installations:
ConditionPathExists=!/proc/xen/capabilities will prevent execution with
a new systemd that mounts xenfs. And this conditional, in combination
with ConditionPathExists=/proc/xen, will trigger execution with an old
systemd.

An absolute path to the mount binary has to be used. /bin/mount is
expected to be universally available, nowaways it is a symlink to
/usr/bin/mount.

Signed-off-by: Olaf Hering 
---

based on 4.10.0-rc2
Please run autogen.sh:

 tools/configure.ac| 2 +-
 tools/hotplug/Linux/systemd/Makefile  | 6 +++---
 .../Linux/systemd/{proc-xen.mount.in => proc-xen.service.in}  | 8 
 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in| 4 ++--
 tools/hotplug/Linux/systemd/xen-init-dom0.service.in  | 4 ++--
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 4 ++--
 tools/hotplug/Linux/systemd/xen-watchdog.service.in   | 4 ++--
 tools/hotplug/Linux/systemd/xenconsoled.service.in| 4 ++--
 tools/hotplug/Linux/systemd/xendomains.service.in | 4 ++--
 tools/hotplug/Linux/systemd/xendriverdomain.service.in| 4 ++--
 tools/hotplug/Linux/systemd/xenstored.service.in  | 6 +++---
 11 files changed, 25 insertions(+), 25 deletions(-)
 rename tools/hotplug/Linux/systemd/{proc-xen.mount.in => proc-xen.service.in} 
(60%)

diff --git a/tools/configure.ac b/tools/configure.ac
index d1a3a78d87..7b18421fa0 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -441,7 +441,7 @@ AX_AVAILABLE_SYSTEMD()
 
 AS_IF([test "x$systemd" = "xy"], [
 AC_CONFIG_FILES([
-hotplug/Linux/systemd/proc-xen.mount
+hotplug/Linux/systemd/proc-xen.service
 hotplug/Linux/systemd/var-lib-xenstored.mount
 hotplug/Linux/systemd/xen-init-dom0.service
 hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service
diff --git a/tools/hotplug/Linux/systemd/Makefile 
b/tools/hotplug/Linux/systemd/Makefile
index a5d41d86ef..855ff3747f 100644
--- a/tools/hotplug/Linux/systemd/Makefile
+++ b/tools/hotplug/Linux/systemd/Makefile
@@ -3,10 +3,10 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 XEN_SYSTEMD_MODULES = xen.conf
 
-XEN_SYSTEMD_MOUNT =  proc-xen.mount
-XEN_SYSTEMD_MOUNT += var-lib-xenstored.mount
+XEN_SYSTEMD_MOUNT  = var-lib-xenstored.mount
 
-XEN_SYSTEMD_SERVICE  = xenstored.service
+XEN_SYSTEMD_SERVICE  = proc-xen.service
+XEN_SYSTEMD_SERVICE += xenstored.service
 XEN_SYSTEMD_SERVICE += xenconsoled.service
 XEN_SYSTEMD_SERVICE += xen-qemu-dom0-disk-backend.service
 XEN_SYSTEMD_SERVICE += xendomains.service
diff --git a/tools/hotplug/Linux/systemd/proc-xen.mount.in 
b/tools/hotplug/Linux/systemd/proc-xen.service.in
similarity index 60%
rename from tools/hotplug/Linux/systemd/proc-xen.mount.in
rename to tools/hotplug/Linux/systemd/proc-xen.service.in
index 64ebe7f9b1..76f0097b75 100644
--- a/tools/hotplug/Linux/systemd/proc-xen.mount.in
+++ b/tools/hotplug/Linux/systemd/proc-xen.service.in
@@ -4,7 +4,7 @@ ConditionPathExists=/proc/xen
 ConditionPathExists=!/proc/xen/capabilities
 RefuseManualStop=true
 
-[Mount]
-What=xenfs
-Where=/proc/xen
-Type=xenfs
+[Service]
+Type=oneshot
+RemainAfterExit=true
+ExecStart=/bin/mount -t xenfs xenfs /proc/xen
diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in 
b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
index 11a7d50edc..5d171f82e8 100644
--- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
+++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=mount xenstore file system
-Requires=proc-xen.mount
-After=proc-xen.mount
+Requires=proc-xen.service
+After=proc-xen.service
 ConditionPathExists=/proc/xen/capabilities
 RefuseManualStop=true
 
diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in 
b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
index 3befadcea3..c560fbe1b7 100644
--- 

[Xen-devel] [PATCH] osstest: set arch before calling set_freebsd_runvars

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
---
 make-flight | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/make-flight b/make-flight
index d595101c..76620c18 100755
--- a/make-flight
+++ b/make-flight
@@ -676,6 +676,8 @@ do_examine_one () {
 *) return  ;; # stuff used for guests is irrelevant
   esac
   local freebsd_runvars
+  # set_freebsd_runvars expects $arch to be set to the desired FreeBSD arch.
+  local arch=$dom0arch
   set_freebsd_runvars
   job_create_test test-$xenarch$kern-$dom0arch-examine \
   host-examine-xen xl $xenarch $dom0arch \
-- 
2.13.5 (Apple Git-94)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-next 8/9] xsm: add bodge when compiling with llvm coverage support

[Daniel De Graaf]

On 10/26/2017 05:19 AM, Roger Pau Monne wrote:

llvm coverage support seems to disable some of the optimizations
needed in order to compile xsm, and the end result is that references
to __xsm_action_mismatch_detected are left in the object files.

Since coverage support cannot be used in production, introduce
__xsm_action_mismatch_detected for llvm coverage builds.

Signed-off-by: Roger Pau Monné 


Acked-by: Daniel De Graaf 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-next] x86/pv: Factor out the calculation of LDT/GDT descriptor pointers

[Jan Beulich]

>>> On 17.10.17 at 17:05,  wrote:
> @@ -16,4 +17,14 @@ static inline int pv_emul_is_mem_write(const struct 
> x86_emulate_state *state,
>: X86EMUL_UNHANDLEABLE;
>  }
>  
> +/* Return a pointer to the GDT/LDT descriptor referenced by sel. */
> +static inline const struct desc_struct *gdt_ldt_desc_ptr(unsigned int sel)

I guess returning a pointer to const here is on the assumption that
you hope we would never have a need to fiddle with the descriptor?

> +{
> +const struct vcpu *curr = current;
> +const struct desc_struct *tbl = (void *)
> +((sel & X86_XEC_TI) ? LDT_VIRT_START(curr) : GDT_VIRT_START(curr));

While the two happen to match, using an error code related
constant with something named "selector" doesn't look to be
really correct. But given the match, I don't mind it being this
way.

Acked-by: Jan Beulich 

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-4.5-testing test] 115226: tolerable FAIL - PUSHED

[osstest service owner]

flight 115226 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115226/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail in 115191 pass 
in 115226
 test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail in 115191 
pass in 115226
 test-armhf-armhf-xl-vhd 10 debian-di-install fail in 115191 pass in 115226
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
115191

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 12 guest-start fail blocked in 114423
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 115191 blocked 
in 114423
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 115191 
like 114423
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 115191 like 114423
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 115191 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 115191 never pass
 test-amd64-amd64-xl-rtds  7 xen-boot fail  like 114423
 test-xtf-amd64-amd64-2   60 leak-check/check fail  like 114423
 test-xtf-amd64-amd64-3   60 leak-check/check fail  like 114423
 test-xtf-amd64-amd64-4   60 leak-check/check fail  like 114423
 test-xtf-amd64-amd64-1   60 leak-check/check fail  like 114423
 test-xtf-amd64-amd64-5   60 leak-check/check fail  like 114423
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114423
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114423
 test-xtf-amd64-amd64-2   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-3   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-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-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 guest-start  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-armhf-armhf-libvirt-raw 11 guest-start  fail  

Re: [Xen-devel] [Qemu-devel] [PATCH] x86: Skip check apic_id_limit for Xen

[Michael S. Tsirkin]

On Thu, Oct 26, 2017 at 02:19:43PM +0200, Eduardo Habkost wrote:
> On Mon, Aug 21, 2017 at 10:22:15AM +0800, Lan Tianyu wrote:
> > On 2017年08月19日 00:38, Eduardo Habkost wrote:
> > > On Thu, Aug 17, 2017 at 09:37:10AM +0800, Lan Tianyu wrote:
> > >> On 2017年08月16日 19:21, Paolo Bonzini wrote:
> > >>> On 16/08/2017 02:22, Lan Tianyu wrote:
> >  Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
> >  check for Xen here when vcpu number is more than 255.
> > >>>
> > >>> I think you still need to do a check for vIOMMU being enabled.
> > >>
> > >> Yes, this will be done in the Xen tool stack and Qemu doesn't have such
> > >> knowledge. Operations of create, destroy Xen vIOMMU will be done in the
> > >> Xen tool stack.
> > > 
> > > Shouldn't we make QEMU have knowledge of the vIOMMU device, then?
> > > Won't QEMU need to know about it eventually?
> > > 
> > 
> > Hi Eduardo:
> >  Thanks for your review.
> >  Xen has some guest modes which doesn't use Qemu and we tried to
> > make Xen vIOMMU framework compatible with all guest modes. So far, we
> > are adding interrupt remapping function for Xen vIOMMU and find qemu
> > doesn't need to know Xen vIOMMU. The check of vcpu number > 255 here
> > will be done in Xen side and so skip the check in Qemu to avoid blocking
> > Xen creating >255 vcpus.
> >  We may make Qemu have knowledge of the vIOMMU device if it's
> > necessary when adding new function.
> 
> I was expecting it to go through the PC tree, but I will queue it
> on x86-next instead.

I was waiting for an ack from you or Paolo as you participated in the
discussion. But sure, go ahead

Acked-by: Michael S. Tsirkin 



> -- 
> Eduardo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen: fix booting ballooned down hvm guest

[Boris Ostrovsky]

On 10/26/2017 05:50 AM, Juergen Gross wrote:
> Commit 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't
> online new memory initially") introduced a regression when booting a
> HVM domain with memory less than mem-max: instead of ballooning down
> immediately the system would try to use the memory up to mem-max
> resulting in Xen crashing the domain.
>
> For HVM domains the current size will be reflected in Xenstore node
> memory/static-max instead of memory/target.
>
> Additionally we have to trigger the ballooning process at once.
>
> Cc:  # 4.13
> Fixes: 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't
>online new memory initially")
>
> Reported-by: Simon Gaiser 
> Suggested-by: Boris Ostrovsky 
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 12/13] xen/pvcalls: implement release command

[Boris Ostrovsky]

On 10/25/2017 07:00 PM, Stefano Stabellini wrote:
> On Wed, 25 Oct 2017, Boris Ostrovsky wrote:
>> On 10/24/2017 01:33 PM, Stefano Stabellini wrote:
>>> Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
>>> in_mutex and out_mutex to avoid concurrent accesses. Then, free the
>>> socket.
>>>
>>> For passive sockets, check whether we have already pre-allocated an
>>> active socket for the purpose of being accepted. If so, free that as
>>> well.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>>> ---
>>>  drivers/xen/pvcalls-front.c | 100 
>>> 
>>>  drivers/xen/pvcalls-front.h |   1 +
>>>  2 files changed, 101 insertions(+)
>>>
>>> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
>>> index 4a413ff..7abc039 100644
>>> --- a/drivers/xen/pvcalls-front.c
>>> +++ b/drivers/xen/pvcalls-front.c
>>> @@ -199,6 +199,23 @@ static irqreturn_t pvcalls_front_event_handler(int 
>>> irq, void *dev_id)
>>>  static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
>>>struct sock_mapping *map, bool locked)
>>>  {
>>> +   int i;
>>> +
>>> +   unbind_from_irqhandler(map->active.irq, map);
>>> +
>>> +   if (!locked)
>>> +   spin_lock(>socket_lock);
>>> +   if (!list_empty(>list))
>>> +   list_del_init(>list);
>>> +   if (!locked)
>>> +   spin_unlock(>socket_lock);
>>> +
>>> +   for (i = 0; i < (1 << PVCALLS_RING_ORDER); i++)
>>> +   gnttab_end_foreign_access(map->active.ring->ref[i], 0, 0);
>>> +   gnttab_end_foreign_access(map->active.ref, 0, 0);
>>> +   free_page((unsigned long)map->active.ring);
>>> +
>>> +   kfree(map);
>>>  }
>>>  
>>>  static irqreturn_t pvcalls_front_conn_handler(int irq, void *sock_map)
>>> @@ -966,6 +983,89 @@ unsigned int pvcalls_front_poll(struct file *file, 
>>> struct socket *sock,
>>> return ret;
>>>  }
>>>  
>>> +int pvcalls_front_release(struct socket *sock)
>>> +{
>>> +   struct pvcalls_bedata *bedata;
>>> +   struct sock_mapping *map;
>>> +   int req_id, notify, ret;
>>> +   struct xen_pvcalls_request *req;
>>> +
>> ..
>>
>>> +
>>> +   if (map->active_socket) {
>>> +   /*
>>> +* Set in_error and wake up inflight_conn_req to force
>>> +* recvmsg waiters to exit.
>>> +*/
>>> +   map->active.ring->in_error = -EBADF;
>>> +   wake_up_interruptible(>active.inflight_conn_req);
>>> +
>>> +   /*
>>> +* Wait until there are no more waiters on the mutexes.
>>> +* We know that no new waiters can be added because sk_send_head
>>> +* is set to NULL -- we only need to wait for the existing
>>> +* waiters to return.
>>> +*/
>>> +   while (!mutex_trylock(>active.in_mutex) ||
>>> +  !mutex_trylock(>active.out_mutex))
>>> +   cpu_relax();
>>> +
>>> +   pvcalls_front_free_map(bedata, map, false);
>>> +   } else {
>>> +   spin_lock(>socket_lock);
>>> +   if (READ_ONCE(map->passive.inflight_req_id) !=
>>> +   PVCALLS_INVALID_ID) {
>>> +   pvcalls_front_free_map(bedata,
>>> +  map->passive.accept_map, true);
>>> +   }
>>> +   list_del(>list);
>>> +   kfree(map);
>>> +   spin_unlock(>socket_lock);
>> We have different locking rules in pvcalls_front_free_map() for each of
>> those clauses in that in the first case we are doing grant table
>> operations and free_page() without the lock and in the second case we
>> are holding it. Is it possible to restructure this so that we prune the
>> lists under the lock (possibly in this routine) and call
>> pvcalls_front_free_map() lock-less?
> Yes, it is possible. However, pvcalls_front_free_map is called from a
> couple of other places (pvcalls_front_accept and pvcalls_front_remove)
> and we would have to add the code to remove the map from the list there
> as well. I am not sure it is worth it.
>
> I don't have a strong opinion on this. Let me know which way you prefer.


I didn't realize this is called from multiple places.

How about

spin_lock(>socket_lock);
if (READ_ONCE(map->passive.inflight_req_id) !=
PVCALLS_INVALID_ID) {
 if (!list_empty(>passive.accept_map->list))
list_del(>passive.accept_map->list);
}
list_del(>list);
spin_unlock(>socket_lock);

pvcalls_front_free_map(bedata, map->passive.accept_map, true);
kfree(map); 


(I may have messed up list pointers here)

This would be slightly inefficient in that you drop the lock and then grab it 
again (only to find that the list is empty, presumably) but it makes 
pvcalls_front_free_map()'s behavior more consistent wrt locking. (Or maybe you 
will need to pass a bool to pvcalls_front_free_map() to indicate whether the 
map needs to be removed from the list for other call 

[Xen-devel] [qemu-mainline test] 115228: regressions - FAIL

[osstest service owner]

flight 115228 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115228/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 114507
 build-amd64-xsm   6 xen-buildfail REGR. vs. 114507
 build-i386-xsm6 xen-buildfail REGR. vs. 114507
 build-amd64   6 xen-buildfail REGR. vs. 114507
 build-armhf-xsm   6 xen-buildfail REGR. vs. 114507
 build-armhf   6 xen-buildfail REGR. vs. 114507

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 

Re: [Xen-devel] [PATCH 0/6] Intel Processor Trace virtulization enabling

[Andrew Cooper]

On 26/10/17 05:13, Kang, Luwei wrote:
>>> Hi All,
>>>
>>> Here is a patch-series which adding Processor Trace enabling in XEN guest. 
>>> You can get It's software developer manuals from:
>>> https://software.intel.com/sites/default/files/managed/c5/15/architect
>>> ure-instruction-set-extensions-programming-reference.pdf
>>> In Chapter 5 INTEL PROCESSOR TRACE: VMX IMPROVEMENTS.
>>>
>>> Introduction:
>>> Intel Processor Trace (Intel PT) is an extension of Intel Architecture that 
>>> captures information about software execution using
>> dedicated hardware facilities that cause only minimal performance 
>> perturbation to the software being traced. Details on the Intel PT
>> infrastructure and trace capabilities can be found in the Intel 64 and IA-32 
>> Architectures Software Developer’s Manual, Volume 3C.
>>> The suite of architecture changes serve to simplify the process of 
>>> virtualizing Intel PT for use by a guest software. There are two
>> primary elements to this new architecture support for VMX support 
>> improvements made for Intel PT.
>>> 1. Addition of a new guest IA32_RTIT_CTL value field to the VMCS.
>>>   — This serves to speed and simplify the process of disabling trace on VM 
>>> exit, and restoring it on VM entry.
>>> 2. Enabling use of EPT to redirect PT output.
>>>   — This enables the VMM to elect to virtualize the PT output buffer using 
>>> EPT. In this mode, the CPU will treat PT output
>> addresses as Guest Physical Addresses (GPAs) and translate them using EPT. 
>> This means that Intel PT output reads (of the ToPA
>> table) and writes (of trace output) can cause EPT violations, and other 
>> output events.
>>
>> Hello,
>>
>> Having read the new proposed extensions, I've got some architecture 
>> questions before diving into the patches themselves.
>>
>> First of all, is this technology expected to end up in Icelake, or something 
>> later?
> Yes, this would be enabled on Icelake.

Thanks.

>
>> In Vol 3, the existing VMX support describes a number of scenarios (system 
>> wide, VMM-only, VM-only, guest aware), which require
>> the use of MSR load lists to atomically alter the IA32_RTIT_* msrs.
> Currently, I just enabling the guest only mode(VM-only) in my patches.

That is fine.  I'm not asking you to implement these modes; I am just
trying to work out how they would interact.

>
>> Obviously, system wide mode is incompatible with also allowing the guest to 
>> use PT itself, 
> Yes, system mode(collect trace packets of the entire system) can't work with 
> guest only mode at the same time.
>
>> but what about Xen wanting to use PT for itself, and for the guest to use PT 
>> as well?
> I think this can be named by host-guest mode. This may need add new command 
> or interface to enable PT in Xen hypervisor. Trace vmm-only and guest 
> simultaneous and output to their respective buffer.
>
>> Previously, this appears to be possible using the MSR load lists (albeit 
>> with Xen needing to shadow the ToPA records to cause the
>> packet stream to end up in the right place).
> Yes.
>
>> However, the new VM consistency checks require that using EPT redirection 
>> requires clear/load CTL on exit/entry be set, and having
>> load on entry set requires the host TraceEn to be clear.
> Yes. New bits added in VMCS can make sure PT be disabled before VM exit and 
> IA32_RTIT_CTL MSR will be written with the value of the associated Guest 
> State field of the VMCS on VM entry.

I am not sure I explained myself clearly.

It appears that it is possible to implement host-guest mode using MSR
load lists, because all the host configuration gets replaced by guest
configuration on vmentry, and host configuration gets restored at vmexit.

However with these PT extension, a new restriction is that a vmentry
failure will occur if we try to load the guest RTIT_CTL value while the
current RTIT_CTL.TraceEn is set.

As far as I can tell, this prohibits host-guest mode from working,
unless we tolerate having Xen clear RTIT_CTL before restoring guest GPR
state.

Is this correct, or have I missed something?

Thanks,

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-4.9-testing baseline-only test] 72352: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72352 xen-4.9-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72352/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64 11 guest-startfail REGR. vs. 72340
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
72340

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail blocked in 72340
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail blocked 
in 72340
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail like 72340
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10  fail like 72340
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 72340
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 72340
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-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-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-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-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  61b6df9d821481ba4e26e5843aa9320345077319
baseline version:
 xen  2040ac14e4cfbae679751796266527d92d11ac78

Last test of basis72340  2017-10-22 21:48:56 Z3 days
Testing same since72352  2017-10-26 05:56:41 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

[Xen-devel] [linux-next test] 115211: regressions - FAIL

[osstest service owner]

flight 115211 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115211/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-examine  7 reboot   fail REGR. vs. 114658
 test-armhf-armhf-xl-arndale   7 xen-boot fail REGR. vs. 114682
 build-amd64-pvops 6 kernel-build fail REGR. vs. 114682
 test-armhf-armhf-xl-xsm   7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-xl-credit2   7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-xl-vhd   7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-libvirt-xsm  7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-libvirt-raw  7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-libvirt  7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-xl-cubietruck  7 xen-boot   fail REGR. vs. 114682
 test-armhf-armhf-xl-multivcpu  7 xen-bootfail REGR. vs. 114682

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm 5 host-ping-check-native fail in 115131 pass in 
115211
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail pass in 115131

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  7 xen-boot fail REGR. vs. 114682

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-examine  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114682
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 114682
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-i386-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

version targeted for testing:
 linux36ef71cae353f88fd6e095e2aaa3e5953af1685d
baseline version:
 linux  

Re: [Xen-devel] [PATCH V3 8/29] tools/libxl: create vIOMMU during domain construction

[Wei Liu]

On Thu, Oct 19, 2017 at 11:13:57AM +0100, Roger Pau Monné wrote:
> > +
> > +if (viommu->type == LIBXL_VIOMMU_TYPE_INTEL_VTD) {
> > +ret = xc_viommu_create(ctx->xch, domid, 
> > VIOMMU_TYPE_INTEL_VTD,
> > +   viommu->base_addr, viommu->cap, 
> > );
> 
> As said in another patch: this will break compilation because
> xc_viommu_create is introduced in patch 9.
> 
> Please organize the patches in a way that the code always compiles and
> works fine. Keep in mind that the Xen tree should be bisectable
> always.
> 

+10 to this.

We rely heavily on our test system's bisector to tell us what is wrong.
The bisector works on patch level. Please make sure every patch builds,
otherwise the test system will just give up.

If triaging can be done automatically by computers, maintainers can
spend less time doing tedious work and more time reviewing patches
(yours included).

Normally I use git-rebase to build every commit, but I figured that's a
bit too dangerous so I wrote a script.

Please check out:

  [PATCH v3 for-4.10] scripts: introduce a script for build test

It is still under review, but you can fish out some of the runes to do
build tests.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH] x86: Skip check apic_id_limit for Xen

[Eduardo Habkost]

On Mon, Aug 21, 2017 at 10:22:15AM +0800, Lan Tianyu wrote:
> On 2017年08月19日 00:38, Eduardo Habkost wrote:
> > On Thu, Aug 17, 2017 at 09:37:10AM +0800, Lan Tianyu wrote:
> >> On 2017年08月16日 19:21, Paolo Bonzini wrote:
> >>> On 16/08/2017 02:22, Lan Tianyu wrote:
>  Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
>  check for Xen here when vcpu number is more than 255.
> >>>
> >>> I think you still need to do a check for vIOMMU being enabled.
> >>
> >> Yes, this will be done in the Xen tool stack and Qemu doesn't have such
> >> knowledge. Operations of create, destroy Xen vIOMMU will be done in the
> >> Xen tool stack.
> > 
> > Shouldn't we make QEMU have knowledge of the vIOMMU device, then?
> > Won't QEMU need to know about it eventually?
> > 
> 
> Hi Eduardo:
>  Thanks for your review.
>  Xen has some guest modes which doesn't use Qemu and we tried to
> make Xen vIOMMU framework compatible with all guest modes. So far, we
> are adding interrupt remapping function for Xen vIOMMU and find qemu
> doesn't need to know Xen vIOMMU. The check of vcpu number > 255 here
> will be done in Xen side and so skip the check in Qemu to avoid blocking
> Xen creating >255 vcpus.
>  We may make Qemu have knowledge of the vIOMMU device if it's
> necessary when adding new function.

I was expecting it to go through the PC tree, but I will queue it
on x86-next instead.

-- 
Eduardo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 5/5 v2] xenconsole: Define and use a macro XEN_INVALID_PFN instead of -1

[Wei Liu]

On Wed, Oct 25, 2017 at 02:57:08PM +0530, Bhupinder Thakur wrote:
> xenconsole will use a new macro XEN_INVALID_PFN instead of -1 for 
> initializing ring-ref.

Can you please paste in the error if the compilation fails with -1?

The way this series is arranged make me wonder if the compilation is
broken half way. We should avoid that.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/5 v2] xenconsole: Change the type of ring_ref to xen_pfn_t in console_create_ring

[Wei Liu]

On Wed, Oct 25, 2017 at 02:57:07PM +0530, Bhupinder Thakur wrote:
> Currently, ring_ref is read as an integer in console_create_ring which could 
> lead to
> truncation of the value as it is reading a 64-bit value.
> 
> The fix is to modify the type of ring_ref to xen_pfn_t and use the correct 
> format
> specifier to read the value correctly for all architectures.
> 
> Signed-off-by: Bhupinder Thakur 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/5 v2] libxc: Fix the data type of mfn parameter passed to xc_map_foreign_range()

[Wei Liu]

On Wed, Oct 25, 2017 at 02:57:06PM +0530, Bhupinder Thakur wrote:
> Currently the data type of mfn parameter passed to xc_map_foreign_range() is 
> unsigned
> long. This could be problem for 32-bit arm architectures where the lengh of 
> long is
> 32 bits while mfn happens to be a 64-bit value.
> 
> To avoid truncating a 64-bit value, the type of mfn is changed from "unsigned 
> long" to
> xen_pfn_t. Also the parameter name "mfn" is changed to "pfn" which is a more 
> accurate
> indication of what this parameter represents.
> 
> Signed-off-by: Bhupinder Thakur 

Acked-by: Wei Liu 

But this should either come before #2 or be squashed into it.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/5 v2] libxl: Change the type of console_mfn to xen_pfn_t

[Andrew Cooper]

On 26/10/17 12:13, Wei Liu wrote:
> On Wed, Oct 25, 2017 at 02:57:05PM +0530, Bhupinder Thakur wrote:
>> Currently the type of console mfn is unsigned long in libxl. This may be
>> an issue for 32-bit toolstack running on 64-bit Xen, where the pfn are
>> 64 bit. To ensure that console_mfn can hold any valid 64-bit pfn, the
>> type of console_mfn is changed to xen_pfn_t.
>>
>> Signed-off-by: Bhupinder Thakur 
>> ---
>> CC: Ian Jackson 
>> CC: Wei Liu 
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>>
>> This patch is as per the review of commit fa1f157
>> libxl: Fix the bug introduced in commit "libxl: use correct type
>>
>>  tools/libxl/libxl_console.c  | 2 +-
>>  tools/libxl/libxl_dom.c  | 2 +-
>>  tools/libxl/libxl_internal.h | 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
>> index 6bfc0e5..f2ca689 100644
>> --- a/tools/libxl/libxl_console.c
>> +++ b/tools/libxl/libxl_console.c
>> @@ -329,7 +329,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t 
>> domid,
>>  flexarray_append(ro_front, "port");
>>  flexarray_append(ro_front, GCSPRINTF("%"PRIu32, 
>> state->console_port));
>>  flexarray_append(ro_front, "ring-ref");
>> -flexarray_append(ro_front, GCSPRINTF("%lu", state->console_mfn));
>> +flexarray_append(ro_front, GCSPRINTF("%"PRIu_xen_pfn, 
>> state->console_mfn));
> Actually, please consider changing console_mfn to console_pfn.

If you are going to make this change, then it is a gfn, not a pfn. 
(console_pfn would be as equally wrong for PV guests as console_mfn is
currently wrong for HVM guest.)

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/5 v2] libxl: Change the type of console_mfn to xen_pfn_t

[Wei Liu]

On Wed, Oct 25, 2017 at 02:57:05PM +0530, Bhupinder Thakur wrote:
> Currently the type of console mfn is unsigned long in libxl. This may be
> an issue for 32-bit toolstack running on 64-bit Xen, where the pfn are
> 64 bit. To ensure that console_mfn can hold any valid 64-bit pfn, the
> type of console_mfn is changed to xen_pfn_t.
> 
> Signed-off-by: Bhupinder Thakur 
> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> 
> This patch is as per the review of commit fa1f157
> libxl: Fix the bug introduced in commit "libxl: use correct type
> 
>  tools/libxl/libxl_console.c  | 2 +-
>  tools/libxl/libxl_dom.c  | 2 +-
>  tools/libxl/libxl_internal.h | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
> index 6bfc0e5..f2ca689 100644
> --- a/tools/libxl/libxl_console.c
> +++ b/tools/libxl/libxl_console.c
> @@ -329,7 +329,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t 
> domid,
>  flexarray_append(ro_front, "port");
>  flexarray_append(ro_front, GCSPRINTF("%"PRIu32, 
> state->console_port));
>  flexarray_append(ro_front, "ring-ref");
> -flexarray_append(ro_front, GCSPRINTF("%lu", state->console_mfn));
> +flexarray_append(ro_front, GCSPRINTF("%"PRIu_xen_pfn, 
> state->console_mfn));

Actually, please consider changing console_mfn to console_pfn.

You can keep my ack if you make such change.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] x86: fix asm() constraint for GS selector update

[Andrew Cooper]

On 26/10/17 08:57, Jan Beulich wrote:
> Exception fixup code may alter the operand, which ought to be reflected
> in the constraint.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

Hopefully this won't have caused us any real problems in the past.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel