Re: [Xen-devel] [PATCH v3 40/62] arm/acpi: Estimate memory required for acpi/efi tables
On 2015/11/30 23:14, Julien Grall wrote:
> Hi Shannon,
>
> On 17/11/15 09:40, shannon.z...@linaro.org wrote:
>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
>> index 53c7452..78d8ae9 100644
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -13,6 +13,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #if EFI_PAGE_SIZE != PAGE_SIZE
>> # error Cannot use xen/pfn.h here!
>> #endif
>> @@ -1171,6 +1172,26 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
>> *SystemTable)
>> for( ; ; ); /* not reached */
>> }
>>
>> +#ifdef CONFIG_ACPI
>> +/* Constant to indicate "Xen" in unicode u16 format */
>> +static const u16 XEN_EFI_FW_VENDOR[] ={0x0058,0x0065,0x006E,0x};
>> +
>> +int __init estimate_efi_size(int mem_nr_banks)
>> +{
>> +int size;
>> +int est_size = sizeof(EFI_SYSTEM_TABLE);
>> +int ect_size = sizeof(EFI_CONFIGURATION_TABLE);
>> +int emd_size = sizeof(EFI_MEMORY_DESCRIPTOR);
>> +int fw_vendor_size = sizeof(XEN_EFI_FW_VENDOR);
>> +
>> +size = PAGE_ALIGN(est_size + ect_size + fw_vendor_size)
>> + + PAGE_ALIGN(emd_size *
>> +(mem_nr_banks + acpi_mem.nr_banks + TBL_MMAX));
>> +
>> +return size;
>> +}
>> +#endif
>> +
>
> efi/boot.c only contains code related to the stub EFI. This is not the
> case of this code.
>
I add these codes at this file because I want to reuse the definitions
of EFI structures like EFI_SYSTEM_TABLE. Parth re-define those
structures at previous patch set and one comment suggested to reuse the
existing ones. If I add these codes in xen/arch/arm/domain_build.c, it
will have some conflicts. E.g:
In file included from /home/open-source/xen/xen/include/asm/efibind.h:2:0,
from domain_build.c:29:
/home/open-source/xen/xen/include/asm/arm64/efibind.h:86:20: error:
conflicting types for 'UINT64'
typedef uint64_t UINT64;
^
In file included from /home/open-source/xen/xen/include/acpi/acpi.h:57:0,
from /home/open-source/xen/xen/include/xen/acpi.h:33,
from domain_build.c:15:
/home/open-source/xen/xen/include/acpi/actypes.h:130:35: note: previous
declaration of 'UINT64' was here
typedef COMPILER_DEPENDENT_UINT64 UINT64;
> Moreover, this code won't compile on x86 because acpi_mem is only
> defined for ARM.
>
> Regards,
>
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing
> -Original Message- > From: David Vrabel [mailto:david.vra...@citrix.com] > Sent: 23 December 2015 13:28 > To: Paul Durrant; xen-de...@lists.xenproject.org > Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan Beulich > Subject: Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control > ring and toeplitz hashing > > On 23/12/15 10:06, Paul Durrant wrote: > > This patch documents a new shared (variable message length) ring > between > > frontend and backend that can be used to pass bulk out-of-band data, such > > as that required to implement toeplitz hashing in the backend that is > > configurable by the frontend. > > > > The patch then goes on to document the messages passed over the control > [...] > > ring that can be used to configure toeplitz hashing. > > --- a/xen/include/public/io/netif.h > > +++ b/xen/include/public/io/netif.h > > @@ -151,6 +151,326 @@ > > */ > > > > /* > > + * Control ring: > [...] > > + * > > + * The layout of the shared page is as follows: > > + * > > + *0 1 2 3 4 5 6 7 octet > > + * +-+-+-+-+-+-+-+-+ > > + * |req_cons |req_prod | > > + * +-+-+-+-+-+-+-+-+ > > + * |rsp_cons |rsp_prod | > > + * +-+-+-+-+-+-+-+-+ > > + * | | > > + * + + > > + * | req[1024]| > > + * . > > + * . > > + * | | > > + * +-+-+-+-+-+-+-+-+ > > + * | | > > + * + + > > + * | rsp[1024]| > > + * . > > + * . > > + * | | > > + * +-+-+-+-+-+-+-+-+ > > You should use the standard ring format and infrastructure. Is there one for variable message size rings? I didn't find one. I don't want to use the fixed size balanced ring macros for control messages as fixed size messages really aren't appropriate in this case. Paul > > David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/5] xen-netback: Fine-tuning for three function implementations
The original code is fine. regards, dan carpenter ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-3.16 test] 66976: regressions - FAIL
On Wed, 2015-12-23 at 20:54 +, osstest service owner wrote:
> flight 66976 linux-3.16 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/66976/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs.
> 64969
The is the expected rumpkernel failure, so force pushed.
> version targeted for testing:
> linux70a95b3e395fa9f5a5cf531c56ae7e5b6ed37e32
> baseline version:
> linuxa11efd7b42bf716f528b4f163cd86ba1e499354a
(test-lab)osstest@osstest:~/branches/for-linux-3.16.git$
OSSTEST_CONFIG=production-config ./ap-push linux-3.16
70a95b3e395fa9f5a5cf531c56ae7e5b6ed37e32
+ branch=linux-3.16
+ revision=70a95b3e395fa9f5a5cf531c56ae7e5b6ed37e32
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ 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 ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push linux-3.16
70a95b3e395fa9f5a5cf531c56ae7e5b6ed37e32
+ branch=linux-3.16
+ revision=70a95b3e395fa9f5a5cf531c56ae7e5b6ed37e32
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ 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/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.16
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x70a95b3e395fa9f5a5cf531c56ae7e5b6ed37e32 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.16
++ : daily-cron.linux-3.16
++ : daily-cron.linux-3.16
++ : daily-cron.linux-3.16
++ : daily-
Re: [Xen-devel] [linux-3.18 test] 67045: regressions - FAIL
On Thu, 2015-12-24 at 07:47 +, osstest service owner wrote:
> flight 67045 linux-3.18 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/67045/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs.
> 63732
>
This is the expected rumpkernel failure, so force pushing.
> version targeted for testing:
> linux60917545df1ffc7f918550512dc4a14758f74784
> baseline version:
> linuxb12403044336e7d567f309eb443aa9acf76380af
(test-lab)osstest@osstest:~/branches/for-linux-3.18.git$
OSSTEST_CONFIG=production-config ./ap-push linux-3.18
60917545df1ffc7f918550512dc4a14758f74784
+ branch=linux-3.18
+ revision=60917545df1ffc7f918550512dc4a14758f74784
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ 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 ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push linux-3.18
60917545df1ffc7f918550512dc4a14758f74784
+ branch=linux-3.18
+ revision=60917545df1ffc7f918550512dc4a14758f74784
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ 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/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.18
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x60917545df1ffc7f918550512dc4a14758f74784 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.18
++ : daily-cron.linux-3.18
++ : daily-cron.linux-3.18
++ : daily-cron.linux-3.18
++ : da
Re: [Xen-devel] [qemu-upstream-4.6-testing test] 67093: regressions - FAIL
Hi Stefano, On Thu, 2015-12-24 at 21:26 +, osstest service owner wrote: > flight 67093 qemu-upstream-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/67093/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. > 63071 > test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. > 63071 There are instances of these two failures for all qemu-upstream-4.[456]- testing branches on list this morning. I can't see any for qemu-upstream-unstable. The 4.2 and 4.3 testing branches are blocked by an unrelated build failure (related to upgrading the build hosts to Jessie, I think). I wouldn't be at all surprised if they also suffered from this issue once that is fixed. Ian. > > Regressions which are regarded as allowable (not blocking): > test-armhf-armhf-xl-rtds 9 debian-installfail REGR. vs. > 63071 > test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like > 63071 > test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like > 63071 > > Tests which did not succeed, but are not blocking: > test-amd64-amd64-xl-pvh-amd 11 guest- > start fail never pass > test-amd64-amd64-xl-pvh-intel 11 guest- > start fail never pass > test-armhf-armhf-libvirt 14 guest- > saverestorefail never pass > test-armhf-armhf-libvirt 12 migrate-support- > checkfail never pass > test-amd64-amd64-libvirt-xsm 12 migrate-support- > checkfail never pass > test-amd64-i386-libvirt 12 migrate-support- > checkfail never pass > test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail > never pass > test-amd64-i386-libvirt-xsm 12 migrate-support- > checkfail never pass > test-armhf-armhf-libvirt-xsm 12 migrate-support- > checkfail never pass > test-armhf-armhf-libvirt-xsm 14 guest- > saverestorefail never pass > test-amd64-amd64-libvirt 12 migrate-support- > checkfail never pass > test-armhf-armhf-xl-credit2 13 saverestore-support- > checkfail never pass > test-armhf-armhf-xl-credit2 12 migrate-support- > checkfail never pass > test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support- > check fail never pass > test-armhf-armhf-xl-arndale 12 migrate-support- > checkfail never pass > test-armhf-armhf-xl-arndale 13 saverestore-support- > checkfail never pass > test-armhf-armhf-xl 12 migrate-support- > checkfail never pass > test-armhf-armhf-xl 13 saverestore-support- > checkfail never pass > test-armhf-armhf-xl-xsm 13 saverestore-support- > checkfail never pass > test-armhf-armhf-xl-xsm 12 migrate-support- > checkfail never pass > test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support- > check fail never pass > test-amd64-amd64-libvirt-vhd 11 migrate-support- > checkfail never pass > test-armhf-armhf-libvirt-raw 13 guest- > saverestorefail never pass > test-armhf-armhf-libvirt-raw 11 migrate-support- > checkfail never pass > test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail > never pass > test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail > never pass > test-armhf-armhf-xl-vhd 11 migrate-support- > checkfail never pass > test-armhf-armhf-xl-vhd 12 saverestore-support- > checkfail never pass > test-armhf-armhf-xl-multivcpu 13 saverestore-support- > checkfail never pass > test-armhf-armhf-xl-multivcpu 12 migrate-support- > checkfail never pass > test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail > never pass > test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail > never pass > > version targeted for testing: > qemuu9e304f572ac98265f5e7433b6490077962acda97 > baseline version: > qemuu980dfcf5b8d8161871f81d1987b2f8ea5d7d4db9 > > Last test of basis63071 2015-10-19 15:10:58 Z 66 days > Testing same since66535 2015-12-18 15:50:42 Z6 days5 > attempts > > > People who touched revisions under test: > Stefano Stabellini > > 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
[Xen-devel] [PATCH] x86/vmx: Fix injection of #DB traps following XSA-156
Most #DB exceptions are traps rather than faults, meaning that the instruction
pointer in the exception frame points after the instruction rather than at it.
However, VMX intercepts all have fault semantics, even when intercepting a
trap. Re-injecting an intercepted trap as a fault causes an infinite loop in
the guest, by re-executing the same trapping instruction repeatedly. This
breaks debugging inside the guest.
Introduce a helper which copies VM_EXIT_INTR_INTO to VM_ENTRY_INTR_INFO, and
use it to mirror the intercepted interrupt back to the guest.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
CC: secur...@xen.org
v2: Drop vmx_intr_info_t to make the patch simpler to backport.
---
xen/arch/x86/hvm/vmx/vmx.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b918b8a..7917fb7 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2877,6 +2877,33 @@ static int vmx_handle_eoi_write(void)
return 0;
}
+/*
+ * Propagate VM_EXIT_INTR_INFO to VM_ENTRY_INTR_INFO. Used to mirror an
+ * intercepted exception back to the guest as if Xen hadn't intercepted it.
+ *
+ * It is the callers responsibility to ensure that this function is only used
+ * in the context of an appropriate vmexit.
+ */
+static void vmx_propagate_intr(void)
+{
+unsigned long intr, tmp;
+
+__vmread(VM_EXIT_INTR_INFO, &intr);
+
+ASSERT(intr & INTR_INFO_VALID_MASK);
+
+__vmwrite(VM_ENTRY_INTR_INFO, intr);
+
+if ( intr & INTR_INFO_DELIVER_CODE_MASK )
+{
+__vmread(VM_EXIT_INTR_ERROR_CODE, &tmp);
+__vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, tmp);
+}
+
+__vmread(VM_EXIT_INSTRUCTION_LEN, &tmp);
+__vmwrite(VM_ENTRY_INSTRUCTION_LEN, tmp);
+}
+
static void vmx_idtv_reinject(unsigned long idtv_info)
{
@@ -3137,7 +3164,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
if ( !v->domain->debugger_attached )
-hvm_inject_hw_exception(vector, HVM_DELIVER_NO_ERROR_CODE);
+vmx_propagate_intr();
else
domain_pause_for_debugger();
break;
@@ -3206,8 +3233,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
break;
case TRAP_alignment_check:
HVMTRACE_1D(TRAP, vector);
-__vmread(VM_EXIT_INTR_ERROR_CODE, &ecode);
-hvm_inject_hw_exception(vector, ecode);
+vmx_propagate_intr();
break;
case TRAP_nmi:
if ( MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK) !=
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.4-testing test] 66718: regressions - FAIL
On Mon, 2015-12-21 at 10:16 -0700, Jan Beulich wrote: > > > > On 21.12.15 at 18:01, wrote: > > flight 66718 xen-4.4-testing real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/66718/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > build-amd64-prev 5 xen-build fail REGR. > > vs. 66458 > > build-i386-prev 5 xen-build fail REGR. > > vs. 66458 > > build-armhf 5 xen-build fail REGR. > > vs. 66458 > > Considering > > libxlu_cfg_y.c: In function 'xlu__cfg_yyparse': > libxlu_cfg_y.c:1311:50: error: 'scanner' undeclared (first use in this > function) > yychar = yylex (&yylval, &yylloc, scanner); > ^ > libxlu_cfg_y.c:1311:50: note: each undeclared identifier is reported only > once for each function it appears in > make[3]: *** [libxlu_cfg_y.o] Error 1 > > - was there any change to the ARM build environment? osstest switched from using Debian 7.0 (Wheezy) to Debian 8 (Jessie) as the base distro, which will have update the compiler etc. I can't see why this would cause this kind of issue though, but I'm somewhat hampered by the line numbers not matching and the amount of ifdeffery in this auto generated file. Since 4.5 looks ok perhaps one of the below is needed? In fact, yes, I'm sure, since in the logs I now see: /usr/bin/bison --output=libxlu_cfg_y.c libxlu_cfg_y.y python gentypes.py libxl_types_internal.idl __libxl_types_internal.h __libxl_types_internal_json.h __libxl_types_internal.c libxlu_cfg_y.y:34.1-13: warning: deprecated directive, use '%name-prefix' [-Wdeprecated] %name-prefix="xlu__cfg_yy" ^ which matches some of the keywords in 7ba4cdfadd4f3's commit message... Ian. $ git log origin/staging-4.4..origin/staging-4.5 -- tools/libxl/libxlu_cfg_y.c commit 7ba4cdfadd4f3c45d65ffe50e621759f458fedc0 Author: Ed Swierk Date: Tue Jan 6 15:21:07 2015 + libxl: Fix building libxlu_cfg_y.y with bison 3.0 - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner parameter - Change deprecated %name-prefix= to %name-prefix Tested against bison 2.4.1 and 3.0.2. This is expected to sometimes (depending on timestamps and whether the bison input files are edited) break building on systems with ancient versions of bison. Bison 2.4.1 is known to work and was released in December 2008. Also, consquentially, regenerate bison output files with bison 1:2.5.dfsg-2.1 from Debian wheezy. Signed-off-by: Ed Swierk Acked-by: Ian Jackson Tested-by: Wei Liu Signed-off-by: Ian Jackson Release-Acked-by: Konrad Rzeszutek Wilk commit dc92f1a781a160229e4935dc03040bc78712a828 Author: Ian Jackson Date: Fri May 2 17:47:55 2014 +0100 libxl: Rerun bison This updates libxlu_cfg_y.[ch] to code generated by bison from Debian wheezy (1:2.5.dfsg-2.1 i386). There should be no functional change since there is no change to the source file, but we will inherit bugfixes and behavioural changes from the new version of bison. So this is more a matter of hope than knowledge. Signed-off-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.4-testing test] 66583: regressions - FAIL
On Tue, 2015-12-22 at 14:40 +, Stefano Stabellini wrote:
> On Tue, 22 Dec 2015, Jan Beulich wrote:
> > > > > On 22.12.15 at 14:55, wrote:
> > > On Mon, 21 Dec 2015, Jan Beulich wrote:
> > > > > > > On 20.12.15 at 13:25, wrote:
> > > > > flight 66583 xen-4.4-testing real [real]
> > > > > http://logs.test-lab.xenproject.org/osstest/logs/66583/
> > > > >
> > > > > Regressions :-(
> > > > >
> > > > > Tests which did not succeed and are blocking,
> > > > > including tests which could not be run:
> > > > > build-amd64-prev 5 xen-build fail
> > > > > REGR. vs.
> > > 66458
> > > > > build-i386-prev 5 xen-build fail
> > > > > REGR. vs.
> > > 66458
> > > >
> > > > Ian, Stefano,
> > > >
> > > > is one of you two looking into this?
> > > >
> > > > block-qcow.c: In function 'get_cluster_offset':
> > > > block-qcow.c:444:3: error: 'tmp_ptr' may be used uninitialized in
> > > > this
> > > function [-Werror=maybe-uninitialized]
> > > > memcpy(tmp_ptr, l1_ptr, 4096);
> > > > ^
> > > > block-qcow.c:619:7: error: 'tmp_ptr2' may be used uninitialized in
> > > > this
> > > function [-Werror=maybe-uninitialized]
> > > > if (write(s->fd, tmp_ptr2, 4096) != 4096) {
> > > > ^
> > > > cc1: all warnings being treated as errors
> > > >
> > > /home/osstest/build.66583.build-amd64-
> > > prev/xen/tools/blktap/drivers/../../../to
> > > ols/Rules.mk:89: recipe for target 'block-qcow.o' failed
> > > > make[5]: *** [block-qcow.o] Error 1
> > >
> > > What does build-amd64-prev means? I cannot find the explanation of
> > > the
> > > test anywhere.
> >
> > Iiuc it's the build pf the previous version, needed to test n-1 -> n
> > migration. I.e. (in line with the respective 4.3 failure) it indicates
> > that 4.3's qemu doesn't build.
>
> Thanks for the explanation, it was very helpful.
>
> From the logs what is not building is actually tools/blktap, not QEMU
> though, but I cannot reproduce the failure.
I think we want to backport:
commit 345e44a85d71a1a910385f33c7f1ba3683026d18
Author: Dario Faggioli
Date: Fri Jun 20 16:09:00 2014 +0200
blktap2: Fix two 'maybe uninitialized' variables
for which gcc 4.9.0 complains about, like this:
block-qcow.c: In function `get_cluster_offset':
block-qcow.c:431:3: error: `tmp_ptr' may be used uninitialized in this
function
[-Werror=maybe-uninitialized]
memcpy(tmp_ptr, l1_ptr, 4096);
^
block-qcow.c:606:7: error: `tmp_ptr2' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
if (write(s->fd, tmp_ptr2, 4096) != 4096) {
^
cc1: all warnings being treated as errors
/home/dario/Sources/xen/xen/xen.git/tools/blktap2/drivers/../../../tools/Rules.mk:89:
recipe for target 'block-qcow.o' failed
make[5]: *** [block-qcow.o] Error 1
The proper behavior is to return upon allocation failure.
About what to return, 0 seems the best option, looking
at both the function and the call sites.
Signed-off-by: Dario Faggioli
Acked-by: Ian Jackson
(this will have been exposed by the update to Jessie's compiler)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Xen 4.7 Development Update
This email only tracks big items for xen.git tree. Please reply for items you woulk like to see in 4.7 so that people have an idea what is going on and prioritise accordingly. You're welcome to provide description and use cases of the feature you're working on. = Timeline = We now adopt a fixed cut-off date scheme. We will release twice a year. The upcoming 4.7 timeline are as followed: * Last posting date: March 18, 2016 * Hard code freeze: April 1, 2016 * RC1: TBD * Release: June 3, 2016 Note that we don't have freeze exception scheme anymore. All patches that wish to go into 4.7 must be posted no later than the last posting date. All patches posted after that date will be automatically queued into next release. RCs will be arranged immediately after freeze. = Projects = == Hypervisor == * Use Kconfig to configure hypervisor components - Doug Goldstein === x86 === * CPUID handling improvement - Andrew Cooper * VMWare tools support - Don Slutz * xSplice, hypervisor hot-patching - Konrad Wilk - Ross Lagerwall * Porting Intel PState driver - Wei Wang * HVM-nodm support - Roger Pau Monne * Posted interrupt - Wu, Feng * VMX TSC scaling support - Haozhong Zhang * VT-d asynchronous flush issue - Quan Xu * Memory protection-key support - Huaitong Han === ARM === * Guest save / restore support - Ian Campbell == Toolstack == * Make it easy to run xenstore in a domain - Juergen Gross * Libxc support for migrating large PV domains - Juergen Gross * Disentangle libxenctrl to stable libraries - Ian Campbell * Libxl PVSCSI support - Olaf Hering * PV USB passthrough - Chunyan Liu * HVM USB passthrough - George Dunlap * QEMU based PVUSB backend - Juergen Gross * Domain snapshot API - Chunyan Liu * Fix hotplug script machinery and remove blktap - George Dunlap * Basic xSplice tooling (see hypervisor item) - Konrad Wilk * Load BIOS via toolstack - Anthony Perard * Libxl depriv QEMU - Ian Jackson * COLO - Wen Congyang == Documentation == * Feature maturity lifecycle - Lars Kurth == Completed == * vgic-v3 - Julien Grall * xsave/xrtors support - Shuai Ruan * Toolstack-based soft reset - Vitaly Kuznetsov * Libxc support for building large PV domains - Juergen Gross * Run QEMU as non-root - Stefano Stabellini * Intel CDP support - He Chen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.3-testing test] 66638: regressions - FAIL
On Mon, 2015-12-21 at 04:54 -0700, Jan Beulich wrote: > > > > On 21.12.15 at 04:05, wrote: > > flight 66638 xen-4.3-testing real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/66638/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > build-amd64 5 xen-build fail REGR. > > vs. 65650 > > build-amd64-prev 5 xen-build fail REGR. > > vs. 65650 > > man/xl.pod.1 around line 854: Expected text after =item, not a bullet > POD document had syntax errors at /usr/bin/pod2text line 84. > Makefile:142: recipe for target 'txt/man/xl.1.txt' failed > make[2]: *** [txt/man/xl.1.txt] Error 255 > > Yet I don't see any commit under test having touched the input file. > Was there an update to build host software, and we're now lacking > some backport in that tree? Yes, osstest switched to Debian 8 (Jessie) as the base os. This is failing to build 4.2 (-prev job in a 4.3 branch), and I think would be fixed by a backport to that branch of: commit 665ddd98c4d418ced6f303b79b7a6322c69b7247 Author: Olaf Hering Date: Thu Jun 27 16:56:18 2013 +0200 docs: remove emtpy =item from xl.1 perl-5.18 is more strict, build fails with: Expected text after =item, not a bullet Signed-off-by: Olaf Hering Acked-by: George Dunlap Acked-by: Ian Campbell Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] question about migration
> -Original Message- [snip] > > We send the I/O request to the default I/O request server, but no backing > > DM hands it. We wil wait the I/O forever.. > > Hmm yes. This needs fixing. > > CC'ing Paul who did the ioreq server work. > > This bug is caused by the read side effects of HVM_PARAM_IOREQ_PFN. The > migration code needs a way of being able to query whether a default > ioreq server exists, without creating one. > > Can you remember what the justification for the read side effects were? > ISTR that it was only for qemu compatibility until the ioreq server work > got in upstream. If that was the case, can we drop the read side > effects now and mandate that all qemus explicitly create their ioreq > servers (even if this involves creating a default ioreq server for > qemu-trad)? > Yes, you're correct that the read side-effect was the only way of keeping compatibility with existing QEMU at the time. It would be nice to remove that hackery but it would indeed require a patch to qemu-trad and would clearly break compatibility with distro qemu packages built prior to my modification. An alternative solution to avoid breaking compatibility (albeit a bit icky) would be to turn off the side effects when HVMOP_create_ioreq_server is handled. There should be no case where a non-default server needs to be created in advance of a default server. Paul > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] question about migration
On 04/01/16 10:28, Paul Durrant wrote: >> -Original Message- > [snip] >>> We send the I/O request to the default I/O request server, but no backing >>> DM hands it. We wil wait the I/O forever.. >> Hmm yes. This needs fixing. >> >> CC'ing Paul who did the ioreq server work. >> >> This bug is caused by the read side effects of HVM_PARAM_IOREQ_PFN. The >> migration code needs a way of being able to query whether a default >> ioreq server exists, without creating one. >> >> Can you remember what the justification for the read side effects were? >> ISTR that it was only for qemu compatibility until the ioreq server work >> got in upstream. If that was the case, can we drop the read side >> effects now and mandate that all qemus explicitly create their ioreq >> servers (even if this involves creating a default ioreq server for >> qemu-trad)? >> > Yes, you're correct that the read side-effect was the only way of keeping > compatibility with existing QEMU at the time. It would be nice to remove that > hackery but it would indeed require a patch to qemu-trad and would clearly > break compatibility with distro qemu packages built prior to my modification. > An alternative solution to avoid breaking compatibility (albeit a bit icky) > would be to turn off the side effects when HVMOP_create_ioreq_server is > handled. There should be no case where a non-default server needs to be > created in advance of a default server. I was under the impression that qemu-trad (like libxc) was expected to exactly match. There is deliberately no facility to use a distro packaged qemu-trad in the Xen build system. CC'ing toolstack maintainers for their input. If this is indeed the case, then the former option is the better course of action. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] memory-hotplug: add automatic onlining policy for the newly added memory
Andrew Morton writes:
> On Tue, 22 Dec 2015 17:32:30 +0100 Vitaly Kuznetsov
> wrote:
>
>> Currently, all newly added memory blocks remain in 'offline' state unless
>> someone onlines them, some linux distributions carry special udev rules
>> like:
>>
>> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline",
>> ATTR{state}="online"
>>
>> to make this happen automatically. This is not a great solution for virtual
>> machines where memory hotplug is being used to address high memory pressure
>> situations as such onlining is slow and a userspace process doing this
>> (udev) has a chance of being killed by the OOM killer as it will probably
>> require to allocate some memory.
>>
>> Introduce default policy for the newly added memory blocks in
>> /sys/devices/system/memory/hotplug_autoonline file with two possible
>> values: "offline" which preserves the current behavior and "online" which
>> causes all newly added memory blocks to go online as soon as they're added.
>> The default is "online" when MEMORY_HOTPLUG_AUTOONLINE kernel config option
>> is selected.
>
> I think the default should be "offline" so vendors can ship kernels
> which have CONFIG_MEMORY_HOTPLUG_AUTOONLINE=y while being
> back-compatible with previous kernels.
>
(sorry for the delayed response, just picking things up after holidays)
I was under an (wrong?) impression that in the majority of use cases
users want to start using their newly added memory right away and that's
what distros will ship. As an alternative to making the feature off by
default I can suggest making CONFIG_MEMORY_HOTPLUG_AUTOONLINE a tristate
switch (no feature, default offline, default online).
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -2537,6 +2537,8 @@ bytes respectively. Such letter suffixes can also be
>> entirely omitted.
>> shutdown the other cpus. Instead use the REBOOT_VECTOR
>> irq.
>>
>> +nomemhp_autoonline Don't automatically online newly added memory.
>> +
>
> This wasn't mentioned in the changelog. Why do we need a boot
> parameter as well as the sysfs knob?
>
I was thinking about some faulty hardware (e.g. reporting new memory
blocks which for some reason are not really usable) and an easy way to
make such hardware work.
>> +config MEMORY_HOTPLUG_AUTOONLINE
>> +bool "Automatically online hot-added memory"
>> +depends on MEMORY_HOTPLUG_SPARSE
>> +help
>> + When memory is hot-added, it is not at ready-to-use state, a special
>
> "When memory is hot-added it is not in a ready-to-use state. A special"
>
>> + userspace action is required to online the newly added blocks. With
>> + this option enabled, the kernel will try to online all newly added
>> + memory automatically.
>> +
>>
>> ...
>>
--
Vitaly
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-sid test] 38586: tolerable FAIL
flight 38586 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38586/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail like 38567 test-amd64-i386-amd64-sid-netboot-pygrub 9 debian-di-install fail like 38567 test-amd64-amd64-i386-sid-netboot-pygrub 9 debian-di-install fail like 38567 test-amd64-amd64-amd64-sid-netboot-pvgrub 9 debian-di-install fail like 38567 test-amd64-i386-i386-sid-netboot-pvgrub 9 debian-di-install fail like 38567 baseline version: flight 38567 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-sid-netboot-pvgrubfail test-amd64-i386-i386-sid-netboot-pvgrub fail test-amd64-i386-amd64-sid-netboot-pygrub fail test-armhf-armhf-armhf-sid-netboot-pygrubfail test-amd64-amd64-i386-sid-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] VGA Passthrough Tested Adatpers
On Tue, 2015-12-22 at 17:12 +, Chris Law wrote: > Hey can someone add AMD Radeon R9 390 to the Tested Adapters list here ht > tp://wiki.xenproject.org/wiki/Xen_VGA_Passthrough_Tested_Adapters > > I've requested edit access, but don't yet have it. Sorry, looks like our coverage was a bit thing over Xmas etc. I've added write access to your account (you'll also get the std boiler plate welcome mail under separate cover). Cheers, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing
On 04/01/16 09:37, Paul Durrant wrote:
>>> + * The layout of the shared page is as follows:
>>> + *
>>> + *0 1 2 3 4 5 6 7 octet
>>> + * +-+-+-+-+-+-+-+-+
>>> + * |req_cons |req_prod |
>>> + * +-+-+-+-+-+-+-+-+
>>> + * |rsp_cons |rsp_prod |
>>> + * +-+-+-+-+-+-+-+-+
>>> + * | |
>>> + * + +
>>> + * | req[1024]|
>>> + * .
>>> + * .
>>> + * | |
>>> + * +-+-+-+-+-+-+-+-+
>>> + * | |
>>> + * + +
>>> + * | rsp[1024]|
>>> + * .
>>> + * .
>>> + * | |
>>> + * +-+-+-+-+-+-+-+-+
>>
>> You should use the standard ring format and infrastructure.
>
> Is there one for variable message size rings? I didn't find one. I
> don't want to use the fixed size balanced ring macros for control
> messages as fixed size messages really aren't appropriate in this case.
Perhaps union the request/response message types with a uint8_t
pad[1024] and use this as the request/response type?
You can use the standard macros like so (to avoid copying the full 1024
bytes every time):
hdr = RING_GET_REQUEST(...);
switch (READ_ONCE(hdr->type)) {
case FOO:
{
struct foo foo;
RING_COPY_REQUEST(ring, cons, &foo);
handle_foo(&foo);
}
break;
case ...:
...
}
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] question about migration
> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 04 January 2016 10:36 > To: Paul Durrant; Wen Congyang > Cc: xen devel; Ian Campbell; Ian Jackson; Wei Liu > Subject: Re: [Xen-devel] question about migration > > On 04/01/16 10:28, Paul Durrant wrote: > >> -Original Message- > > [snip] > >>> We send the I/O request to the default I/O request server, but no > backing > >>> DM hands it. We wil wait the I/O forever.. > >> Hmm yes. This needs fixing. > >> > >> CC'ing Paul who did the ioreq server work. > >> > >> This bug is caused by the read side effects of HVM_PARAM_IOREQ_PFN. > The > >> migration code needs a way of being able to query whether a default > >> ioreq server exists, without creating one. > >> > >> Can you remember what the justification for the read side effects were? > >> ISTR that it was only for qemu compatibility until the ioreq server work > >> got in upstream. If that was the case, can we drop the read side > >> effects now and mandate that all qemus explicitly create their ioreq > >> servers (even if this involves creating a default ioreq server for > >> qemu-trad)? > >> > > Yes, you're correct that the read side-effect was the only way of keeping > compatibility with existing QEMU at the time. It would be nice to remove that > hackery but it would indeed require a patch to qemu-trad and would clearly > break compatibility with distro qemu packages built prior to my modification. > > An alternative solution to avoid breaking compatibility (albeit a bit icky) > would be to turn off the side effects when HVMOP_create_ioreq_server is > handled. There should be no case where a non-default server needs to be > created in advance of a default server. > > I was under the impression that qemu-trad (like libxc) was expected to > exactly match. There is deliberately no facility to use a distro > packaged qemu-trad in the Xen build system. CC'ing toolstack > maintainers for their input. > It wasn't clear but I meant that compatibility with *upstream* QEMU builds prior to my patch would be broken. It depends whether we care about this or not. Paul > If this is indeed the case, then the former option is the better course > of action. > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/5] xen-netback: Fine-tuning for three function implementations
I think the original code is fine. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] add support for vNVDIMM - Part 1: enable instructions
On Wed, Dec 30, 2015 at 07:48:57PM +0800, Haozhong Zhang wrote: > I split the previous patch series "[PATCH 0/4] add support for vNVDIMM" > into two parts. This is the first part that enables clflushopt/clwb/pcommit > instructions for HVM guests. > > [The second part will be sent separately after v1 patches get reviewed.] > > Changes in v2: > * Refactor modifications in hvm_cpuid() per Andrew Cooper's comments. > > Haozhong Zhang (2): > x86/hvm: allow guest to use clflushopt and clwb > x86/hvm: add support for pcommit instruction > > tools/libxc/xc_cpufeature.h| 4 +++- > tools/libxc/xc_cpuid_x86.c | 5 - Tools bits: Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing
> -Original Message-
> From: David Vrabel [mailto:david.vra...@citrix.com]
> Sent: 04 January 2016 10:56
> To: Paul Durrant; David Vrabel; xen-de...@lists.xenproject.org
> Cc: Tim (Xen.org); Keir (Xen.org); Ian Campbell; Jan Beulich; Ian Jackson
> Subject: Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control
> ring and toeplitz hashing
>
> On 04/01/16 09:37, Paul Durrant wrote:
> >>> + * The layout of the shared page is as follows:
> >>> + *
> >>> + *0 1 2 3 4 5 6 7 octet
> >>> + * +-+-+-+-+-+-+-+-+
> >>> + * |req_cons |req_prod |
> >>> + * +-+-+-+-+-+-+-+-+
> >>> + * |rsp_cons |rsp_prod |
> >>> + * +-+-+-+-+-+-+-+-+
> >>> + * | |
> >>> + * + +
> >>> + * | req[1024]|
> >>> + * .
> >>> + * .
> >>> + * | |
> >>> + * +-+-+-+-+-+-+-+-+
> >>> + * | |
> >>> + * + +
> >>> + * | rsp[1024]|
> >>> + * .
> >>> + * .
> >>> + * | |
> >>> + * +-+-+-+-+-+-+-+-+
> >>
> >> You should use the standard ring format and infrastructure.
> >
> > Is there one for variable message size rings? I didn't find one. I
> > don't want to use the fixed size balanced ring macros for control
> > messages as fixed size messages really aren't appropriate in this case.
>
> Perhaps union the request/response message types with a uint8_t
> pad[1024] and use this as the request/response type?
>
The problem is that this places a 1k limit on the message size, which is not
there in the scheme I'm proposing. I'd rather not bake that limit in if I don't
have to.
Paul
> You can use the standard macros like so (to avoid copying the full 1024
> bytes every time):
>
> hdr = RING_GET_REQUEST(...);
> switch (READ_ONCE(hdr->type)) {
> case FOO:
> {
> struct foo foo;
> RING_COPY_REQUEST(ring, cons, &foo);
> handle_foo(&foo);
> }
> break;
> case ...:
> ...
> }
>
> David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] tools/xl: add a new xl configuration 'nvdimm'
On Tue, Dec 29, 2015 at 07:31:50PM +0800, Haozhong Zhang wrote: > This configure is used to specify vNVDIMM devices which are provided to > the guest. xl parses this configuration and passes the result to qemu > that is responsible to create vNVDIMM devices. > > Signed-off-by: Haozhong Zhang For the record in your latest series you said you will be sending toolstack changes in a separate patch set so I skip these two patches for now. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing
On 04/01/16 11:14, Paul Durrant wrote: You should use the standard ring format and infrastructure. >>> >>> Is there one for variable message size rings? I didn't find one. I >>> don't want to use the fixed size balanced ring macros for control >>> messages as fixed size messages really aren't appropriate in this case. >> >> Perhaps union the request/response message types with a uint8_t >> pad[1024] and use this as the request/response type? >> > > The problem is that this places a 1k limit on the message size, > which > is not there in the scheme I'm proposing. I'd rather not bake that limit > in if I don't have to. > + * | req[1024]| ^ Surely this limits your size to 1024 bytes? Also if you need bigger messages you can grant those areas separately and pass a grant ref through the ring, or you can chunk the message to fit in several requests/responses. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing
> -Original Message- > From: David Vrabel [mailto:david.vra...@citrix.com] > Sent: 04 January 2016 11:18 > To: Paul Durrant; xen-de...@lists.xenproject.org > Cc: Tim (Xen.org); Keir (Xen.org); Ian Campbell; Jan Beulich; Ian Jackson > Subject: Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control > ring and toeplitz hashing > > On 04/01/16 11:14, Paul Durrant wrote: > You should use the standard ring format and infrastructure. > >>> > >>> Is there one for variable message size rings? I didn't find one. I > >>> don't want to use the fixed size balanced ring macros for control > >>> messages as fixed size messages really aren't appropriate in this case. > >> > >> Perhaps union the request/response message types with a uint8_t > >> pad[1024] and use this as the request/response type? > >> > > > > The problem is that this places a 1k limit on the message size, > > which > > is not there in the scheme I'm proposing. I'd rather not bake that limit > > in if I don't have to. > > > + * | req[1024]| > ^ > Surely this limits your size to 1024 bytes? No, I've already got prototype code that can pass 4k messages. Nothing in the protocol says the whole message has to fit in the buffer. In fact I've explicitly documented how to handle partial messages. > > Also if you need bigger messages you can grant those areas separately > and pass a grant ref through the ring, or you can chunk the message to > fit in several requests/responses. Why go to that trouble to wedge a square peg into a round hole? What is the fundamental problem with what I've proposed that you want to avoid? Paul > > David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] memory-hotplug: add automatic onlining policy for the newly added memory
On 22/12/15 16:32, Vitaly Kuznetsov wrote: > @@ -1292,6 +1304,11 @@ int __ref add_memory_resource(int nid, struct resource > *res) > /* create new memmap entry */ > firmware_map_add_hotplug(start, start + size, "System RAM"); > > + /* online pages if requested */ > + if (online) > + online_pages(start >> PAGE_SHIFT, size >> PAGE_SHIFT, > + MMOP_ONLINE_KEEP); This will cause the Xen balloon driver to deadlock because it calls add_memory_resource() with the balloon_mutex locked and the online page callback also locks the balloon_mutex. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: convert CONFIG_COMPAT to Kconfig
On Mon, 2015-12-21 at 04:32 -0700, Jan Beulich wrote:
> > > > On 18.12.15 at 23:09, wrote:
> > On 18/12/2015 21:49, Doug Goldstein wrote:
> > > On 12/18/15 3:35 PM, Andrew Cooper wrote:
> > > > On 18/12/2015 20:06, Doug Goldstein wrote:
> > > > > Use the Kconfig generated CONFIG_COMPAT defines in the code base.
> > > > >
> > > > > CC: Keir Fraser
> > > > > CC: Jan Beulich
> > > > > CC: Andrew Cooper
> > > > > Signed-off-by: Doug Goldstein
> > > > Reviewed-by: Andrew Cooper , although I
> > > > have
> > > > a slight quibble.
> > > >
> > > > > ---
> > > > > This was previously Acked-by: Jan Beulich but
> > > > > then
> > > > > there was a request to change it to xen/common/Kconfig from
> > > > > xen/arch/x86/Kconfig. Unfortunately a small typo ('def_bool y'
> > > > > instead of
> > > > > 'bool') caused it to break on ARM. This resolves the issue and
> > > > > should be
> > > > > ready to merge.
> > > > > ---
> > > > > config/x86_64.mk | 1 -
> > > > > xen/arch/x86/Kconfig | 1 +
> > > > > xen/common/Kconfig | 7 +++
> > > > > 3 files changed, 8 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/config/x86_64.mk b/config/x86_64.mk
> > > > > index f12d549..85fa27c 100644
> > > > > --- a/config/x86_64.mk
> > > > > +++ b/config/x86_64.mk
> > > > > @@ -2,7 +2,6 @@ CONFIG_X86 := y
> > > > > CONFIG_X86_64 := y
> > > > > CONFIG_X86_$(XEN_OS) := y
> > > > >
> > > > > -CONFIG_COMPAT := y
> > > > > CONFIG_MIGRATE := y
> > > > > CONFIG_XCUTILS := y
> > > > >
> > > > > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> > > > > index 07e366d..7d2ed96 100644
> > > > > --- a/xen/arch/x86/Kconfig
> > > > > +++ b/xen/arch/x86/Kconfig
> > > > > @@ -3,6 +3,7 @@ config X86_64
> > > > >
> > > > > config X86
> > > > > def_bool y
> > > > > + select COMPAT
> > > > > select HAS_ACPI
> > > > > select HAS_CPUFREQ
> > > > > select HAS_EHCI
> > > > > diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> > > > > index 7d0e9a9..046e257 100644
> > > > > --- a/xen/common/Kconfig
> > > > > +++ b/xen/common/Kconfig
> > > > > @@ -1,6 +1,13 @@
> > > > >
> > > > > menu "Common Features"
> > > > >
> > > > > +config COMPAT
> > > > > + bool
> > > > > + help
> > > > > + 32-bit interface support on 64-bit Xen which is used
> > > > > for both
> > > > > + HVM and PV guests. HVMLoader makes 32-bit hypercalls
> > > > > irrespective
> > > > > + of the destination runmode of the guest.
> > > > As this is now common, probably want to specify x86 HVM and PV
> > > > guests.
> > > > Arm guests are technically HVM, although the term is rather less
> > > > common
> > > > on their side.
> > > >
> > > > ~Andrew
> > > >
> > > How about:
> > >
> > > 32-bit interface support on 64-bit Xen which is used by x86 HVM and
> > > PV
> > > guests and ARM HVM guests. The reason this is used for HVM guests is
> > > that HVMLoader makes 32-bit hypercalls irrespective of the
> > > destination
> > > run mode of the guest.
> > >
> >
> > The complication here is that arm doesn't yet support compat. There is
> > a hope to (which is, I guess, why Jan asked for it to be common), but
> > it
> > shouldn't give any implication that it is available on ARM yet.
>
> I don't think ARM is meant to ever use this layer - its interface was
> made 32-bit clean from the beginning.
Correct. We went to some lengths to avoid the need for a compat layer for
supporting 32 bit guests on a 64 bit Xen ARM.
I also want to clarify that ARM guests are neither PV nor HVM(*), they are
something in between and we try to avoid the PV/HVM terminology when
speaking about ARM, they are just "guests" as there is only one kind. (Some
of the PV/HVM terminology has leaked into the implementation, due to not
fully refactoring some stuff or shaving various yaks by renaming stuff, but
that's irrelevant to the bigger picture IMHO).
Eventually we may end up with a thing like x86's HVM (i.e. pretending to be
real h/w) at which point we will need to retcon on a name for the existing
guest type.
(*) They are somewhat more like a PVH or dm-lite guest, but even that isn't
quite right.
> The reason for wanting this
> option to be common is an abstract one (i.e. considering just possible
> future architectures).
I would hope that most future arches would try very hard to follow ARM's
lead here and not have a compat layer at all, but that doesn't conflict
with your abstract point IMHO.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] retain the configuration that Xen was built with
On Tue, 2015-12-22 at 09:47 -0600, Doug Goldstein wrote:
> On 12/22/15 9:44 AM, Doug Goldstein wrote:
> > This should retain the .config file from the Kconfig process so that we
> > know how this build of Xen was configured.
> >
> > Signed-off-by: Doug Goldstein
> > ---
> > ts-xen-build | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/ts-xen-build b/ts-xen-build
> > index b02e737..80b1faa 100755
> > --- a/ts-xen-build
> > +++ b/ts-xen-build
> > @@ -192,6 +192,7 @@ sub stash () {
> > }
> > built_stash_file($ho, $builddir, "xen-syms", "xen/xen/xen-syms",
> > 1);
> > built_stash_file($ho, $builddir, "xen-config", "xen/.config", 1);
> > +built_stash_file($ho, $builddir, "xen-hv-config",
> > "xen/xen/.config", 1);
> > built_stash_file($ho, $builddir, "seabios-config",
> > "xen/tools/firmware/seabios-dir-remote/.config",
> > 1);
> > built_compress_stashed("xen-syms");
> >
>
>
> This is for osstest. I forgot to include that in the subject.
I guessed ;-)
Acked-by: Ian Campbell
We should probably get this into the osstest gate sooner rather than later
in anticipation of series's which add more options.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: save generated config in /boot
On Mon, 2015-12-21 at 08:35 -0600, Doug Goldstein wrote: > On 12/21/15 6:11 AM, Jan Beulich wrote: > > > > > On 18.12.15 at 22:35, wrote: > > > Since we now support changing Xen options with Kconfig, we should > > > save > > > the configuration that was used to build up Xen. This will save it in > > > /boot alongside the installed xen.gz and call it > > > xen-$(FULLVERSION).config > > > > > > Suggested-by: Ian Campbell > > > Signed-off-by: Doug Goldstein > > > --- > > > xen/Makefile | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/xen/Makefile b/xen/Makefile > > > index 9023863..460b977 100644 > > > --- a/xen/Makefile > > > +++ b/xen/Makefile > > > @@ -58,6 +58,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX) > > > ln -f -s $(T)-$(XEN_FULLVERSION)$(Z) > > > $(D)$(BOOT_DIR)/$(T)$(Z) > > > [ -d "$(D)$(DEBUG_DIR)" ] || $(INSTALL_DIR) $(D)$(DEBUG_DIR) > > > $(INSTALL_DATA) $(TARGET)-syms $(D)$(DEBUG_DIR)/$(T)-syms- > > > $(XEN_FULLVERSION) > > > + $(INSTALL_DATA) $(KCONFIG_CONFIG) $(D)$(BOOT_DIR)/$(T)- > > > $(XEN_FULLVERSION).config > > > > Was it really suggested to put this into /boot? It has no business > > being there... > > > > Jan > > > > Yes. By multiple people. Ian Campbell was the first person to suggest it > in that location. I don't really care where it goes so long as it is somewhere which is (or can become) well known. IOW: I don't care to join in the argument about the location. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing
On 04/01/16 11:21, Paul Durrant wrote: >> -Original Message- >> From: David Vrabel [mailto:david.vra...@citrix.com] >> Sent: 04 January 2016 11:18 >> To: Paul Durrant; xen-de...@lists.xenproject.org >> Cc: Tim (Xen.org); Keir (Xen.org); Ian Campbell; Jan Beulich; Ian Jackson >> Subject: Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control >> ring and toeplitz hashing >> >> On 04/01/16 11:14, Paul Durrant wrote: >> You should use the standard ring format and infrastructure. > > Is there one for variable message size rings? I didn't find one. I > don't want to use the fixed size balanced ring macros for control > messages as fixed size messages really aren't appropriate in this case. Perhaps union the request/response message types with a uint8_t pad[1024] and use this as the request/response type? >>> >>> The problem is that this places a 1k limit on the message size, >>> which >>> is not there in the scheme I'm proposing. I'd rather not bake that limit >>> in if I don't have to. >> >>> + * | req[1024]| >> ^ >> Surely this limits your size to 1024 bytes? > > No, I've already got prototype code that can pass 4k messages. Nothing in the > protocol says the whole message has to fit in the buffer. In fact I've > explicitly documented how to handle partial messages. Then the standard ring infrastructure will work just fine. >> Also if you need bigger messages you can grant those areas separately >> and pass a grant ref through the ring, or you can chunk the message to >> fit in several requests/responses. > > Why go to that trouble to wedge a square peg into a round hole? What is the > fundamental problem with what I've proposed that you want to avoid? You've put the consumer values into the shared page. I'd rather not have to scrutinize your shared ring implementation for other security bugs. Similarly, if there's another security issues like XSA-155 I'd rather not have to look at another non-standard shared ring implementation. IMO, it's you who should be presenting compelling reasons for /not/ using the standard infrastructure, not the other way around. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 33/34] xenbus: use virt_xxx barriers
On 31/12/15 19:10, Michael S. Tsirkin wrote: > drivers/xen/xenbus/xenbus_comms.c uses > full memory barriers to communicate with the other side. > > For guests compiled with CONFIG_SMP, smp_wmb and smp_mb > would be sufficient, so mb() and wmb() here are only needed if > a non-SMP guest runs on an SMP host. > > Switch to virt_xxx barriers which serve this exact purpose. Acked-by: David Vrabel If you're feeling particularly keen there's a rmb() consume_one_event() in drivers/xen/events/events_fifo.c that can be converted to virt_rmb() as well. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 34/34] xen/io: use virt_xxx barriers
On 31/12/15 19:10, Michael S. Tsirkin wrote: > include/xen/interface/io/ring.h uses > full memory barriers to communicate with the other side. > > For guests compiled with CONFIG_SMP, smp_wmb and smp_mb > would be sufficient, so mb() and wmb() here are only needed if > a non-SMP guest runs on an SMP host. > > Switch to virt_xxx barriers which serve this exact purpose. Acked-by: David Vrabel David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing
> -Original Message- > From: David Vrabel [mailto:david.vra...@citrix.com] > Sent: 04 January 2016 11:29 > To: Paul Durrant; xen-de...@lists.xenproject.org > Cc: Tim (Xen.org); Keir (Xen.org); Ian Campbell; Jan Beulich; Ian Jackson > Subject: Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control > ring and toeplitz hashing > > On 04/01/16 11:21, Paul Durrant wrote: > >> -Original Message- > >> From: David Vrabel [mailto:david.vra...@citrix.com] > >> Sent: 04 January 2016 11:18 > >> To: Paul Durrant; xen-de...@lists.xenproject.org > >> Cc: Tim (Xen.org); Keir (Xen.org); Ian Campbell; Jan Beulich; Ian Jackson > >> Subject: Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control > >> ring and toeplitz hashing > >> > >> On 04/01/16 11:14, Paul Durrant wrote: > >> You should use the standard ring format and infrastructure. > > > > Is there one for variable message size rings? I didn't find one. I > > don't want to use the fixed size balanced ring macros for control > > messages as fixed size messages really aren't appropriate in this case. > > Perhaps union the request/response message types with a uint8_t > pad[1024] and use this as the request/response type? > > >>> > >>> The problem is that this places a 1k limit on the message size, > >>> which > >>> is not there in the scheme I'm proposing. I'd rather not bake that limit > >>> in if I don't have to. > >> > >>> + * | req[1024]| > >> ^ > >> Surely this limits your size to 1024 bytes? > > > > No, I've already got prototype code that can pass 4k messages. Nothing in > the protocol says the whole message has to fit in the buffer. In fact I've > explicitly documented how to handle partial messages. > > Then the standard ring infrastructure will work just fine. > > >> Also if you need bigger messages you can grant those areas separately > >> and pass a grant ref through the ring, or you can chunk the message to > >> fit in several requests/responses. > > > > Why go to that trouble to wedge a square peg into a round hole? What is > the fundamental problem with what I've proposed that you want to avoid? > > You've put the consumer values into the shared page. I'd rather not have > to scrutinize your shared ring implementation for other security bugs. > Similarly, if there's another security issues like XSA-155 I'd rather > not have to look at another non-standard shared ring implementation. Ok. That's a good enough reason. I'll come up with a new prototype. > > IMO, it's you who should be presenting compelling reasons for /not/ > using the standard infrastructure, not the other way around. > There is no 'standard' here though. There's convention, but that's a different thing. If we're going to have a 'no more variable size message protocols' policy than that needs writing down somewhere. Paul > David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Check if gdbsx is running
On Sat, 2015-12-26 at 23:38 +, Andrew Cooper wrote: > On 26/12/2015 23:27, Carl Patenaude Poulin wrote: > > Hi all, > > > > I'm writing some development tools for my team. Given a domain ID, > > is there a way to programmatically check whether gdbsx is running on > > that domain and what port it's running on? I could use something > > like `top -b -n 1 | grep gdbsx` but that seems very brittle. > With a XEN_DOMCTL_getdomaininfo hypercall, "flags & XEN_DOMINF_debugged" > (or xc_dominfo_t.debugged) will tell you whether a debugger is attached > to a domain. > > This is the closest I am aware of you being able to get. > > Whether gdbsx is running, or what port it is running on, are internal > details to the domain running the debugger and not interesting to Xen. > > If you can assume that all debuggers are run in dom0, then some process > list based approach is probably best. Or patching gdbsx to leave a dropping (akin to a pid file) pointing to the correct port for a named domain (e.g. /var/run/gdbsx.$domid.port or something in xenstore maybe?). Or even make it able to use a named pipe or Unix domain socket instead of a port (assuming the gdb client supports the same). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/3] checkpatch: handling of memory barriers
As part of memory barrier cleanup, this patchset extends checkpatch to make it easier to stop incorrect memory barrier usage. This applies on top of my series arch: barrier cleanup + barriers for virt and will be included in the next version of the series. Michael S. Tsirkin (3): checkpatch.pl: add missing memory barriers checkpatch: check for __smp outside barrier.h checkpatch: add virt barriers scripts/checkpatch.pl | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) -- MST ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/3] checkpatch: check for __smp outside barrier.h
Introduction of __smp barriers cleans up a bunch of duplicate code, but
it gives people an additional handle onto a "new" set of barriers - just
because they're prefixed with __* unfortunately doesn't stop anyone from
using it (as happened with other arch stuff before.)
Add a checkpatch test so it will trigger a warning.
Reported-by: Russell King
Signed-off-by: Michael S. Tsirkin
---
scripts/checkpatch.pl | 11 +++
1 file changed, 11 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0245bbe..e3f9ad9 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5130,6 +5130,17 @@ sub process {
}
}
+ my @underscore_smp_barriers = map {"__" . $_} @smp_barriers;
+ my $underscore_all_barriers = join('|',
@underscore_smp_barriers);
+
+ if ($realfile !~ m@^include/asm-generic/@ &&
+ $realfile !~ m@/barrier\.h$@ &&
+ $line =~ m/\b($underscore_all_barriers)\(/ &&
+ $line !~
m/^.\s*\#\s*define\s+($underscore_all_barriers)\(/) {
+ WARN("MEMORY_BARRIER",
+"__smp memory barriers shouldn't be used outside
barrier.h and asm-generic\n" . $herecurr);
+ }
+
# check for waitqueue_active without a comment.
if ($line =~ /\bwaitqueue_active\s*\(/) {
if (!ctx_has_comment($first_line, $linenr)) {
--
MST
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/3] checkpatch.pl: add missing memory barriers
SMP-only barriers were missing in checkpatch.pl
Refactor code slightly to make adding more variants easier.
Signed-off-by: Michael S. Tsirkin
---
scripts/checkpatch.pl | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 2b3c228..0245bbe 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5116,7 +5116,14 @@ sub process {
}
}
# check for memory barriers without a comment.
- if ($line =~
/\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|smp_read_barrier_depends)\(/)
{
+
+ my @barriers = ('mb', 'rmb', 'wmb', 'read_barrier_depends');
+ my @smp_barriers = ('smp_store_release', 'smp_load_acquire',
'smp_store_mb');
+
+ @smp_barriers = (@smp_barriers, map {"smp_" . $_} @barriers);
+ my $all_barriers = join('|', (@barriers, @smp_barriers));
+
+ if ($line =~ /\b($all_barriers)\(/) {
if (!ctx_has_comment($first_line, $linenr)) {
WARN("MEMORY_BARRIER",
"memory barrier without comment\n" .
$herecurr);
--
MST
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/3] checkpatch: add virt barriers
Add virt_ barriers to list of barriers to check for
presence of a comment.
Signed-off-by: Michael S. Tsirkin
---
scripts/checkpatch.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e3f9ad9..5fb6ef7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5121,7 +5121,8 @@ sub process {
my @smp_barriers = ('smp_store_release', 'smp_load_acquire',
'smp_store_mb');
@smp_barriers = (@smp_barriers, map {"smp_" . $_} @barriers);
- my $all_barriers = join('|', (@barriers, @smp_barriers));
+ my @virt_barriers = map {my $l = $_; $l =~ s/smp_/virt_/; $l}
@smp_barriers;
+ my $all_barriers = join('|', (@barriers, @smp_barriers,
@virt_barriers));
if ($line =~ /\b($all_barriers)\(/) {
if (!ctx_has_comment($first_line, $linenr)) {
--
MST
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 08/16] xen, mm: Set IORESOURCE_SYSTEM_RAM to System RAM
On 25/12/15 22:09, Toshi Kani wrote: > Set IORESOURCE_SYSTEM_RAM to 'flags' of struct resource entries > with "System RAM". [...] > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -257,7 +257,7 @@ static struct resource > *additional_memory_resource(phys_addr_t size) > return NULL; > > res->name = "System RAM"; > - res->flags = IORESOURCE_MEM | IORESOURCE_BUSY; > + res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; > > ret = allocate_resource(&iomem_resource, res, > size, 0, -1, Acked-by: David Vrabel David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] Improved RTDS scheduler
On Thu, 2015-12-31 at 04:45 -0500, Tianyang Chen wrote: > Budget replenishment is now handled by a dedicated timer which is > triggered at the most imminent release time of all runnable vcpus. > > Signed-off-by: Tianyang Chen > Signed-off-by: Meng Xu > Signed-off-by: Dagaen Golomb > --- > -cover-letter.patch| 16 +++ > 0001-Improved-RTDS-scheduler.patch | 280 > > bak| 62 I assume you didn't actually intend to commit those ;-) (In general single patches do not require a separate cover letter unless the required context contains a large amount of information which is not appropriate for the commit message of the actual change, I'll leave it to you and the scheduler maintainers to decide how much of your cover letter it would be appropriate to move to the commit message). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.2-testing test] 76943: regressions - FAIL
flight 76943 qemu-upstream-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/76943/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 62044 build-amd64 5 xen-build fail REGR. vs. 62044 Tests which did not succeed, but are not blocking: build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xend-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 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-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a version targeted for testing: qemuu5081fc1c773d2a83ec7a867f030323b8b6956cd1 baseline version: qemuuc17e602ae64fb24405ebd256679ba9a6f5819086 Last test of basis62044 2015-09-15 15:06:42 Z 110 days Testing same since66542 2015-12-18 16:37:10 Z 16 days8 attempts People who touched revisions under test: Stefano Stabellini jobs: build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked test-amd64-i386-xend-qemuu-winxpsp3 blocked test-amd64-amd64-xl-qemuu-winxpsp3 blocked test-i386-i386-xl-qemuu-winxpsp3 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 5081fc1c773d2a83ec7a867f030323b8b6956cd1 Author: Stefano Stabellini Date: Fri Dec 18 15:45:14 2015 + xenfb: avoid reading twice the same fields from the shared page Reading twice the same field could give the guest an attack of opportunity. In the case of event->type, gcc could compile the switch statement into a jump table, effectively ending up reading the type field multiple times. This is part of XSA-155. Signed-off-by: Stefano Stabellini commit 74fab2ef4c0ba42af477e9e445c9883cc45cf9e6 Author: Stefano Stabellini Date: Fri Dec 18 15:44:58 2015 + xen/blkif: Avoid double access to src->nr_segments src is stored in shared memory and src->nr_segments is dereferenced twice at the end of the function. If a compiler decides to compile this into two separate memory accesses then the size limitation could be bypassed. Fix it by removing the double access to src->nr_segments. This is part of XSA-155. Signed-off-by: Stefano Stabellini
[Xen-devel] [PATCH] xen/events: use virt_xxx barriers
drivers/xen/events/events_fifo.c uses rmb() to communicate with the
other side.
For guests compiled with CONFIG_SMP, smp_rmb would be sufficient, so
rmb() here is only needed if a non-SMP guest runs on an SMP host.
Switch to the virt_rmb barrier which serves this exact purpose.
Pull in asm/barrier.h here to make sure the file is self-contained.
Suggested-by: David Vrabel
Signed-off-by: Michael S. Tsirkin
---
This is on top of my series:
arch: barrier cleanup + barriers for virt
and will be included in v3 of the series.
drivers/xen/events/events_fifo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index 96a1b8d..eff2b88 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -41,6 +41,7 @@
#include
#include
+#include
#include
#include
#include
@@ -296,7 +297,7 @@ static void consume_one_event(unsigned cpu,
* control block.
*/
if (head == 0) {
- rmb(); /* Ensure word is up-to-date before reading head. */
+ virt_rmb(); /* Ensure word is up-to-date before reading head. */
head = control_block->head[priority];
}
--
MST
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] What is Ganeti?
On Thu, 2015-12-31 at 17:50 +, Jason Long wrote: > Hello. > Can anyone tell me about "Ganeti" ? Is it a replacement for Xen? https://code.google.com/p/ganeti/ answers this quite clearly IMHO. You should have been able to easily discover this page for yourself before asking here. (Completely leaving aside why you would ask on xen-devel about a tool which you apparently think replaces Xen, rather than asking them). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/events: use virt_xxx barriers
On 04/01/16 11:46, Michael S. Tsirkin wrote: > drivers/xen/events/events_fifo.c uses rmb() to communicate with the > other side. > > For guests compiled with CONFIG_SMP, smp_rmb would be sufficient, so > rmb() here is only needed if a non-SMP guest runs on an SMP host. > > Switch to the virt_rmb barrier which serves this exact purpose. > > Pull in asm/barrier.h here to make sure the file is self-contained. Thanks! Acked-by: David Vrabel David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] blkback name greater than 16 characters issue
On Mon, Dec 14, 2015 at 11:46:35AM -0500, Konrad Rzeszutek Wilk wrote: > Hey, > > Way back in the past Jan pointed out this issue > http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg03505.html > > which is that the device name is "blkback.." > > for exmaple: blkback.8.xvda, blkback.11.hda > > With the multiqueue block backend we add "-%d" for the queue. > But sadly this is already way past the limit so it gets stripped. > > > Possible solution had been identified by Ian: > http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg03516.html > > " > If you are pressed for space then the "xvd" is probably a bit redundant > in a string which starts blkbk. > > The guest may not even call the device xvdN (iirc BSD has another > prefix) any how, so having blkback say so seems of limited use anyway. > > Since this seems to not include a partition number how does this work in > the split partition scheme? (i.e. one where the guest is given xvda1 and > xvda2 rather than xvda with a partition table) > > [It will be 'blkback.8.xvda1', and 'blkback.11.xvda2'] > > Perhaps something derived from one of the schemes in > http://xenbits.xen.org/docs/unstable/misc/vbd-interface.txt might be a > better fit? > " > > [Inline is my answer] > > My desire is to easily correlate the name of the thread with the > guest config. And that means preserving the 'xvda' or 'hda' or whatever > the user had in mind. > > I believe the domain id is important as well - so we need that. > > Which means we are left with the prefix. Should it be 'blkbk' or > should it be completely eliminated? Meaning we have: > > 8.xvda > 11.hda > > and > 9.xvda-1 > 9.xvda-2 > 32100.xvdfg9-5 > > Or perhaps use 'blk." > > blk.32100.xvdfg9-5 > (exactly 17, so '5' is gone). > > Perhaps in those occassions drop 'blk.' altogether? But I wouldn't want > a special case, so back to: > > 32100.xvdfg9-5 > > ? Thoughts? > > Or > ? Or enlarge TASK_COMM_LEN? :-) Jokes aside, 'git grep blkback' in tools directory doesn't show any reference to "blkback" in code (as I would expect), so there is no risk in breaking tookstack should you change the name. I don't really have a preference whatsoever on this. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] patch about "don't reset vcpu_info on a cancelled suspend"
On 29/12/15 05:49, Ouyangzhaowei (Charles) wrote: > Hi David, > > This patch has been applied to for-linus-4.1b, and we wonder if this patch > will be applied to linux kernel, or does > it still needs more test to apply to linux kernel? Sorry, it looks like I forgot to send a pull request for this patch. I'd applied it to for-linus-4.5 and tagged it for stable. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/events: use virt_xxx barriers
Hi Michael,
[auto build test ERROR on v4.4-rc8]
[also build test ERROR on next-20151231]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Michael-S-Tsirkin/xen-events-use-virt_xxx-barriers/20160104-194916
config: x86_64-randconfig-x008-01040711 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/xen/events/events_fifo.c: In function 'consume_one_event':
>> drivers/xen/events/events_fifo.c:300:3: error: implicit declaration of
>> function 'virt_rmb' [-Werror=implicit-function-declaration]
virt_rmb(); /* Ensure word is up-to-date before reading head. */
^
cc1: some warnings being treated as errors
vim +/virt_rmb +300 drivers/xen/events/events_fifo.c
294
295 /*
296 * Reached the tail last time? Read the new HEAD from the
297 * control block.
298 */
299 if (head == 0) {
> 300 virt_rmb(); /* Ensure word is up-to-date before reading
> head. */
301 head = control_block->head[priority];
302 }
303
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 31/34] xenbus: use __smp_XXX barriers
On Wed, 30 Dec 2015, Michael S. Tsirkin wrote:
> drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
>
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
>
> Switch to __smp_XXX barriers which serve this exact purpose.
>
> Signed-off-by: Michael S. Tsirkin
Reviewed-by: Stefano Stabellini
> This is straight-forward, but untested.
> I can either merge this patchset through my tree if this is
> acked, or defer this and merge the patchset first,
> and xen bits through xen tree afterwards.
>
> Pls let me know.
I think it can go via your tree. However you have missed a few Xen
source files which need the same mb/__smb_mb conversions:
drivers/xen/grant-table.c
drivers/xen/evtchn.c
drivers/xen/events/events_fifo.c
drivers/xen/xen-scsiback.c
drivers/xen/tmem.c
drivers/xen/xen-pciback/pci_stub.c
drivers/xen/xen-pciback/pciback_ops.c
> drivers/xen/xenbus/xenbus_comms.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/xen/xenbus/xenbus_comms.c
> b/drivers/xen/xenbus/xenbus_comms.c
> index fdb0f33..09b17c7 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -123,14 +123,14 @@ int xb_write(const void *data, unsigned len)
> avail = len;
>
> /* Must write data /after/ reading the consumer index. */
> - mb();
> + __smp_mb();
>
> memcpy(dst, data, avail);
> data += avail;
> len -= avail;
>
> /* Other side must not see new producer until data is there. */
> - wmb();
> + __smp_wmb();
> intf->req_prod += avail;
>
> /* Implies mb(): other side will see the updated producer. */
> @@ -180,14 +180,14 @@ int xb_read(void *data, unsigned len)
> avail = len;
>
> /* Must read data /after/ reading the producer index. */
> - rmb();
> + __smp_rmb();
>
> memcpy(data, src, avail);
> data += avail;
> len -= avail;
>
> /* Other side must not see free space until we've copied out */
> - mb();
> + __smp_mb();
> intf->rsp_cons += avail;
>
> pr_debug("Finished read of %i bytes (%i to go)\n", avail, len);
> --
> MST
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 32/34] xen/io: use __smp_XXX barriers
On Wed, 30 Dec 2015, Michael S. Tsirkin wrote:
> include/xen/interface/io/ring.h uses
> full memory barriers to communicate with the other side.
>
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
>
> Switch to __smp_XXX barriers which serve this exact purpose.
>
> Signed-off-by: Michael S. Tsirkin
Reviewed-by: Stefano Stabellini
> include/xen/interface/io/ring.h | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
> index 7dc685b..46dfc65 100644
> --- a/include/xen/interface/io/ring.h
> +++ b/include/xen/interface/io/ring.h
> @@ -208,12 +208,12 @@ struct __name##_back_ring {
> \
>
>
> #define RING_PUSH_REQUESTS(_r) do { \
> -wmb(); /* back sees requests /before/ updated producer index */ \
> +__smp_wmb(); /* back sees requests /before/ updated producer index */
> \
> (_r)->sring->req_prod = (_r)->req_prod_pvt;
> \
> } while (0)
>
> #define RING_PUSH_RESPONSES(_r) do { \
> -wmb(); /* front sees responses /before/ updated producer index */
> \
> +__smp_wmb(); /* front sees responses /before/ updated producer index */
> \
> (_r)->sring->rsp_prod = (_r)->rsp_prod_pvt;
> \
> } while (0)
>
> @@ -250,9 +250,9 @@ struct __name##_back_ring {
> \
> #define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do {
> \
> RING_IDX __old = (_r)->sring->req_prod; \
> RING_IDX __new = (_r)->req_prod_pvt; \
> -wmb(); /* back sees requests /before/ updated producer index */ \
> +__smp_wmb(); /* back sees requests /before/ updated producer index */
> \
> (_r)->sring->req_prod = __new; \
> -mb(); /* back sees new requests /before/ we check req_event */ \
> +__smp_mb(); /* back sees new requests /before/ we check req_event */
> \
> (_notify) = ((RING_IDX)(__new - (_r)->sring->req_event) <
> \
>(RING_IDX)(__new - __old));\
> } while (0)
> @@ -260,9 +260,9 @@ struct __name##_back_ring {
> \
> #define RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(_r, _notify) do {
> \
> RING_IDX __old = (_r)->sring->rsp_prod; \
> RING_IDX __new = (_r)->rsp_prod_pvt; \
> -wmb(); /* front sees responses /before/ updated producer index */
> \
> +__smp_wmb(); /* front sees responses /before/ updated producer index */
> \
> (_r)->sring->rsp_prod = __new; \
> -mb(); /* front sees new responses /before/ we check rsp_event */ \
> +__smp_mb(); /* front sees new responses /before/ we check rsp_event */
> \
> (_notify) = ((RING_IDX)(__new - (_r)->sring->rsp_event) <
> \
>(RING_IDX)(__new - __old));\
> } while (0)
> @@ -271,7 +271,7 @@ struct __name##_back_ring {
> \
> (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);
> \
> if (_work_to_do) break; \
> (_r)->sring->req_event = (_r)->req_cons + 1; \
> -mb();\
> +__smp_mb();
> \
> (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);
> \
> } while (0)
>
> @@ -279,7 +279,7 @@ struct __name##_back_ring {
> \
> (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);
> \
> if (_work_to_do) break; \
> (_r)->sring->rsp_event = (_r)->rsp_cons + 1; \
> -mb();\
> +__smp_mb();
> \
> (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);
> \
> } while (0)
>
> --
> MST
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 33/34] xenbus: use virt_xxx barriers
On Thu, 31 Dec 2015, Michael S. Tsirkin wrote:
> drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
>
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
>
> Switch to virt_xxx barriers which serve this exact purpose.
>
> Signed-off-by: Michael S. Tsirkin
Reviewed-by: Stefano Stabellini
Are you also going to take care of
drivers/xen/grant-table.c
drivers/xen/evtchn.c
drivers/xen/events/events_fifo.c
drivers/xen/xen-scsiback.c
drivers/xen/tmem.c
drivers/xen/xen-pciback/pci_stub.c
drivers/xen/xen-pciback/pciback_ops.c
?
> drivers/xen/xenbus/xenbus_comms.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/xen/xenbus/xenbus_comms.c
> b/drivers/xen/xenbus/xenbus_comms.c
> index fdb0f33..ecdecce 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -123,14 +123,14 @@ int xb_write(const void *data, unsigned len)
> avail = len;
>
> /* Must write data /after/ reading the consumer index. */
> - mb();
> + virt_mb();
>
> memcpy(dst, data, avail);
> data += avail;
> len -= avail;
>
> /* Other side must not see new producer until data is there. */
> - wmb();
> + virt_wmb();
> intf->req_prod += avail;
>
> /* Implies mb(): other side will see the updated producer. */
> @@ -180,14 +180,14 @@ int xb_read(void *data, unsigned len)
> avail = len;
>
> /* Must read data /after/ reading the producer index. */
> - rmb();
> + virt_rmb();
>
> memcpy(data, src, avail);
> data += avail;
> len -= avail;
>
> /* Other side must not see free space until we've copied out */
> - mb();
> + virt_mb();
> intf->rsp_cons += avail;
>
> pr_debug("Finished read of %i bytes (%i to go)\n", avail, len);
> --
> MST
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 34/34] xen/io: use virt_xxx barriers
On Thu, 31 Dec 2015, Michael S. Tsirkin wrote:
> include/xen/interface/io/ring.h uses
> full memory barriers to communicate with the other side.
>
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
>
> Switch to virt_xxx barriers which serve this exact purpose.
>
> Signed-off-by: Michael S. Tsirkin
Reviewed-by: Stefano Stabellini
> include/xen/interface/io/ring.h | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
> index 7dc685b..21f4fbd 100644
> --- a/include/xen/interface/io/ring.h
> +++ b/include/xen/interface/io/ring.h
> @@ -208,12 +208,12 @@ struct __name##_back_ring {
> \
>
>
> #define RING_PUSH_REQUESTS(_r) do { \
> -wmb(); /* back sees requests /before/ updated producer index */ \
> +virt_wmb(); /* back sees requests /before/ updated producer index */
> \
> (_r)->sring->req_prod = (_r)->req_prod_pvt;
> \
> } while (0)
>
> #define RING_PUSH_RESPONSES(_r) do { \
> -wmb(); /* front sees responses /before/ updated producer index */
> \
> +virt_wmb(); /* front sees responses /before/ updated producer index */
> \
> (_r)->sring->rsp_prod = (_r)->rsp_prod_pvt;
> \
> } while (0)
>
> @@ -250,9 +250,9 @@ struct __name##_back_ring {
> \
> #define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do {
> \
> RING_IDX __old = (_r)->sring->req_prod; \
> RING_IDX __new = (_r)->req_prod_pvt; \
> -wmb(); /* back sees requests /before/ updated producer index */ \
> +virt_wmb(); /* back sees requests /before/ updated producer index */
> \
> (_r)->sring->req_prod = __new; \
> -mb(); /* back sees new requests /before/ we check req_event */ \
> +virt_mb(); /* back sees new requests /before/ we check req_event */
> \
> (_notify) = ((RING_IDX)(__new - (_r)->sring->req_event) <
> \
>(RING_IDX)(__new - __old));\
> } while (0)
> @@ -260,9 +260,9 @@ struct __name##_back_ring {
> \
> #define RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(_r, _notify) do {
> \
> RING_IDX __old = (_r)->sring->rsp_prod; \
> RING_IDX __new = (_r)->rsp_prod_pvt; \
> -wmb(); /* front sees responses /before/ updated producer index */
> \
> +virt_wmb(); /* front sees responses /before/ updated producer index */
> \
> (_r)->sring->rsp_prod = __new; \
> -mb(); /* front sees new responses /before/ we check rsp_event */ \
> +virt_mb(); /* front sees new responses /before/ we check rsp_event */
> \
> (_notify) = ((RING_IDX)(__new - (_r)->sring->rsp_event) <
> \
>(RING_IDX)(__new - __old));\
> } while (0)
> @@ -271,7 +271,7 @@ struct __name##_back_ring {
> \
> (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);
> \
> if (_work_to_do) break; \
> (_r)->sring->req_event = (_r)->req_cons + 1; \
> -mb();\
> +virt_mb();
> \
> (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);
> \
> } while (0)
>
> @@ -279,7 +279,7 @@ struct __name##_back_ring {
> \
> (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);
> \
> if (_work_to_do) break; \
> (_r)->sring->rsp_event = (_r)->rsp_cons + 1; \
> -mb();\
> +virt_mb();
> \
> (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);
> \
> } while (0)
>
> --
> MST
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: make flask utils build unconditional
On Mon, Dec 21, 2015 at 10:46:43PM -0600, Doug Goldstein wrote: > The flask utilities only have dependencies on libxc so there's no > downside to always building it. Distros and projects based on Xen can > put these utilities into a different package and not install them for > everyone. Prior to this change FLASK_ENABLE needs to be a top level > variable however after this change FLASK_ENABLE only affects xen/. > > Signed-off-by: Doug Goldstein While it is true about the dependency, enabling flask build unconditionally in toolstack will leave a xenpolicy-$VERSION installed in /boot. Not sure how that will be useful to Xen without flask support. It is true that packager can pick that into separate package, but for people installing from source, this might be a bit confusing. Wei. > --- > tools/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/Makefile b/tools/Makefile > index 820ca40..2f773fd 100644 > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk > SUBDIRS-y := > SUBDIRS-y += include > SUBDIRS-y += libxc > -SUBDIRS-$(FLASK_ENABLE) += flask > +SUBDIRS-y += flask > SUBDIRS-y += xenstore > SUBDIRS-y += misc > SUBDIRS-y += examples > -- > 2.4.10 > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] memory-hotplug: add automatic onlining policy for the newly added memory
On Mon, 04 Jan 2016 11:47:12 +0100
Vitaly Kuznetsov wrote:
> Andrew Morton writes:
>
> > On Tue, 22 Dec 2015 17:32:30 +0100 Vitaly Kuznetsov
> > wrote:
> >
> >> Currently, all newly added memory blocks remain in 'offline' state unless
> >> someone onlines them, some linux distributions carry special udev rules
> >> like:
> >>
> >> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline",
> >> ATTR{state}="online"
> >>
> >> to make this happen automatically. This is not a great solution for virtual
> >> machines where memory hotplug is being used to address high memory pressure
> >> situations as such onlining is slow and a userspace process doing this
> >> (udev) has a chance of being killed by the OOM killer as it will probably
> >> require to allocate some memory.
> >>
> >> Introduce default policy for the newly added memory blocks in
> >> /sys/devices/system/memory/hotplug_autoonline file with two possible
> >> values: "offline" which preserves the current behavior and "online" which
> >> causes all newly added memory blocks to go online as soon as they're added.
> >> The default is "online" when MEMORY_HOTPLUG_AUTOONLINE kernel config option
> >> is selected.
> >
> > I think the default should be "offline" so vendors can ship kernels
> > which have CONFIG_MEMORY_HOTPLUG_AUTOONLINE=y while being
> > back-compatible with previous kernels.
> >
>
> (sorry for the delayed response, just picking things up after holidays)
>
> I was under an (wrong?) impression that in the majority of use cases
> users want to start using their newly added memory right away and that's
> what distros will ship. As an alternative to making the feature off by
> default I can suggest making CONFIG_MEMORY_HOTPLUG_AUTOONLINE a tristate
> switch (no feature, default offline, default online).
That what probably would satisfy every distro,
only question is why do you need 'no feature',
wouldn't 'default offline' cover current state?
>
> >> --- a/Documentation/kernel-parameters.txt
> >> +++ b/Documentation/kernel-parameters.txt
> >> @@ -2537,6 +2537,8 @@ bytes respectively. Such letter suffixes can also be
> >> entirely omitted.
> >>shutdown the other cpus. Instead use the REBOOT_VECTOR
> >>irq.
> >>
> >> + nomemhp_autoonline Don't automatically online newly added memory.
> >> +
> >
> > This wasn't mentioned in the changelog. Why do we need a boot
> > parameter as well as the sysfs knob?
if 'default online' policy is set then we need a kernel option to disable
auto-onlining at kernel boot time (when it parses ACPI tables for x86) if needed
and vice verse for 'default offline' to enable auto-onlining at kernel boot
time.
For RHEL we would probably use 'default online' policy like
we do in RHEL6 with custom patch.
> >
>
> I was thinking about some faulty hardware (e.g. reporting new memory
> blocks which for some reason are not really usable) and an easy way to
> make such hardware work.
>
> >> +config MEMORY_HOTPLUG_AUTOONLINE
> >> + bool "Automatically online hot-added memory"
> >> + depends on MEMORY_HOTPLUG_SPARSE
> >> + help
> >> +When memory is hot-added, it is not at ready-to-use state, a special
> >
> > "When memory is hot-added it is not in a ready-to-use state. A special"
> >
> >> +userspace action is required to online the newly added blocks. With
> >> +this option enabled, the kernel will try to online all newly added
> >> +memory automatically.
> >> +
> >>
> >> ...
> >>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Missing libvirt+libxl functionality (Was: Re: [Xen-users] Programmatic administration of Xen machines)
On Mon, 2016-01-04 at 13:31 +0100, Andreas Pflug wrote: > Am 04.01.16 um 13:13 schrieb Ian Campbell: > > On Mon, 2016-01-04 at 12:47 +0100, Andreas Pflug wrote: > > > Am 04.01.16 um 12:36 schrieb Ian Campbell: > > > > Sorry to hijack this thread. > > > > > > > > On Mon, 2015-12-28 at 12:56 +0100, Andreas Pflug wrote: > > > > > Actually, I find virsh a bad idea since its support for the new > > > > > xl > > > > > interface isn't feature complete as the old xm interface was. I > > > > > had > > > > > to > > > > > realize this the hard way when my virsh based python tools didn't > > > > > work > > > > > as expected after upgrading from xm to xl. > > > > Note that virsh speaks to libxl directly, not via xl. > > > > > > > > Please can you list the functionality of libvirt's libxl backed > > > > which > > > > is > > > > missing compared to the old xend based one? > > > libvirt only handles domains created through it, i.e. using xl at the > > > same time is incompatible. Since dom0 can't be created using libvirt, > > > it's missing from "virsh list" in any case. > > This works for me with a reasonably modern set of bits: > > > > root@marilith-n0:~# virsh list > > IdName State > > > > 0 Domain-0 running > > 13d running > > > > It probably requires the correct running of xen-init-dom0 during boot > > (likely via the xencommons initscript). > > > > I could believe it was broken at some point in history though. > > > > > libvirt stores its own state, not using libxl/xenstore stuff. > > Please can you elaborate. > I tested on Debian with 4.4.1 and xl toolstack. See the author's blog > post: > https://blog.xenproject.org/2014/01/17/libvirt-support-for-xens-new- > libxenlight-toolstack/ I think that particular aspect of the blog post is no longer valid, at least AFAICT with modern libvirt. > I had even more trouble, e.g. I wasn't able to use non-standard block > scripts (neither via /etc/xen/scripts/block-XXX nor via a script > parameter) which are mandatory for me. Looking at the code it seems like this is still missing. Copying the devel list and maintainer in case I've either missed something or there is a reason for this (other than "still on the TODO list", which I expect is most likely). If you find other shortcomings of libvirt with libxl then I suppose the best way to approach them would be to report them as bugs: http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen (I don't know if Jim or libvirt prefers some other means of doing so). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] support XSM/FLASK via Kconfig
On Tue, 2015-12-22 at 13:00 -0600, Doug Goldstein wrote:
> In antcipation of XSM and FLASK migrating to Kconfig add support for
> building them via Kconfig or the existing mechanism.
>
> Signed-off-by: Doug Goldstein
> ---
> I have not tested this because I'm honestly not sure and I'm not sure if
> this is correct. I'm just trying to write something to prevent a failure
> once XSM/FLASK gets changed to Kconfig and education for myself on how
> to do these patches in the future.
The general shape looks plausible, but it needs to continue working even
with Xen 4.6 and older.
Not sure how best to achieve that, perhaps checking for the existence of
some well known piece of the Kconfig infrastructure and behaving
accordingly?
Another alternative would be to add a runvar (see osstest.git/README for
the terminology) which controls whether Kconfig is to be used expected, but
given that this is static and per branch I'm not sure there is too much
point in this case (and it would be more complex for a newcomer).
Ian J probably has an opinion.
> ---
> ts-xen-build | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/ts-xen-build b/ts-xen-build
> index 80b1faa..6616ed3 100755
> --- a/ts-xen-build
> +++ b/ts-xen-build
> @@ -55,6 +55,8 @@ sub checkout () {
> echo >>.config KERNELS=''
> END
> (nonempty($r{enable_xsm}) ? < + echo >>xen/.config CONFIG_XSM='${build_xsm}'
> + echo >>xen/.config CONFIG_FLASK='${build_xsm}'
> echo >>.config XSM_ENABLE='${build_xsm}'
> END
> (nonempty($r{tree_qemu}) ? < @@ -126,6 +128,7 @@ END
> END
> #/;
> buildcmd_stamped_logged(9000, 'build', '',< +$make_prefix make -C xen olddefconfig
> $make_prefix make $makeflags @ARGV
> END
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] what's the type of nested xen? HVM or PV?
On Thu, 24 Dec 2015, quizyjones wrote: > Happy Holiday, guys. God tell me that I should work this out before celebrate > ; )I create a HVM first, then > compile Xen on it. The dom0 of this Xen is a PV. So is this nested xen a HVM > or a PV? It's hard to differentiate > when concerning to enable events as only HVM supports events. Xen itself, the hypervisor, is neither HVM or PV. HVM and PV are types of virtual machines; the distinction doesn't apply to the hypervisor. Dom0 is always PV (unless you use PVH which is experimental and not something you would use by chance). All the other nested guests are going to be PV unless you passed nestedhvm=1 in your external VM config file. If you passed nestedhvm=1, you can start both nested PV and HVM guests. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory
On Tue, Dec 22, 2015 at 10:06:25AM -0500, Eric Shelton wrote: > The XSA mentions that "PV frontend patches will be developed and > released (publicly) after the embargo date." Has anything been done > towards this that should also be incorporated into MiniOS? On a > system utilizing a "driver domain," where a backend is running on a > domain that is considered unprivileged and untrusted (such as the > example described in http://wiki.xenproject.org/wiki/Driver_Domain), > it seems XSA-155-style double fetch vulnerabilities in the frontends > are also a potential security concern, and should be eliminated. > However, perhaps that does not include pcifront, since pciback would > always be running in dom0. And BTW the same applies to Linux frontends, for which also I haven't seen any public development. In attachment my email to xen-security-issues-discuss list (sent during embargo), with patches attached there. I haven't got any response. PS Dropping minios-devel -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --- Begin Message --- On Fri, Dec 11, 2015 at 11:52:17AM -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Dec 11, 2015 at 12:03:01PM +0100, Marek Marczykowski-Górecki wrote: > > Hi, > > > > In advisory it's said that PV frontend patches will be developed and > > released (publicly) after the embargo date. But in some cases (namely: > > if driver domains are in use), frontends may be more trusted/privileged > > than backends. So it would make sense to consider developing frontend > > patches before embargo end date. At least for the most common ones: > > network and block. > > > > Do you have some list of places that needs to be fixed? I can try to > > help with patches, but need some input on this... Patches (against 4.4) for netfront and blkfront attached. I don't have test case for actual XSA155, but at least it doesn't break normal usage. Below are some comments/questions. Sorry for the delay. > Any code where the shared page is being accessed. For example > blkif_interrupt. Added RING_COPY_RESPONSE here. Probably it would be enough to use just READ_ONCE(bret->operation), but blkif_response isn't that big, so safer option is better. The other places in block frontend are about preparing request - it should not reuse data already put into shared ring, because (malicious) backend might already changed it. Generally added local structure on the stack, filled there and only then put in on the ring. And save a copy to info->shadow[id].req (the original one, not the one from shared ring!). Maybe it would be better to use info->shadow[id].req in the first place (and then copy it to the shared ring)? Theoretically one memory copy less. Does it matter? > We probably should add another macro: RING_COPY_RESPONSE which > would replace the RING_GET_RESPONSE and copy the response to > an on stack variable and then operated on. > > Ditto with xennet_alloc_rx_buffers and the RING_GET_REQUEST. I'm not sure about this one - there is only write to that request, no reads. Or maybe I'm missing some obscure code there? > And > xennet_tx_buf_gc. Additionally added BUG_ON(id >= NET_TX_RING_SIZE). Not sure about the impact of backend giving out of range id, so make sure it's DoS in the _worst_ case. > There is also xennet_tx_setup_grant. It looks like the tx pointer outlive this function. So instead of changing it to local copy, made sure no data is read from that structure (only written). Similar in handling gso in xennet_start_xmit - it's only filled with data. Not sure about xennet_move_rx_slot, but I guess it's safe. > xen-pcifront looks to be safe - it memcopies the fields. However > as I've found out - doing 'memcpy' does not mean the compiler > will do that - it may convert that just to a pointer operation. > So an barrier() will have to be sprinkled in 'do_pci_op'. There is already wmb() after the first memcpy. Is it necessary to have another one before the memcpy in the other direction? $ shasum -a 256 *.patch f7b0c45dbd2c91bee5cc151b1c53b5b452e4e448991204ab6ac6aeb3b5811674 xsa155-linux-0008-xen-Add-RING_COPY_RESPONSE.patch a9f34c6b0b746bdd49594ddabab71ff18477b1cbad62d7cd380f3ca5dc9ff7e3 xsa155-linux-0009-xen-netfront-copy-response-out-of-shared-buffer-befo.patch e924fb7b344135e21c7df9ed6297165275646ea97b9d3072b9f1cc0152d88bec xsa155-linux-0010-xen-netfront-do-not-use-data-already-exposed-to-back.patch 03ac14dcbfb2ccd9e1c375e57e2c9184075d29ffadbaf696a8b015f7eb6bb2c0 xsa155-linux-0011-xen-netfront-add-range-check-for-Tx-response-id.patch e71bbd472b33af4424bee936019b11af2dfc1e3512d13d1aad9713fd8b337227 xsa155-linux-0012-xen-blkfront-make-local-copy-of-response-before-usin.patch 4c99b24ed5092e45c504c84312b619cb77c7ee1169b95002a9ea77fb96523d1d xsa155-linux-0013-xen-blkfront-prepare-request-locally-only-then-put-i.patch -- Best Regards, Marek Marczykowski-Górecki Invisibl
Re: [Xen-devel] [xen-4.5-testing test] 66666: regressions - trouble: broken/fail/pass
On Mon, 2015-12-21 at 09:23 -0700, Jan Beulich wrote: > > > > On 21.12.15 at 17:06, wrote: > > flight 6 xen-4.5-testing real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/6/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. > > vs. 66426 > > test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. > > vs. 66426 > > These seem to fail pretty consistently in 4.6, 4.5, and 4.4, which > seems odd considering that no similar failure was so far seen on > -unstable (flight 66590 included the respective commits, and while > it has many blocked tests the ovmf ones ar not among those). The > guest appears to not make any attempt to reboot (albeit the libxl > log shows that shutdown got initiated), but I can't see no other > oddities in the logs. Thoughts anyone? The bisections all seem to have been unsuccessful (those are posted only to the osstest-output list[0]), e.g. [1] shows that the expected baseline was also unreliable for both cases. I notice that qemu-X.Y-testing also seems to be suffering failures of these cases, but there haven't been any recent passes of qemu-upstream-4.5- testing which might have gotten a lucky pass. Last push seems to have been in September last year. The bisection of the same failure on the qemu-upstream-4.4-testing branch appears to be blocked[2,3]: GenFw: ERROR 3000: Invalid Unsupported section alignment. Which might be fallout from the Jessie update? Ian. [0] http://lists.xenproject.org/archives/html/osstest-output/ [1] http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.5-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.5-testing/test-amd64-i386-xl-qemuu-ovmf-amd64.debian-hvm-install.html [2] http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream-4.4-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html http://logs.test-lab.xenproject.org/osstest/logs/76975/build-amd64/5.ts-xen-build.log Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] what's the type of nested xen? HVM or PV?
On Mon, 2016-01-04 at 12:52 +, Stefano Stabellini wrote: > On Thu, 24 Dec 2015, quizyjones wrote: > > Happy Holiday, guys. God tell me that I should work this out before > > celebrate ; )I create a HVM first, then > > compile Xen on it. The dom0 of this Xen is a PV. So is this nested xen > > a HVM or a PV? It's hard to differentiate > > when concerning to enable events as only HVM supports events. > > Xen itself, the hypervisor, is neither HVM or PV. HVM and PV are types > of virtual machines; the distinction doesn't apply to the hypervisor. I think it's a little more subtle (AKA complicated) than that. The L1 Xen is running "bare metal" inside what L0 Xen sees as an HVM guest. However the L1 Dom0 is running PV, but it is PV WRT the L1 Xen, not the L0 Xen. From the L0's point of view the combination of L0 Xen+Dom0 remains HVM. In fact the PV L1 Dom0 might even be able to see some "PVHVM" like aspects of the L0 HVM domain in which it is running, although typical configurations don't (or can't) make use of that. I'm not sure what the original "enable events" is referring to, so I'm not sure whether this has clarified anything or not. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 06/32] s390: reuse asm-generic/barrier.h
On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote:
> On s390 read_barrier_depends, smp_read_barrier_depends
> smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the
> asm-generic variants exactly. Drop the local definitions and pull in
> asm-generic/barrier.h instead.
>
> This is in preparation to refactoring this code area.
>
> Signed-off-by: Michael S. Tsirkin
> Acked-by: Arnd Bergmann
> ---
> arch/s390/include/asm/barrier.h | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/s390/include/asm/barrier.h b/arch/s390/include/asm/barrier.h
> index 7ffd0b1..c358c31 100644
> --- a/arch/s390/include/asm/barrier.h
> +++ b/arch/s390/include/asm/barrier.h
> @@ -30,14 +30,6 @@
> #define smp_rmb()rmb()
> #define smp_wmb()wmb()
>
> -#define read_barrier_depends() do { } while (0)
> -#define smp_read_barrier_depends() do { } while (0)
> -
> -#define smp_mb__before_atomic() smp_mb()
> -#define smp_mb__after_atomic() smp_mb()
As per:
lkml.kernel.org/r/20150921112252.3c2937e1@mschwide
s390 should change this to barrier() instead of smp_mb() and hence
should not use the generic versions.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/32] mips: reuse asm-generic/barrier.h
On Thu, Dec 31, 2015 at 09:07:10PM +0200, Michael S. Tsirkin wrote:
> -#define smp_store_release(p, v)
> \
> -do { \
> - compiletime_assert_atomic_type(*p); \
> - smp_mb(); \
> - WRITE_ONCE(*p, v); \
> -} while (0)
> -
> -#define smp_load_acquire(p) \
> -({ \
> - typeof(*p) ___p1 = READ_ONCE(*p); \
> - compiletime_assert_atomic_type(*p); \
> - smp_mb(); \
> - ___p1; \
> -})
David Daney wanted to use fancy new MIPS barriers to provide better
implementations of this.
This patch isn't in the way of that, just a FYI.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx
On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote: > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote: > > My only concern is that it gives people an additional handle onto a > > "new" set of barriers - just because they're prefixed with __* > > unfortunately doesn't stop anyone from using it (been there with > > other arch stuff before.) > > > > I wonder whether we should consider making the smp memory barriers > > inline functions, so these __smp_xxx() variants can be undef'd > > afterwards, thereby preventing drivers getting their hands on these > > new macros? > > That'd be tricky to do cleanly since asm-generic depends on > ifndef to add generic variants where needed. > > But it would be possible to add a checkpatch test for this. Wasn't the whole purpose of these things for 'drivers' (namely virtio/xen hypervisor interaction) to use these? And I suppose most of virtio would actually be modules, so you cannot do what I did with preempt_enable_no_resched() either. But yes, it would be good to limit the use of these things. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] Crashes on image file backed VMs
On Sat, 2015-12-19 at 11:18 +, Andre Fucs wrote: > Ian, > > Thanks for the reply. > > coredumpctl gbd PID_OF_PROCESS printed the following: A SIGBUS in QEMU's blk_handle_requests, how exciting! Copying xen-devel and some relevant maintainers, start of thread is http://lists.xen.org/archives/html/xen-users/2015-12/msg00073.html From that, this is Xen 4.5.1 on arch Linux. Andre, could you take a look under /var/log/xen for logs relating to a domain to which this has happened, in particular the qemu log. It would also be useful to see the corresponding guest cfg file I expect. Ian. > [...] > warning: Could not load shared library symbols for linux-vdso.so.1. > Do you need "set solib-search-path" or "set sysroot"? > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > Core was generated by `/usr/lib/xen/bin/qemu-system-i386 -xen-domid 11 > -chardev > socket,id=libxl-cmd,pa'. > Program terminated with signal SIGBUS, Bus error. > #0 0x55b276a618fd in blk_handle_requests (blkdev=0x55b277c49ab0) > at /home/xafucs/xen/src/xen-4.5.1/tools/qemu- > xen/hw/block/xen_disk.c:699 > 699 rp = blkdev->rings.common.sring->req_prod; > [Current thread is 1 (Thread 0x7f68ed0909c0 (LWP 10134))] > (gdb) bt > #0 0x55b276a618fd in blk_handle_requests (blkdev=0x55b277c49ab0) at > /home/xafucs/xen/src/xen-4.5.1/tools/qemu-xen/hw/block/xen_disk.c:699 > #1 blk_bh (opaque=0x55b277c49ab0) at /home/xafucs/xen/src/xen- > 4.5.1/tools/qemu-xen/hw/block/xen_disk.c:738 > #2 0x55b2769e62d3 in aio_bh_poll (ctx=ctx@entry=0x55b277c34600) at > /home/xafucs/xen/src/xen-4.5.1/tools/qemu-xen/async.c:81 > #3 0x55b2769e5efc in aio_poll (ctx=0x55b277c34600, blocking=blocking > @entry=false) at /home/xafucs/xen/src/xen-4.5.1/tools/qemu-xen/aio- > posix.c:188 > #4 0x55b2769e6103 in aio_ctx_dispatch (source=, > callback=, user_data=) > at /home/xafucs/xen/src/xen-4.5.1/tools/qemu-xen/async.c:211 > #5 0x7f68ebf98dc7 in g_main_context_dispatch () from > /usr/lib/libglib-2.0.so.0 > #6 0x55b276b066b1 in glib_pollfds_poll () at > /home/xafucs/xen/src/xen-4.5.1/tools/qemu-xen/main-loop.c:190 > #7 os_host_main_loop_wait (timeout=) at > /home/xafucs/xen/src/xen-4.5.1/tools/qemu-xen/main-loop.c:235 > #8 main_loop_wait (nonblocking=) at > /home/xafucs/xen/src/xen-4.5.1/tools/qemu-xen/main-loop.c:484 > #9 0x55b276b77e09 in main_loop () at /home/xafucs/xen/src/xen- > 4.5.1/tools/qemu-xen/vl.c:2056 > #10 main (argc=, argv=, envp= out>) at /home/xafucs/xen/src/xen-4.5.1/tools/qemu-xen/vl.c:4535 > (gdb) thread 1 > [Switching to thread 1 (Thread 0x7f68ed0909c0 (LWP 10134))] > #0 0x55b276a618fd in blk_handle_requests (blkdev=0x55b277c49ab0) at > /home/xafucs/xen/src/xen-4.5.1/tools/qemu-xen/hw/block/xen_disk.c:699 > 699 rp = blkdev->rings.common.sring->req_prod; > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 20/32] metag: define __smp_xxx
On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote:
> +#ifdef CONFIG_SMP
> +#define fence() metag_fence()
> +#else
> +#define fence() do { } while (0)
> #endif
James, it strikes me as odd that fence() is a no-op instead of a
barrier() for UP, can you verify/explain?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 22/32] s390: define __smp_xxx
On Thu, Dec 31, 2015 at 09:08:38PM +0200, Michael S. Tsirkin wrote: > This defines __smp_xxx barriers for s390, > for use by virtualization. > > Some smp_xxx barriers are removed as they are > defined correctly by asm-generic/barriers.h > > Note: smp_mb, smp_rmb and smp_wmb are defined as full barriers > unconditionally on this architecture. > > Signed-off-by: Michael S. Tsirkin > Acked-by: Arnd Bergmann > --- > arch/s390/include/asm/barrier.h | 15 +-- > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/arch/s390/include/asm/barrier.h b/arch/s390/include/asm/barrier.h > index c358c31..fbd25b2 100644 > --- a/arch/s390/include/asm/barrier.h > +++ b/arch/s390/include/asm/barrier.h > @@ -26,18 +26,21 @@ > #define wmb()barrier() > #define dma_rmb()mb() > #define dma_wmb()mb() > -#define smp_mb() mb() > -#define smp_rmb()rmb() > -#define smp_wmb()wmb() > - > -#define smp_store_release(p, v) > \ > +#define __smp_mb() mb() > +#define __smp_rmb() rmb() > +#define __smp_wmb() wmb() > +#define smp_mb() __smp_mb() > +#define smp_rmb()__smp_rmb() > +#define smp_wmb()__smp_wmb() Why define the smp_*mb() primitives here? Would not the inclusion of asm-generic/barrier.h do this? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] Improved RTDS scheduler
On Mon, Jan 4, 2016 at 7:42 PM, Ian Campbell wrote: > On Thu, 2015-12-31 at 04:45 -0500, Tianyang Chen wrote: >> Budget replenishment is now handled by a dedicated timer which is >> triggered at the most imminent release time of all runnable vcpus. >> >> Signed-off-by: Tianyang Chen >> Signed-off-by: Meng Xu >> Signed-off-by: Dagaen Golomb >> --- >> -cover-letter.patch| 16 +++ >> 0001-Improved-RTDS-scheduler.patch | 280 >> >> bak| 62 > > I assume you didn't actually intend to commit those ;-) No. This version was sent by mistake. Please ignore this version. :-( Tianyang sent another version (v2) with the subject "[PATCH V2 1/1] Improved RTDS scheduler". > > (In general single patches do not require a separate cover letter unless > the required context contains a large amount of information which is not > appropriate for the commit message of the actual change, I'll leave it to > you and the scheduler maintainers to decide how much of your cover letter > it would be appropriate to move to the commit message). The cover letter is supposed to explain the design idea of the improved RTDS scheduler so that reviewers could (potentially) save time in reviewing the patch, we think. :-) Probably, the commit message should be refined and self-contained? Thank you very much for your comments and suggestions! Best, Meng -- --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx
On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote: > On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote: > > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote: > > > > My only concern is that it gives people an additional handle onto a > > > "new" set of barriers - just because they're prefixed with __* > > > unfortunately doesn't stop anyone from using it (been there with > > > other arch stuff before.) > > > > > > I wonder whether we should consider making the smp memory barriers > > > inline functions, so these __smp_xxx() variants can be undef'd > > > afterwards, thereby preventing drivers getting their hands on these > > > new macros? > > > > That'd be tricky to do cleanly since asm-generic depends on > > ifndef to add generic variants where needed. > > > > But it would be possible to add a checkpatch test for this. > > Wasn't the whole purpose of these things for 'drivers' (namely > virtio/xen hypervisor interaction) to use these? Ah, I see, you add virt_*mb() stuff later on for that use case. So, assuming everybody does include asm-generic/barrier.h, you could simply #undef the __smp version at the end of that, once we've generated all the regular primitives from it, no? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 31/32] sh: support a 2-byte smp_store_mb
On Thu, Dec 31, 2015 at 09:09:47PM +0200, Michael S. Tsirkin wrote:
> At the moment, xchg on sh only supports 4 and 1 byte values, so using it
> from smp_store_mb means attempts to store a 2 byte value using this
> macro fail.
>
> And happens to be exactly what virtio drivers want to do.
>
> Check size and fall back to a slower, but safe, WRITE_ONCE+smp_mb.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> arch/sh/include/asm/barrier.h | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/sh/include/asm/barrier.h b/arch/sh/include/asm/barrier.h
> index f887c64..0cc5735 100644
> --- a/arch/sh/include/asm/barrier.h
> +++ b/arch/sh/include/asm/barrier.h
> @@ -32,7 +32,15 @@
> #define ctrl_barrier() __asm__ __volatile__
> ("nop;nop;nop;nop;nop;nop;nop;nop")
> #endif
>
> -#define __smp_store_mb(var, value) do { (void)xchg(&var, value); } while (0)
> +#define __smp_store_mb(var, value) do { \
> + if (sizeof(var) != 4 && sizeof(var) != 1) { \
> + WRITE_ONCE(var, value); \
> + __smp_mb(); \
> + } else { \
> + (void)xchg(&var, value); \
> + } \
> +} while (0)
So SH is an orphaned arch, which is also why I did not comment on using
xchg() for the UP smp_store_mb() thing.
But I really think we should try fixing the xchg() implementation
instead of this duct-tape.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] Improved RTDS scheduler
On Mon, 2016-01-04 at 21:48 +0800, Meng Xu wrote: > > (In general single patches do not require a separate cover letter > > unless > > the required context contains a large amount of information which is > > not > > appropriate for the commit message of the actual change, I'll leave it > > to > > you and the scheduler maintainers to decide how much of your cover > > letter > > it would be appropriate to move to the commit message). > > The cover letter is supposed to explain the design idea of the > improved RTDS scheduler so that reviewers could (potentially) save > time in reviewing the patch, we think. :-) > Probably, the commit message should be refined and self-contained? If I were maintainer of this code I would likely ask that a bunch of the information from the cover letter (i..e anything which would still be relevant to a code archaeologist in 6 months or 10 years) was moved into the commit message, but I'm not maintainer of this code. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] mm: Fix missing #include in
On 12/19/2015 09:30 PM, Ben Hutchings wrote: The various VM_WARN_ON/VM_BUG_ON macros depend on those defined by . Most users already include those, but not all; for example: CC arch/arm64/xen/../../arm/xen/grant-table.o In file included from arch/arm64/include/../../arm/include/asm/xen/page.h:5:0, from arch/arm64/include/asm/xen/page.h:1, from include/xen/page.h:28, from arch/arm64/xen/../../arm/xen/grant-table.c:33: arch/arm64/include/asm/pgtable.h: In function 'set_pte_at': arch/arm64/include/asm/pgtable.h:281:3: error: implicit declaration of function 'BUILD_BUG_ON_INVALID' [-Werror=implicit-function-declaration] VM_WARN_ONCE(!pte_young(pte), Signed-off-by: Ben Hutchings Acked-by: Vlastimil Babka --- include/linux/mmdebug.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h index 877ef22..772362a 100644 --- a/include/linux/mmdebug.h +++ b/include/linux/mmdebug.h @@ -1,6 +1,7 @@ #ifndef LINUX_MM_DEBUG_H #define LINUX_MM_DEBUG_H 1 +#include #include struct page; ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx
On Mon, Jan 04, 2016 at 02:54:20PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote:
> > On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote:
> > > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote:
> >
> > > > My only concern is that it gives people an additional handle onto a
> > > > "new" set of barriers - just because they're prefixed with __*
> > > > unfortunately doesn't stop anyone from using it (been there with
> > > > other arch stuff before.)
> > > >
> > > > I wonder whether we should consider making the smp memory barriers
> > > > inline functions, so these __smp_xxx() variants can be undef'd
> > > > afterwards, thereby preventing drivers getting their hands on these
> > > > new macros?
> > >
> > > That'd be tricky to do cleanly since asm-generic depends on
> > > ifndef to add generic variants where needed.
> > >
> > > But it would be possible to add a checkpatch test for this.
> >
> > Wasn't the whole purpose of these things for 'drivers' (namely
> > virtio/xen hypervisor interaction) to use these?
>
> Ah, I see, you add virt_*mb() stuff later on for that use case.
>
> So, assuming everybody does include asm-generic/barrier.h, you could
> simply #undef the __smp version at the end of that, once we've generated
> all the regular primitives from it, no?
Not so simple - that's why I mentioned using inline functions.
The new smp_* _macros_ are:
+#define smp_mb() __smp_mb()
which means if we simply #undef __smp_mb(), smp_mb() then points at
something which is no longer available, and we'll end up with errors
saying that __smp_mb() doesn't exist.
My suggestion was to change:
#ifndef smp_mb
#define smp_mb()__smp_mb()
#endif
to:
#ifndef smp_mb
static inline void smp_mb(void)
{
__smp_mb();
}
#endif
which then means __smp_mb() and friends can be #undef'd afterwards.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 33/34] xenbus: use virt_xxx barriers
On Thu, Dec 31, 2015 at 09:10:01PM +0200, Michael S. Tsirkin wrote: > drivers/xen/xenbus/xenbus_comms.c uses > full memory barriers to communicate with the other side. > > For guests compiled with CONFIG_SMP, smp_wmb and smp_mb > would be sufficient, so mb() and wmb() here are only needed if > a non-SMP guest runs on an SMP host. > > Switch to virt_xxx barriers which serve this exact purpose. > > Signed-off-by: Michael S. Tsirkin > --- > drivers/xen/xenbus/xenbus_comms.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/xen/xenbus/xenbus_comms.c > b/drivers/xen/xenbus/xenbus_comms.c > index fdb0f33..ecdecce 100644 > --- a/drivers/xen/xenbus/xenbus_comms.c > +++ b/drivers/xen/xenbus/xenbus_comms.c > @@ -123,14 +123,14 @@ int xb_write(const void *data, unsigned len) > avail = len; > > /* Must write data /after/ reading the consumer index. */ > - mb(); > + virt_mb(); > So its possible to remove this barrier entirely, see the "CONTROL DEPENDNCIES" chunk of memory-barrier.txt. But do that in a separate patch series and only if you really really need the performance. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: make flask utils build unconditional
On 1/4/16 6:28 AM, Wei Liu wrote: > On Mon, Dec 21, 2015 at 10:46:43PM -0600, Doug Goldstein wrote: >> The flask utilities only have dependencies on libxc so there's no >> downside to always building it. Distros and projects based on Xen can >> put these utilities into a different package and not install them for >> everyone. Prior to this change FLASK_ENABLE needs to be a top level >> variable however after this change FLASK_ENABLE only affects xen/. >> >> Signed-off-by: Doug Goldstein > > While it is true about the dependency, enabling flask build > unconditionally in toolstack will leave a xenpolicy-$VERSION installed > in /boot. Not sure how that will be useful to Xen without flask support. > > It is true that packager can pick that into separate package, but for > people installing from source, this might be a bit confusing. > > Wei. Wei, This is actually not correct. The installation of that file is controlled by the ./configure script with --enable-xsmpolicy and --disable-xsmpolicy. This patch just makes the utilities be unconditionally built. -- Doug > >> --- >> tools/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/Makefile b/tools/Makefile >> index 820ca40..2f773fd 100644 >> --- a/tools/Makefile >> +++ b/tools/Makefile >> @@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk >> SUBDIRS-y := >> SUBDIRS-y += include >> SUBDIRS-y += libxc >> -SUBDIRS-$(FLASK_ENABLE) += flask >> +SUBDIRS-y += flask >> SUBDIRS-y += xenstore >> SUBDIRS-y += misc >> SUBDIRS-y += examples >> -- >> 2.4.10 >> -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 76949: regressions - FAIL
flight 76949 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/76949/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 66433 build-amd64-xsm 5 xen-build fail REGR. vs. 66433 build-amd64 5 xen-build fail REGR. vs. 66433 build-i386-xsm5 xen-build fail REGR. vs. 66433 build-armhf-xsm 5 xen-build fail REGR. vs. 66433 build-armhf 5 xen-build fail REGR. vs. 66433 Tests which did not succeed, but are not blocking: build-i386-libvirt1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 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 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 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-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-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-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 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-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 bui
Re: [Xen-devel] [PATCH] tools: make flask utils build unconditional
On Mon, Jan 04, 2016 at 08:14:23AM -0600, Doug Goldstein wrote: > On 1/4/16 6:28 AM, Wei Liu wrote: > > On Mon, Dec 21, 2015 at 10:46:43PM -0600, Doug Goldstein wrote: > >> The flask utilities only have dependencies on libxc so there's no > >> downside to always building it. Distros and projects based on Xen can > >> put these utilities into a different package and not install them for > >> everyone. Prior to this change FLASK_ENABLE needs to be a top level > >> variable however after this change FLASK_ENABLE only affects xen/. > >> > >> Signed-off-by: Doug Goldstein > > > > While it is true about the dependency, enabling flask build > > unconditionally in toolstack will leave a xenpolicy-$VERSION installed > > in /boot. Not sure how that will be useful to Xen without flask support. > > > > It is true that packager can pick that into separate package, but for > > people installing from source, this might be a bit confusing. > > > > Wei. > > Wei, > > This is actually not correct. The installation of that file is > controlled by the ./configure script with --enable-xsmpolicy and > --disable-xsmpolicy. > > This patch just makes the utilities be unconditionally built. > You're right. I misread. Sorry for the noise. Acked-by: Wei Liu Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] memory-hotplug: add automatic onlining policy for the newly added memory
David Vrabel writes: > On 22/12/15 16:32, Vitaly Kuznetsov wrote: >> @@ -1292,6 +1304,11 @@ int __ref add_memory_resource(int nid, struct >> resource *res) >> /* create new memmap entry */ >> firmware_map_add_hotplug(start, start + size, "System RAM"); >> >> +/* online pages if requested */ >> +if (online) >> +online_pages(start >> PAGE_SHIFT, size >> PAGE_SHIFT, >> + MMOP_ONLINE_KEEP); > > This will cause the Xen balloon driver to deadlock because it calls > add_memory_resource() with the balloon_mutex locked and the online page > callback also locks the balloon_mutex. Currently xen ballon driver always calls add_memory_resource() with online=false so this won't happen. -- Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 40/62] arm/acpi: Estimate memory required for acpi/efi tables
On Mon, 4 Jan 2016, Shannon Zhao wrote:
> On 2015/11/30 23:14, Julien Grall wrote:
> > Hi Shannon,
> >
> > On 17/11/15 09:40, shannon.z...@linaro.org wrote:
> >> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> >> index 53c7452..78d8ae9 100644
> >> --- a/xen/common/efi/boot.c
> >> +++ b/xen/common/efi/boot.c
> >> @@ -13,6 +13,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #if EFI_PAGE_SIZE != PAGE_SIZE
> >> # error Cannot use xen/pfn.h here!
> >> #endif
> >> @@ -1171,6 +1172,26 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
> >> *SystemTable)
> >> for( ; ; ); /* not reached */
> >> }
> >>
> >> +#ifdef CONFIG_ACPI
> >> +/* Constant to indicate "Xen" in unicode u16 format */
> >> +static const u16 XEN_EFI_FW_VENDOR[] ={0x0058,0x0065,0x006E,0x};
> >> +
> >> +int __init estimate_efi_size(int mem_nr_banks)
> >> +{
> >> +int size;
> >> +int est_size = sizeof(EFI_SYSTEM_TABLE);
> >> +int ect_size = sizeof(EFI_CONFIGURATION_TABLE);
> >> +int emd_size = sizeof(EFI_MEMORY_DESCRIPTOR);
> >> +int fw_vendor_size = sizeof(XEN_EFI_FW_VENDOR);
> >> +
> >> +size = PAGE_ALIGN(est_size + ect_size + fw_vendor_size)
> >> + + PAGE_ALIGN(emd_size *
> >> +(mem_nr_banks + acpi_mem.nr_banks + TBL_MMAX));
> >> +
> >> +return size;
> >> +}
> >> +#endif
> >> +
> >
> > efi/boot.c only contains code related to the stub EFI. This is not the
> > case of this code.
> >
>
> I add these codes at this file because I want to reuse the definitions
> of EFI structures like EFI_SYSTEM_TABLE. Parth re-define those
> structures at previous patch set and one comment suggested to reuse the
> existing ones. If I add these codes in xen/arch/arm/domain_build.c, it
> will have some conflicts. E.g:
>
> In file included from /home/open-source/xen/xen/include/asm/efibind.h:2:0,
> from domain_build.c:29:
> /home/open-source/xen/xen/include/asm/arm64/efibind.h:86:20: error:
> conflicting types for 'UINT64'
> typedef uint64_t UINT64;
> ^
> In file included from /home/open-source/xen/xen/include/acpi/acpi.h:57:0,
> from /home/open-source/xen/xen/include/xen/acpi.h:33,
> from domain_build.c:15:
> /home/open-source/xen/xen/include/acpi/actypes.h:130:35: note: previous
> declaration of 'UINT64' was here
> typedef COMPILER_DEPENDENT_UINT64 UINT64;
I think that having this code in efi/boot.c might be OK, but let's see
what Jan thinks.
> > Moreover, this code won't compile on x86 because acpi_mem is only
> > defined for ARM.
> >
> > Regards,
> >
>
> Thanks,
> --
> Shannon
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: remove the xl list limit of 1024 domains
On 18/12/15 15:34, Juergen Gross wrote:
> xl list is currently limited to 1024 domains. Remove the limit.
>
> Signed-off-by: Juergen Gross
Found a bug, will send V2 soon (together with two other patches
addressing a similar limitation in xl vm-list and tools/xenstat.
Juergen
> ---
> tools/libxl/libxl.c | 37 ++---
> 1 file changed, 18 insertions(+), 19 deletions(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 9207621..83e37a9 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -649,31 +649,30 @@ static void xcinfo2xlinfo(libxl_ctx *ctx,
>
> libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain_out)
> {
> -libxl_dominfo *ptr;
> +libxl_dominfo *ptr = NULL;
> int i, ret;
> xc_domaininfo_t info[1024];
> -int size = 1024;
> +int size = 0;
> +uint32_t domid = 0;
> GC_INIT(ctx);
>
> -ptr = calloc(size, sizeof(libxl_dominfo));
> -if (!ptr) {
> -LOGE(ERROR, "allocating domain info");
> -GC_FREE;
> -return NULL;
> -}
> -
> -ret = xc_domain_getinfolist(ctx->xch, 0, 1024, info);
> -if (ret<0) {
> -LOGE(ERROR, "getting domain info list");
> -free(ptr);
> -GC_FREE;
> -return NULL;
> +for (ret = 1; ret;) {
> +ret = xc_domain_getinfolist(ctx->xch, domid, 1024, info);
> +if (ret < 0) {
> +LOGE(ERROR, "getting domain info list");
> +free(ptr);
> +GC_FREE;
> +return NULL;
> +}
> +ptr = libxl__realloc(NOGC, ptr, (size + ret) *
> sizeof(libxl_dominfo));
> +for (i = 0; i < ret; i++) {
> +xcinfo2xlinfo(ctx, &info[i], &ptr[size + i]);
> +}
> +domid = info[ret - 1].domain + 1;
> +size += ret;
> }
>
> -for (i = 0; i < ret; i++) {
> -xcinfo2xlinfo(ctx, &info[i], &ptr[i]);
> -}
> -*nb_domain_out = ret;
> +*nb_domain_out = size;
> GC_FREE;
> return ptr;
> }
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 40/62] arm/acpi: Estimate memory required for acpi/efi tables
On Thu, 31 Dec 2015, Shannon Zhao wrote:
> On 2015/11/27 0:39, Stefano Stabellini wrote:
> > On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> >> From: Shannon Zhao
> >>
> >> Estimate the memory required for loading acpi/efi tables in Dom0. Alloc
> >> the pages to store the new created EFI and ACPI tables and free these
> >> pages when destroying domain.
> >
> > Could you please explain what you are page aligning exactly and why?
> >
>
> At least it should be 64bit aligned of the table start address. If not,
> guest will throw out an alignment fault.
>
> ACPI: Using GIC for interrupt routing
> Unhandled fault: alignment fault (0x9621) at 0xff86c19c
> Internal error: : 9621 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #551
> Hardware name: (null) (DT)
> task: ffc00887 ti: ffc00884c000 task.ti: ffc00884c000
> PC is at acpi_get_phys_id+0x264/0x290
> LR is at acpi_get_phys_id+0x178/0x290
OK, but between page alignment and 64-bit alignment there is a very big
difference.
> >
> >>
> >> Signed-off-by: Parth Dixit
> >> Signed-off-by: Shannon Zhao
> >> ---
> >> xen/arch/arm/domain.c | 4 +++
> >> xen/arch/arm/domain_build.c | 80
> >> -
> >> xen/common/efi/boot.c | 21
> >> xen/include/asm-arm/setup.h | 2 ++
> >> 4 files changed, 106 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> >> index 880d0a6..10c58c4 100644
> >> --- a/xen/arch/arm/domain.c
> >> +++ b/xen/arch/arm/domain.c
> >> @@ -638,6 +638,10 @@ void arch_domain_destroy(struct domain *d)
> >> domain_vgic_free(d);
> >> domain_vuart_free(d);
> >> free_xenheap_page(d->shared_info);
> >> +#ifdef CONFIG_ACPI
> >> +free_xenheap_pages(d->arch.efi_acpi_table,
> >> + get_order_from_bytes(d->arch.efi_acpi_len));
> >> +#endif
> >> }
> >>
> >> void arch_domain_shutdown(struct domain *d)
> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >> index 0c3441a..b5ed44c 100644
> >> --- a/xen/arch/arm/domain_build.c
> >> +++ b/xen/arch/arm/domain_build.c
> >> @@ -12,6 +12,8 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -1354,6 +1356,78 @@ static int prepare_dtb(struct domain *d, struct
> >> kernel_info *kinfo)
> >> return -EINVAL;
> >> }
> >>
> >> +#ifdef CONFIG_ACPI
> >> +static int estimate_acpi_efi_size(struct domain *d, struct kernel_info
> >> *kinfo)
> >> +{
> >> +u64 efi_size, acpi_size = 0, addr;
> >> +u32 madt_size;
> >> +struct acpi_table_rsdp *rsdp_tbl;
> >> +struct acpi_table_header *table = NULL;
> >> +
> >> +efi_size = estimate_efi_size(kinfo->mem.nr_banks);
> >> +
> >> +acpi_size += PAGE_ALIGN(sizeof(struct acpi_table_fadt));
> >> +acpi_size += PAGE_ALIGN(sizeof(struct acpi_table_stao));
> >> +
> >> +madt_size = sizeof(struct acpi_table_madt)
> >> ++ sizeof(struct acpi_madt_generic_interrupt) *
> >> d->max_vcpus
> >> ++ sizeof(struct acpi_madt_generic_distributor);
> >> +if ( d->arch.vgic.version == GIC_V3 )
> >> +madt_size += sizeof(struct acpi_madt_generic_redistributor)
> >> + * d->arch.vgic.nr_regions;
> >> +acpi_size += PAGE_ALIGN(madt_size);
> >
> > are the MADT and FADT tables guaranteed to be on separate pages or is it
> > just an estimate?
> >
> >
> >> +addr = acpi_os_get_root_pointer();
> >> +if ( !addr )
> >> +{
> >> +printk("Unable to get acpi root pointer\n");
> >> +return -EINVAL;
> >> +}
> >> +rsdp_tbl = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp));
> >> +table = acpi_os_map_memory(rsdp_tbl->xsdt_physical_address,
> >> + sizeof(struct acpi_table_header));
> >> +acpi_size += PAGE_ALIGN(table->length + sizeof(u64));
> >> +acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
> >> +acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp));
> >> +
> >> +acpi_size += PAGE_ALIGN(sizeof(struct acpi_table_rsdp));
> >> +d->arch.efi_acpi_len = PAGE_ALIGN(efi_size) + PAGE_ALIGN(acpi_size);
> >> +
> >> +return 0;
> >> +}
> >> +
> >> +static int prepare_acpi(struct domain *d, struct kernel_info *kinfo)
> >> +{
> >> +int rc = 0;
> >> +int order;
> >> +
> >> +rc = estimate_acpi_efi_size(d, kinfo);
> >> +if ( rc != 0 )
> >> +return rc;
> >> +
> >> +order = get_order_from_bytes(d->arch.efi_acpi_len);
> >> +d->arch.efi_acpi_table = alloc_xenheap_pages(order, 0);
> >> +if ( d->arch.efi_acpi_table == NULL )
> >> +{
> >> +printk("unable to allocate memory!\n");
> >> +return -1;
> >
> > ENOMEM
> >
> >
> >> +}
> >> +memset(d->arch.efi_acpi_table, 0, d->arch.efi_acpi_len);
> >> +
> >> +/* For ACPI,
Re: [Xen-devel] [PATCH v3 1/6] xl: Return proper error codes for block-attach and block-detach
On Tue, Dec 08, 2015 at 05:15:28PM +, Ian Campbell wrote: > On Tue, 2015-12-01 at 11:53 +, George Dunlap wrote: > > Return proper error codes on failure so that scripts can tell whether > > the command completed properly or not. > > > > Also while we're at it, normalize init and dispose of > > libxl_device_disk structures. This means calling init and dispose in > > the actual functions where they are declared. > > > > This in turn means changing parse_disk_config_multistring() to not > > call libxl_device_disk_init. And that in turn means changes to > > callers of parse_disk_config(). > > > > It also means removing libxl_device_disk_init() from > > libxl.c:libxl_vdev_to_device_disk(). This is only called from > > xl_cmdimpl.c. > > ... and the ocaml bindings. > > I can't remember what we decided regarding libxl "getter" functions and > initialisation of the data type (i.e. whose responsibility it is), but it > seems that changing a given calls semantics is rather dangerous API-wise. > > Wei, ISTR you stumbling over this once and the formulation of A Plan(tm), > but I can't remember what it was, can you? > I vaguely remember getting into something about libxl_device_disk_init when I was discussing with with Jim regarding libvirt, but I can't remember exactly what. It's probably a different issue. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] Improved RTDS scheduler
On Mon, 2016-01-04 at 21:48 +0800, Meng Xu wrote: > On Mon, Jan 4, 2016 at 7:42 PM, Ian Campbell > wrote: > > On Thu, 2015-12-31 at 04:45 -0500, Tianyang Chen wrote: > > > Budget replenishment is now handled by a dedicated timer which is > > > triggered at the most imminent release time of all runnable > > > vcpus. > > > > > > Signed-off-by: Tianyang Chen > > > Signed-off-by: Meng Xu > > > Signed-off-by: Dagaen Golomb > > > --- > > > -cover-letter.patch| 16 +++ > > > 0001-Improved-RTDS-scheduler.patch | 280 > > > > > > bak| 62 > > > > I assume you didn't actually intend to commit those ;-) > > No. This version was sent by mistake. Please ignore this version. :-( > > Tianyang sent another version (v2) with the subject "[PATCH V2 1/1] > Improved RTDS scheduler". > Indeed. BTW, I'm back today from Winter Holidays. I'll give a look at this series as soon as practical. I'll comment directly on V2, with the only exception of this very email. So, first of all, Cc list (which is the same here and in V2): how have the names of the people that are in there been picked? The patch is only about xen/common/sched_rt.c. As per MAINTAINERS, the maintainer of the code hosted in that file is just me. Surely it's a good thing to also include George, as he's the other maintainer of scheduling in general. All the other people, though, should not be bothered by being copied directly... Especially IanC and IanJ, I'd say. > > (In general single patches do not require a separate cover letter > > unless > > the required context contains a large amount of information which > > is not > > appropriate for the commit message of the actual change, I'll leave > > it to > > you and the scheduler maintainers to decide how much of your cover > > letter > > it would be appropriate to move to the commit message). > > The cover letter is supposed to explain the design idea of the > improved RTDS scheduler so that reviewers could (potentially) save > time in reviewing the patch, we think. :-) > Probably, the commit message should be refined and self-contained? > That's true. In particular, the "context", defined as summary of what happened and have been discussed on the mailing list before, during previous submissions, etc., definitely belongs to a cover letter. High level design ideas and concepts, also do, e.g., in order to avoid ending up with commit changelogs that are all several pages long! :-) All that being said, we certainly want patches' subject lines and changelogs to be descriptive of at least what is being done, and why. If we commit this as it is right now, here it is what we'll find in `git log': Improved RTDS scheduler Budget replenishment is now handled by a dedicated timer which is triggered at the most imminent release time of all runnable vcpus. Which won't, I'm quite sure about it, be that much useful when looking at it, say, in 3 years! :-D I know, finding the proper balance of what's better put where is not always super easy, especially at the beginning... but that's part of the process of cooking a good patch (series) :-) A few suggestions: - we want tags in the subject. E.g., in this case, something like "xen: sched: Improved RTDS scheduler" - avoid (in both subject and changelog) generic terms like "improve" "fix", etc., unless you can explain more specifically to what they refer... I mean, pretty much all commits that touch sched_rt.c can have "Improve RTDS" as a subject, can't they? (Unless we decide to commit something making things deliberately worse!! :-)) In this case, e.g. (although, perhaps a bit long): "xen: sched: convert RTDS from time to event driven model" - as Ian said, there are information in the cover letter that can well be moved in the changelog, making it a lot more useful, and not less refined or self contained. Thanks and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
Unfortunately I don't have a setup to test this either. Maybe Lars can
find out who should be involved on the Intel side on this.
In any case, the patch looks good to me. It would be nice to get
feedback from somebody at Intel before applying it, but if we don't get
any to your next version of the patch, I'll probably apply it anyway to
my next branch.
On Tue, 29 Dec 2015, Cao jin wrote:
> Agree with your review point. Since can`t get contact with author
> tiejun.c...@intel.com, maybe only can ask for test help from Stefano, I will
> send next version when we get in touch with stefano.
>
> On 12/29/2015 07:25 PM, Michael S. Tsirkin wrote:
> > On Tue, Dec 29, 2015 at 04:46:03PM +0800, Cao jin wrote:
> > > Signed-off-by: Cao jin
> > > ---
> > > changelog v4:
> > > 1. strip the bugfix code, but I guess this patch should be applied after
> > > that bugfix patch.
> > > 2. Other little fix as per previous review
> > >
> > > Some explanation to previous review:
> > > 1. error_setg_errno() I use in this patch will print the strerror(errno),
> > > so I
> > > guess it will be informative enough? example:
> > >
> > > error_setg_errno(errp, errno, "open %s fail", path); will print:
> > > "open bluhbluh fail: string_from_strerrer(errno)"
> >
> > I'd prefer some mention of why this is attempted too.
> > E.g. "igd passthrough : open bluhbluh fail"
> >
> > > 2. snprintf() has tiny tiny chance to fail,
> >
> > It just formats a string into a buffer. the buffer
> > is pre-allocated, and we know it's large enough for the data.
> > How can it fail?
> >
> >
> > > I don`t assert here, because this
> > > device is on-board, it init during machine initialization, in case it
> > > fails,
> > > the errp we set will results in error_report(err) and exit(1), at
> > > least can
> > > let user know why fail. see the call-chain:
> > >
> > > pc_xen_hvm_init_pci->pc_init1->i440fx_init->pci_create_simple->
> > > pci_create_simple_multifunction->qdev_init_nofail
> >
> > unlike open failing, there's nothing user can do, this means there's
> > a coding bug somewhere, and assert is easier to debug.
> >
> > > About test:
> > > 1. Compiled
> > > 2. Did a dirty hack to force create/realize this device in pc_init1(),
> > > prove
> > > that the realizing process is ok, I will reply this mail later to
> > > attch the
> > > screenshot evidence
> >
> > Good job, thanks!
> > You should also Cc Tiejun Chen who wrote this
> > code, presumably with access to hardware to test on.
> >
> >
> > > hw/pci-host/piix.c | 30 +++---
> > > 1 file changed, 15 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> > > index a9cb983..e91570f 100644
> > > --- a/hw/pci-host/piix.c
> > > +++ b/hw/pci-host/piix.c
> > > @@ -761,7 +761,7 @@ static const IGDHostInfo igd_host_bridge_infos[] = {
> > > {0xa8, 4}, /* SNB: base of GTT stolen memory */
> > > };
> > >
> > > -static int host_pci_config_read(int pos, int len, uint32_t *val)
> > > +static void host_pci_config_read(int pos, int len, uint32_t *val, Error
> > > **errp)
> > > {
> > > char path[PATH_MAX];
> > > int config_fd;
> > > @@ -769,19 +769,19 @@ static int host_pci_config_read(int pos, int len,
> > > uint32_t *val)
> > > /* Access real host bridge. */
> > > int rc = snprintf(path, size,
> > > "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
> > > 0, 0, 0, 0, "config");
> > > -int ret = 0;
> > >
> > > if (rc >= size || rc < 0) {
> > > -return -ENODEV;
> > > +error_setg_errno(errp, errno, "snprintf err");
> > > }
> > >
> > > config_fd = open(path, O_RDWR);
> > > if (config_fd < 0) {
> > > -return -ENODEV;
> > > +error_setg_errno(errp, errno, "open %s fail", path);
> > > +return;
> > > }
> > >
> > > if (lseek(config_fd, pos, SEEK_SET) != pos) {
> > > -ret = -errno;
> > > +error_setg_errno(errp, errno, "lseek err");
> > > goto out;
> > > }
> > >
> > > @@ -789,32 +789,32 @@ static int host_pci_config_read(int pos, int len,
> > > uint32_t *val)
> > > rc = read(config_fd, (uint8_t *)val, len);
> > > } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
> > > if (rc != len) {
> > > -ret = -errno;
> > > +error_setg_errno(errp, errno, "read err");
> > > }
> > >
> > > out:
> > > close(config_fd);
> > > -return ret;
> > > }
> > >
> > > -static int igd_pt_i440fx_initfn(struct PCIDevice *pci_dev)
> > > +static void igd_pt_i440fx_realize(struct PCIDevice *pci_dev, Error
> > > **errp)
> > > {
> > > uint32_t val = 0;
> > > -int rc, i, num;
> > > +int i, num;
> > > int pos, len;
> > > +Error *local_err = NULL;
> > >
> > > num = ARRAY_SIZE(igd_host_bridge_infos);
> > > for (i = 0; i < num; i++) {
> > > pos = igd_host_bridge_info
Re: [Xen-devel] [PATCH trivial v2] xen/Makefile.objs: simplify
On Tue, 29 Dec 2015, Stefan Weil wrote: > Am 29.12.2015 um 13:39 schrieb Cao jin: > > merge last two lines, keep alphabetic order. > > > > Signed-off-by: Cao jin > > --- > > hw/xen/Makefile.objs | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs > > index a9ad7e7..d367094 100644 > > --- a/hw/xen/Makefile.objs > > +++ b/hw/xen/Makefile.objs > > @@ -2,5 +2,4 @@ > > common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o > > > > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o > > -obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o > > xen_pt_msi.o > > -obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o > > xen_pt_msi.o xen_pt_graphics.o > > +obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o > > xen_pt_graphics.o xen_pt_msi.o > > > > Thanks. > > Reviewed-by: Stefan Weil Reviewed-by: Stefano Stabellini Stefan, do you want me to pick this up or are you going to apply it to trivial? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4.4 2/2] libxl: Fix building libxlu_cfg_y.y with bison 3.0
From: Ed Swierk
- Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
parameter
- Change deprecated %name-prefix= to %name-prefix
Tested against bison 2.4.1 and 3.0.2.
This is expected to sometimes (depending on timestamps and whether the
bison input files are edited) break building on systems with ancient
versions of bison. Bison 2.4.1 is known to work and was released in
December 2008.
Also, consquentially, regenerate bison output files with bison
1:2.5.dfsg-2.1 from Debian wheezy.
Signed-off-by: Ed Swierk
Acked-by: Ian Jackson
Tested-by: Wei Liu
Signed-off-by: Ian Jackson
Release-Acked-by: Konrad Rzeszutek Wilk
(cherry picked from commit 7ba4cdfadd4f3c45d65ffe50e621759f458fedc0)
[ I have checked that rebuilding the bison and flex input produces no
further changes. -iwj ]
Signed-off-by: Ian Jackson
---
tools/libxl/libxlu_cfg_y.c |4 ++--
tools/libxl/libxlu_cfg_y.y |6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
index 4437e05..07b5a1d 100644
--- a/tools/libxl/libxlu_cfg_y.c
+++ b/tools/libxl/libxlu_cfg_y.c
@@ -76,7 +76,7 @@
/* Line 268 of yacc.c */
#line 19 "libxlu_cfg_y.y"
-#define YYLEX_PARAM ctx->scanner
+#define ctx_scanner ctx->scanner
#include "libxlu_cfg_i.h"
#include "libxlu_cfg_l.h"
@@ -656,7 +656,7 @@ while (YYID (0))
#ifdef YYLEX_PARAM
# define YYLEX yylex (&yylval, &yylloc, YYLEX_PARAM)
#else
-# define YYLEX yylex (&yylval, &yylloc, scanner)
+# define YYLEX yylex (&yylval, &yylloc, ctx_scanner)
#endif
/* Enable debugging if requested. */
diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
index aa9f787..5acd438 100644
--- a/tools/libxl/libxlu_cfg_y.y
+++ b/tools/libxl/libxlu_cfg_y.y
@@ -17,7 +17,7 @@
*/
%{
-#define YYLEX_PARAM ctx->scanner
+#define ctx_scanner ctx->scanner
#include "libxlu_cfg_i.h"
#include "libxlu_cfg_l.h"
%}
@@ -31,9 +31,9 @@
%pure-parser
%defines
%error-verbose
-%name-prefix="xlu__cfg_yy"
+%name-prefix "xlu__cfg_yy"
%parse-param { CfgParseContext *ctx }
-%lex-param { void *scanner }
+%lex-param { ctx_scanner }
%token IDENT STRING NUMBER NEWLINE
%type atom
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4.4 1/2] libxl: Rerun bison and flex
We are going to want to cherry pick a change to the bison input, which
will involve rerunning bison.
So firstly, update the bison and flex output to that from current
Debian wheezy (i386; 1:2.5.dfsg-2.1 and 2.5.35-10.1 respectively).
There should be no functional change since there is no change to the
source file, but we will inherit bugfixes and behavioural changes from
the new version of bison. So this is more a matter of hope than
knowledge.
Signed-off-by: Ian Jackson
---
tools/libxl/libxlu_cfg_y.c | 538
tools/libxl/libxlu_cfg_y.h | 14 +-
2 files changed, 304 insertions(+), 248 deletions(-)
diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
index 218933e..4437e05 100644
--- a/tools/libxl/libxlu_cfg_y.c
+++ b/tools/libxl/libxlu_cfg_y.c
@@ -1,10 +1,8 @@
+/* A Bison parser, made by GNU Bison 2.5. */
-/* A Bison parser, made by GNU Bison 2.4.1. */
-
-/* Skeleton implementation for Bison's Yacc-like parsers in C
+/* Bison implementation for Yacc-like parsers in C
- Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
- Free Software Foundation, Inc.
+ Copyright (C) 1984, 1989-1990, 2000-2011 Free Software Foundation, Inc.
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
@@ -46,7 +44,7 @@
#define YYBISON 1
/* Bison version. */
-#define YYBISON_VERSION "2.4.1"
+#define YYBISON_VERSION "2.5"
/* Skeleton name. */
#define YYSKELETON_NAME "yacc.c"
@@ -75,7 +73,7 @@
/* Copy the first part of user declarations. */
-/* Line 189 of yacc.c */
+/* Line 268 of yacc.c */
#line 19 "libxlu_cfg_y.y"
#define YYLEX_PARAM ctx->scanner
@@ -83,8 +81,8 @@
#include "libxlu_cfg_l.h"
-/* Line 189 of yacc.c */
-#line 88 "libxlu_cfg_y.c"
+/* Line 268 of yacc.c */
+#line 86 "libxlu_cfg_y.c"
/* Enabling traces. */
#ifndef YYDEBUG
@@ -124,7 +122,7 @@
typedef union YYSTYPE
{
-/* Line 214 of yacc.c */
+/* Line 293 of yacc.c */
#line 25 "libxlu_cfg_y.y"
char *string;
@@ -132,8 +130,8 @@ typedef union YYSTYPE
-/* Line 214 of yacc.c */
-#line 137 "libxlu_cfg_y.c"
+/* Line 293 of yacc.c */
+#line 135 "libxlu_cfg_y.c"
} YYSTYPE;
# define YYSTYPE_IS_TRIVIAL 1
# define yystype YYSTYPE /* obsolescent; will be withdrawn */
@@ -157,8 +155,8 @@ typedef struct YYLTYPE
/* Copy the second part of user declarations. */
-/* Line 264 of yacc.c */
-#line 162 "libxlu_cfg_y.c"
+/* Line 343 of yacc.c */
+#line 160 "libxlu_cfg_y.c"
#ifdef short
# undef short
@@ -208,7 +206,7 @@ typedef short int yytype_int16;
#define YYSIZE_MAXIMUM ((YYSIZE_T) -1)
#ifndef YY_
-# if YYENABLE_NLS
+# if defined YYENABLE_NLS && YYENABLE_NLS
# if ENABLE_NLS
# include /* INFRINGES ON USER NAME SPACE */
# define YY_(msgid) dgettext ("bison-runtime", msgid)
@@ -261,11 +259,11 @@ YYID (yyi)
#define alloca _alloca
# else
#define YYSTACK_ALLOC alloca
-#if ! defined _ALLOCA_H && ! defined _STDLIB_H && (defined __STDC__ ||
defined __C99__FUNC__ \
+#if ! defined _ALLOCA_H && ! defined EXIT_SUCCESS && (defined __STDC__ ||
defined __C99__FUNC__ \
|| defined __cplusplus || defined _MSC_VER)
# include /* INFRINGES ON USER NAME SPACE */
-# ifndef _STDLIB_H
-# define _STDLIB_H 1
+# ifndef EXIT_SUCCESS
+# define EXIT_SUCCESS 0
# endif
#endif
# endif
@@ -288,24 +286,24 @@ YYID (yyi)
# ifndef YYSTACK_ALLOC_MAXIMUM
# define YYSTACK_ALLOC_MAXIMUM YYSIZE_MAXIMUM
# endif
-# if (defined __cplusplus && ! defined _STDLIB_H \
+# if (defined __cplusplus && ! defined EXIT_SUCCESS \
&& ! ((defined YYMALLOC || defined malloc) \
&& (defined YYFREE || defined free)))
# include /* INFRINGES ON USER NAME SPACE */
-# ifndef _STDLIB_H
-#define _STDLIB_H 1
+# ifndef EXIT_SUCCESS
+#define EXIT_SUCCESS 0
# endif
# endif
# ifndef YYMALLOC
# define YYMALLOC malloc
-# if ! defined malloc && ! defined _STDLIB_H && (defined __STDC__ || defined
__C99__FUNC__ \
+# if ! defined malloc && ! defined EXIT_SUCCESS && (defined __STDC__ ||
defined __C99__FUNC__ \
|| defined __cplusplus || defined _MSC_VER)
void *malloc (YYSIZE_T); /* INFRINGES ON USER NAME SPACE */
# endif
# endif
# ifndef YYFREE
# define YYFREE free
-# if ! defined free && ! defined _STDLIB_H && (defined __STDC__ || defined
__C99__FUNC__ \
+# if ! defined free && ! defined EXIT_SUCCESS && (defined __STDC__ ||
defined __C99__FUNC__ \
|| defined __cplusplus || defined _MSC_VER)
void free (void *); /* INFRINGES ON USER NAME SPACE */
# endif
@@ -336,23 +334,7 @@ union yyalloc
((N) * (sizeof (yytype_int16) + sizeof (YYSTYPE) + sizeof (YYLTYPE)) \
+ 2 * YYSTACK_GAP_MAXIMUM)
-/* Copy COUNT objects from FROM to TO. The source and destination do
- not overlap. */
-# ifndef YYCOPY
-# if defined __GNUC__ &&
Re: [Xen-devel] [PATCH v3 20/62] arm/acpi: Add ACPI support for SMP initialization
On Wed, 30 Dec 2015, Shannon Zhao wrote: > On 2015/11/30 22:57, Julien Grall wrote: > > Hi Shannon, > > > > On 17/11/15 09:40, shannon.z...@linaro.org wrote: > >> > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c > >> > index d800cb6..dede0e1 100644 > >> > --- a/xen/arch/arm/psci.c > >> > +++ b/xen/arch/arm/psci.c > >> > @@ -22,6 +22,7 @@ > >> > #include > >> > #include > >> > #include > >> > +#include > >> > > >> > /* > >> > * While a 64-bit OS can make calls with SMC32 calling conventions, for > >> > @@ -86,6 +87,9 @@ int __init psci_init_0_1(void) > >> > int ret; > >> > const struct dt_device_node *psci; > >> > > >> > +if ( !acpi_disabled ) > >> > +return -EINVAL; > > Please explain in the commit message why PSCI 0.1 is not supported on ACPI. > > Hi, > > I check this again. There are not limitations of supporting PSCI version > in ACPI SPEC. It should support PSCI 0.1 as well. But look at the code > of linux kernel, it says it only supports PSCI 0.2+. > > #define ACPI_FADT_PSCI_COMPLIANT(1) /* 00: [V5+] PSCI 0.2+ is > implemented */ > > So does it need to be consistent with Linux or support PSCI 0.1 in Xen > as well? I don't think it needs to be consistent with Linux. I would support PSCI 0.1 too. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 52/62] arm/acpi: Prepare EFI memory descriptor for Dom0
On Thu, 31 Dec 2015, Shannon Zhao wrote:
> On 2015/11/27 22:30, Stefano Stabellini wrote:
> > On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> >> > From: Shannon Zhao
> >> >
> >> > Create a few EFI memory descriptors to tell Dom0 the RAM region
> >> > information, ACPI table regions and EFI tables reserved resions.
> >> >
> >> > Signed-off-by: Parth Dixit
> >> > Signed-off-by: Shannon Zhao
> >> > ---
> >> > xen/arch/arm/domain_build.c | 2 ++
> >> > xen/common/efi/boot.c | 48
> >> > +
> >> > xen/include/asm-arm/setup.h | 4
> >> > 3 files changed, 54 insertions(+)
> >> >
> >> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >> > index 9d667ea..073c634 100644
> >> > --- a/xen/arch/arm/domain_build.c
> >> > +++ b/xen/arch/arm/domain_build.c
> >> > @@ -1737,6 +1737,8 @@ static int prepare_acpi(struct domain *d, struct
> >> > kernel_info *kinfo)
> >> > acpi_map_rest_tables(d);
> >> > acpi_create_efi_system_table(d->arch.efi_acpi_gpa,
> >> > d->arch.efi_acpi_table,
> >> > tbl_add);
> >> > +acpi_create_efi_mmap_table(d->arch.efi_acpi_gpa,
> >> > d->arch.efi_acpi_table,
> >> > + &kinfo->mem, tbl_add);
> >> >
> >> > return 0;
> >> > }
> >> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> >> > index 75835ae..ff2faed 100644
> >> > --- a/xen/common/efi/boot.c
> >> > +++ b/xen/common/efi/boot.c
> >> > @@ -1256,6 +1256,54 @@ void __init acpi_create_efi_system_table(paddr_t
> >> > paddr, void *efi_acpi_table,
> >> > tbl_add[TBL_EFIT].start = table_addr;
> >> > tbl_add[TBL_EFIT].size = table_size;
> >> > }
> >> > +
> >> > +void __init acpi_create_efi_mmap_table(paddr_t paddr, void
> >> > *efi_acpi_table,
> >> > + const struct meminfo *mem,
> >> > + struct membank tbl_add[])
> > This function shouldn't be in this file.
> >
> >
> >
> >> > +{
> >> > +EFI_MEMORY_DESCRIPTOR *memory_map;
> >> > +int i, offset;
> >> > +u8 *base_ptr;
> >> > +
> >> > +tbl_add[TBL_MMAP].start = paddr + acpi_get_table_offset(tbl_add,
> >> > TBL_MMAP);
> >> > +tbl_add[TBL_MMAP].size = sizeof(EFI_MEMORY_DESCRIPTOR)
> >> > + * (mem->nr_banks + acpi_mem.nr_banks +
> >> > TBL_MMAX);
> >> > +
> >> > +base_ptr = efi_acpi_table + acpi_get_table_offset(tbl_add,
> >> > TBL_MMAP);
> >> > +memory_map = (EFI_MEMORY_DESCRIPTOR *)(base_ptr);
> >> > +
> >> > +offset = 0;
> >> > +for( i = 0; i < mem->nr_banks; i++, offset++ )
> >> > +{
> >> > +memory_map[offset].Type = EfiConventionalMemory;
> >> > +memory_map[offset].PhysicalStart = mem->bank[i].start;
> >> > +memory_map[offset].NumberOfPages = mem->bank[i].size/PAGE_SIZE;
> > Use PAGE_SHIFT throughout the function.
> >
> >
> >> > +memory_map[offset].Attribute = EFI_MEMORY_WB;
> >> > +}
> >> > +
> >> > +for( i = 0; i < acpi_mem.nr_banks; i++, offset++ )
> >> > +{
> >> > +memory_map[offset].Type = EfiACPIReclaimMemory;
> >> > +memory_map[offset].PhysicalStart = acpi_mem.bank[i].start;
> >> > +memory_map[offset].NumberOfPages =
> >> > acpi_mem.bank[i].size/PAGE_SIZE;
> >> > +memory_map[offset].Attribute = EFI_MEMORY_WB;
> >> > +}
> >> > +
> >> > +for( i = 0; i < TBL_EFIT; i++, offset++ )
> >> > +{
> >> > +memory_map[offset].Type = EfiACPIReclaimMemory;
> >> > +memory_map[offset].PhysicalStart = tbl_add[i].start;
> >> > +memory_map[offset].NumberOfPages =tbl_add[i].size/PAGE_SIZE;
> >> > +memory_map[offset].Attribute = EFI_MEMORY_WB;
> >> > +}
> > Can't we just use a single EFI_MEMORY_DESCRIPTOR (or maybe 2, to cover
> > EfiACPIReclaimMemory and EfiReservedMemoryType regions) to describe the
> > whole efi_acpi_gpa region? Using one EFI_MEMORY_DESCRIPTOR per table,
> > and PAGE_ALIGNing each of them, looks like a waste of memory to me.
> > Unless it's an ACPI or EFI spec requirement.
> >
>
> Looking at the UEFI SPEC it says
> "EFI memory descriptors of type EfiACPIReclaimMemory and EfiACPIMemoryNVS
> must be aligned on a 4 KiB boundary and must be a multiple of 4 KiB in size"
OK, but can we use only one, 4 KiB aligned, descriptor for all tables?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.4-testing test] 66583: regressions - FAIL
Ian Campbell writes ("Re: [Xen-devel] [xen-4.4-testing test] 66583: regressions
- FAIL"):
> I think we want to backport:
>
> commit 345e44a85d71a1a910385f33c7f1ba3683026d18
> Author: Dario Faggioli
> Date: Fri Jun 20 16:09:00 2014 +0200
This is already in stable-4.4, as 5e39eb05, and has been since June.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/3] xenstat: handle more than 1024 domains
get_domain_ids() in libxenstat used by read_attributes_qdisk() is
limited to 1024 domains. Remove that limit.
Signed-off-by: Juergen Gross
---
tools/xenstat/libxenstat/src/xenstat_qmp.c | 67 +-
1 file changed, 29 insertions(+), 38 deletions(-)
diff --git a/tools/xenstat/libxenstat/src/xenstat_qmp.c
b/tools/xenstat/libxenstat/src/xenstat_qmp.c
index 5e261af..5104afb 100644
--- a/tools/xenstat/libxenstat/src/xenstat_qmp.c
+++ b/tools/xenstat/libxenstat/src/xenstat_qmp.c
@@ -356,18 +356,6 @@ static int qmp_connect(char *path)
return s;
}
-/* Get up to 1024 active domains */
-static xc_domaininfo_t *get_domain_ids(xc_interface *xc_handle, int *num_doms)
-{
- xc_domaininfo_t *dominfo;
-
- dominfo = calloc(1024, sizeof(xc_domaininfo_t));
- if (dominfo == NULL)
- return NULL;
- *num_doms = xc_domain_getinfolist(xc_handle, 0, 1024, dominfo);
- return dominfo;
-}
-
/* Gather the qdisk statistics by querying QMP
Resources: http://wiki.qemu.org/QMP and qmp-commands.hx from the qemu code
QMP Syntax for entering command mode. This command must be issued before
@@ -398,44 +386,47 @@ void read_attributes_qdisk(xenstat_node * node)
{
char *cmd_mode = "{ \"execute\": \"qmp_capabilities\" }";
char *query_blockstats_cmd = "{ \"execute\": \"query-blockstats\" }";
- xc_domaininfo_t *dominfo = NULL;
+ xc_domaininfo_t dominfo[1024];
unsigned char *qmp_stats, *val;
char path[80];
int i, qfd, num_doms;
+ domid_t next_domid = 0;
- dominfo = get_domain_ids(node->handle->xc_handle, &num_doms);
- if (dominfo == NULL)
- return;
+ for (;;) {
+ num_doms = xc_domain_getinfolist(node->handle->xc_handle,
next_domid, 1024, dominfo);
+ if (num_doms <= 0)
+ return;
- for (i=0; ihandle->xshandle, XBT_NULL, path,
NULL)) == NULL)
- continue;
- free(val);
+ /* Verify that qdisk disks are used with this VM */
+ snprintf(path,
sizeof(path),"/local/domain/0/backend/qdisk/%i", dominfo[i].domain);
+ if ((val = xs_read(node->handle->xshandle, XBT_NULL,
path, NULL)) == NULL)
+ continue;
+ free(val);
- /* Connect to this VMs QMP socket */
- snprintf(path, sizeof(path), "/var/run/xen/qmp-libxenstat-%i",
dominfo[i].domain);
- if ((qfd = qmp_connect(path)) < 0) {
- continue;
- }
+ /* Connect to this VMs QMP socket */
+ snprintf(path, sizeof(path),
"/var/run/xen/qmp-libxenstat-%i", dominfo[i].domain);
+ if ((qfd = qmp_connect(path)) < 0) {
+ continue;
+ }
- /* First enable QMP capabilities so that we can query for data
*/
- if ((qmp_stats = qmp_query(qfd, cmd_mode)) != NULL) {
- free(qmp_stats);
- /* Query QMP for this VMs blockstats */
- if ((qmp_stats = qmp_query(qfd, query_blockstats_cmd))
!= NULL) {
- qmp_parse_stats(node, dominfo[i].domain,
qmp_stats, qfd);
+ /* First enable QMP capabilities so that we can query
for data */
+ if ((qmp_stats = qmp_query(qfd, cmd_mode)) != NULL) {
free(qmp_stats);
+ /* Query QMP for this VMs blockstats */
+ if ((qmp_stats = qmp_query(qfd,
query_blockstats_cmd)) != NULL) {
+ qmp_parse_stats(node,
dominfo[i].domain, qmp_stats, qfd);
+ free(qmp_stats);
+ }
}
+ close(qfd);
}
- close(qfd);
- }
- free(dominfo);
+ next_domid = dominfo[num_doms - 1].domain + 1;
+ }
}
#else /* !HAVE_YAJL_V2 */
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/3] libxl: base libxl_list_vm() on libxl_list_domain()
libxl_list_vm() is calling xc_domain_getinfolist() today with a limit
of 1024 domains. To avoid open coding a loop around
xc_domain_getinfolist() to avoid the 1024 domain limit just use
libxl_list_domain() instead.
Suggested-by: Andrew Cooper
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 86b08d9..abb2845 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -799,32 +799,31 @@ out:
libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out)
{
GC_INIT(ctx);
+libxl_dominfo *info;
libxl_vminfo *ptr = NULL;
-int idx, i, ret;
-xc_domaininfo_t info[1024];
+int idx, i, n_doms;
-ret = xc_domain_getinfolist(ctx->xch, 1, ARRAY_SIZE(info), info);
-if (ret < 0) {
-LOGE(ERROR, "getting domain info list");
+info = libxl_list_domain(ctx, &n_doms);
+if (!info)
goto out;
-}
/*
* Always make sure to allocate at least one element; if we don't and we
* request zero, libxl__calloc (might) think its internal call to calloc
* has failed (if it returns null), if so it would kill our process.
*/
-ptr = libxl__calloc(NOGC, ret ? ret : 1, sizeof(libxl_vminfo));
+ptr = libxl__calloc(NOGC, n_doms ? n_doms : 1, sizeof(libxl_vminfo));
-for (idx = i = 0; i < ret; i++) {
-if (libxl_is_stubdom(ctx, info[i].domain, NULL))
+for (idx = i = 0; i < n_doms; i++) {
+if (libxl_is_stubdom(ctx, info[i].domid, NULL))
continue;
-memcpy(&(ptr[idx].uuid), info[i].handle, sizeof(xen_domain_handle_t));
-ptr[idx].domid = info[i].domain;
+ptr[idx].uuid = info[i].uuid;
+ptr[idx].domid = info[i].domid;
idx++;
}
*nb_vm_out = idx;
+libxl_dominfo_list_free(info, n_doms);
out:
GC_FREE;
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.3-testing test] 66638: regressions - FAIL
Ian Campbell writes ("Re: [Xen-devel] [xen-4.3-testing test] 66638: regressions
- FAIL"):
> This is failing to build 4.2 (-prev job in a 4.3 branch), and I think would
> be fixed by a backport to that branch of:
>
> commit 665ddd98c4d418ced6f303b79b7a6322c69b7247
> Author: Olaf Hering
> Date: Thu Jun 27 16:56:18 2013 +0200
I think we should probably drop this job in the 4.3 branch (and
earlier). 4.2 has had no commits since October - in particular, none
of the recent security fixes - and I would be reluctant to give it a
veneer of activity.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.3-testing test] 76954: regressions - FAIL
flight 76954 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/76954/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 62112 build-amd64 5 xen-build fail REGR. vs. 62112 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-pv1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-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-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 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-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-pv 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a version targeted for testing: qemuu6e184363e64a0610c35ca231bfc73cea56eb02f3 baseline version: qemuub188780861662e8cf1847ec562799b32bb44f05e Last test of basis62112 2015-09-18 04:07:28 Z 108 days Testing same since66538 2015-12-18 16:12:07 Z 16 days7 attempts People who touched revisions under test: Stefano Stabellini jobs: build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-credit2 blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-xl-multivcpublocked test-amd64-amd64-pairblocked test-amd64-i386-pair blocked test-amd64-amd64-pv blocked test-amd64-i386-pv
Re: [Xen-devel] Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory
On Mon, Jan 04, 2016 at 02:06:32PM +0100, Marek Marczykowski-Górecki wrote: > On Tue, Dec 22, 2015 at 10:06:25AM -0500, Eric Shelton wrote: > > The XSA mentions that "PV frontend patches will be developed and > > released (publicly) after the embargo date." Has anything been done > > towards this that should also be incorporated into MiniOS? On a > > system utilizing a "driver domain," where a backend is running on a > > domain that is considered unprivileged and untrusted (such as the > > example described in http://wiki.xenproject.org/wiki/Driver_Domain), > > it seems XSA-155-style double fetch vulnerabilities in the frontends > > are also a potential security concern, and should be eliminated. > > However, perhaps that does not include pcifront, since pciback would > > always be running in dom0. > > And BTW the same applies to Linux frontends, for which also I haven't seen > any public development. In attachment my email to > xen-security-issues-discuss list (sent during embargo), with patches > attached there. I haven't got any response. Could you post it using git-send-email please? I took a quick glance at them but didn't get a chance to do an indepth look. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 20/62] arm/acpi: Add ACPI support for SMP initialization
On Mon, Jan 04, 2016 at 02:51:51PM +, Stefano Stabellini wrote: > On Wed, 30 Dec 2015, Shannon Zhao wrote: > > On 2015/11/30 22:57, Julien Grall wrote: > > > Hi Shannon, > > > > > > On 17/11/15 09:40, shannon.z...@linaro.org wrote: > > >> > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c > > >> > index d800cb6..dede0e1 100644 > > >> > --- a/xen/arch/arm/psci.c > > >> > +++ b/xen/arch/arm/psci.c > > >> > @@ -22,6 +22,7 @@ > > >> > #include > > >> > #include > > >> > #include > > >> > +#include > > >> > > > >> > /* > > >> > * While a 64-bit OS can make calls with SMC32 calling conventions, > > >> > for > > >> > @@ -86,6 +87,9 @@ int __init psci_init_0_1(void) > > >> > int ret; > > >> > const struct dt_device_node *psci; > > >> > > > >> > +if ( !acpi_disabled ) > > >> > +return -EINVAL; > > > Please explain in the commit message why PSCI 0.1 is not supported on > > > ACPI. > > > > Hi, > > > > I check this again. There are not limitations of supporting PSCI version > > in ACPI SPEC. It should support PSCI 0.1 as well. But look at the code > > of linux kernel, it says it only supports PSCI 0.2+. > > > > #define ACPI_FADT_PSCI_COMPLIANT(1) /* 00: [V5+] PSCI 0.2+ is > > implemented */ > > > > So does it need to be consistent with Linux or support PSCI 0.1 in Xen > > as well? > > I don't think it needs to be consistent with Linux. I would support PSCI > 0.1 too. That's not possible, so I don't follow. Prior to 0.2 the function IDs are not defined. The FADT has a single bit which describes PSCI 0.2+ being implemented, and does not describe function IDs. You must assume PSCI 0.2+ in order to have a set of function IDs to use. You should also assume the presence of the rest of the mandatory portions of PSCI 0.2, as these are also required per the combination of the PSCI spec and the ACPI spec. Mark. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4.4 1/2] libxl: Rerun bison and flex
On Mon, 2016-01-04 at 14:50 +, Ian Jackson wrote:
> We are going to want to cherry pick a change to the bison input, which
> will involve rerunning bison.
>
> So firstly, update the bison and flex output to that from current
> Debian wheezy (i386; 1:2.5.dfsg-2.1 and 2.5.35-10.1 respectively).
>
> There should be no functional change since there is no change to the
> source file, but we will inherit bugfixes and behavioural changes from
> the new version of bison. So this is more a matter of hope than
> knowledge.
This one isn't a cherry pick, but rather a manual rerun of the tools with a
cargo-culted commit message from another such occasion, right?
>
> Signed-off-by: Ian Jackson
> ---
> tools/libxl/libxlu_cfg_y.c | 538
>
> tools/libxl/libxlu_cfg_y.h | 14 +-
> 2 files changed, 304 insertions(+), 248 deletions(-)
>
> diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
> index 218933e..4437e05 100644
> --- a/tools/libxl/libxlu_cfg_y.c
> +++ b/tools/libxl/libxlu_cfg_y.c
> @@ -1,10 +1,8 @@
> +/* A Bison parser, made by GNU Bison 2.5. */
>
> -/* A Bison parser, made by GNU Bison 2.4.1. */
> -
> -/* Skeleton implementation for Bison's Yacc-like parsers in C
> +/* Bison implementation for Yacc-like parsers in C
>
> - Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004,
> 2005, 2006
> - Free Software Foundation, Inc.
> + Copyright (C) 1984, 1989-1990, 2000-2011 Free Software Foundation,
> Inc.
>
> 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
> @@ -46,7 +44,7 @@
> #define YYBISON 1
>
> /* Bison version. */
> -#define YYBISON_VERSION "2.4.1"
> +#define YYBISON_VERSION "2.5"
>
> /* Skeleton name. */
> #define YYSKELETON_NAME "yacc.c"
> @@ -75,7 +73,7 @@
>
> /* Copy the first part of user declarations. */
>
> -/* Line 189 of yacc.c */
> +/* Line 268 of yacc.c */
> #line 19 "libxlu_cfg_y.y"
>
> #define YYLEX_PARAM ctx->scanner
> @@ -83,8 +81,8 @@
> #include "libxlu_cfg_l.h"
>
>
> -/* Line 189 of yacc.c */
> -#line 88 "libxlu_cfg_y.c"
> +/* Line 268 of yacc.c */
> +#line 86 "libxlu_cfg_y.c"
>
> /* Enabling traces. */
> #ifndef YYDEBUG
> @@ -124,7 +122,7 @@
> typedef union YYSTYPE
> {
>
> -/* Line 214 of yacc.c */
> +/* Line 293 of yacc.c */
> #line 25 "libxlu_cfg_y.y"
>
> char *string;
> @@ -132,8 +130,8 @@ typedef union YYSTYPE
>
>
>
> -/* Line 214 of yacc.c */
> -#line 137 "libxlu_cfg_y.c"
> +/* Line 293 of yacc.c */
> +#line 135 "libxlu_cfg_y.c"
> } YYSTYPE;
> # define YYSTYPE_IS_TRIVIAL 1
> # define yystype YYSTYPE /* obsolescent; will be withdrawn */
> @@ -157,8 +155,8 @@ typedef struct YYLTYPE
> /* Copy the second part of user declarations. */
>
>
> -/* Line 264 of yacc.c */
> -#line 162 "libxlu_cfg_y.c"
> +/* Line 343 of yacc.c */
> +#line 160 "libxlu_cfg_y.c"
>
> #ifdef short
> # undef short
> @@ -208,7 +206,7 @@ typedef short int yytype_int16;
> #define YYSIZE_MAXIMUM ((YYSIZE_T) -1)
>
> #ifndef YY_
> -# if YYENABLE_NLS
> +# if defined YYENABLE_NLS && YYENABLE_NLS
> # if ENABLE_NLS
> # include /* INFRINGES ON USER NAME SPACE */
> # define YY_(msgid) dgettext ("bison-runtime", msgid)
> @@ -261,11 +259,11 @@ YYID (yyi)
> #define alloca _alloca
> # else
> #define YYSTACK_ALLOC alloca
> -#if ! defined _ALLOCA_H && ! defined _STDLIB_H && (defined __STDC__
> || defined __C99__FUNC__ \
> +#if ! defined _ALLOCA_H && ! defined EXIT_SUCCESS && (defined
> __STDC__ || defined __C99__FUNC__ \
> || defined __cplusplus || defined _MSC_VER)
> # include /* INFRINGES ON USER NAME SPACE */
> -# ifndef _STDLIB_H
> -# define _STDLIB_H 1
> +# ifndef EXIT_SUCCESS
> +# define EXIT_SUCCESS 0
> # endif
> #endif
> # endif
> @@ -288,24 +286,24 @@ YYID (yyi)
> # ifndef YYSTACK_ALLOC_MAXIMUM
> # define YYSTACK_ALLOC_MAXIMUM YYSIZE_MAXIMUM
> # endif
> -# if (defined __cplusplus && ! defined _STDLIB_H \
> +# if (defined __cplusplus && ! defined EXIT_SUCCESS \
> && ! ((defined YYMALLOC || defined malloc) \
> && (defined YYFREE || defined free)))
> # include /* INFRINGES ON USER NAME SPACE */
> -# ifndef _STDLIB_H
> -#define _STDLIB_H 1
> +# ifndef EXIT_SUCCESS
> +#define EXIT_SUCCESS 0
> # endif
> # endif
> # ifndef YYMALLOC
> # define YYMALLOC malloc
> -# if ! defined malloc && ! defined _STDLIB_H && (defined __STDC__ ||
> defined __C99__FUNC__ \
> +# if ! defined malloc && ! defined EXIT_SUCCESS && (defined __STDC__
> || defined __C99__FUNC__ \
> || defined __cplusplus || defined _MSC_VER)
> void *malloc (YYSIZE_T); /* INFRINGES ON USER NAME SPACE */
> # endif
> # endif
> # ifndef YYFREE
> # define YYFREE free
> -# if ! defined free && ! defined _STDLIB_H && (defined __STDC__ ||
> defined __C99__FUNC__ \
> +
[Xen-devel] [PATCH v2 0/3] tools: remove 1024 domain limit at some places
There are some places in Xen tools which will work for only up to 1024 domains. Remove this limit. Changes in V2: - corrected a little error in patch 1 at end of loop (index -1 used in array) - added patches 2 and 3 Juergen Gross (3): libxl: remove the xl list limit of 1024 domains libxl: base libxl_list_vm() on libxl_list_domain() xenstat: handle more than 1024 domains tools/libxl/libxl.c| 46 ++-- tools/xenstat/libxenstat/src/xenstat_qmp.c | 67 +- 2 files changed, 51 insertions(+), 62 deletions(-) -- 2.6.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/3] libxl: remove the xl list limit of 1024 domains
xl list is currently limited to 1024 domains. Remove the limit.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9207621..86b08d9 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -649,31 +649,30 @@ static void xcinfo2xlinfo(libxl_ctx *ctx,
libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain_out)
{
-libxl_dominfo *ptr;
+libxl_dominfo *ptr = NULL;
int i, ret;
xc_domaininfo_t info[1024];
-int size = 1024;
+int size = 0;
+uint32_t domid = 0;
GC_INIT(ctx);
-ptr = calloc(size, sizeof(libxl_dominfo));
-if (!ptr) {
-LOGE(ERROR, "allocating domain info");
-GC_FREE;
-return NULL;
+while ((ret = xc_domain_getinfolist(ctx->xch, domid, 1024, info)) > 0) {
+ptr = libxl__realloc(NOGC, ptr, (size + ret) * sizeof(libxl_dominfo));
+for (i = 0; i < ret; i++) {
+xcinfo2xlinfo(ctx, &info[i], &ptr[size + i]);
+}
+domid = info[ret - 1].domain + 1;
+size += ret;
}
-ret = xc_domain_getinfolist(ctx->xch, 0, 1024, info);
-if (ret<0) {
+if (ret < 0) {
LOGE(ERROR, "getting domain info list");
free(ptr);
GC_FREE;
return NULL;
}
-for (i = 0; i < ret; i++) {
-xcinfo2xlinfo(ctx, &info[i], &ptr[i]);
-}
-*nb_domain_out = ret;
+*nb_domain_out = size;
GC_FREE;
return ptr;
}
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.4-testing test] 66583: regressions - FAIL
On Mon, 2016-01-04 at 14:54 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-4.4-testing test] 66583:
> regressions - FAIL"):
> > I think we want to backport:
> >
> > commit 345e44a85d71a1a910385f33c7f1ba3683026d18
> > Author: Dario Faggioli
> > Date: Fri Jun 20 16:09:00 2014 +0200
>
> This is already in stable-4.4, as 5e39eb05, and has been since June.
This failure is in build-*-prev, i.e. the backport needs to be to 4.3 (and
presumably earlier). Sorry for not making that clear.
But it is already there as c591613f8c62, also from June.
So now I am rather perplexed by the build failures, which look identical to
the ones in the commit message, modulo some line number skew.
http://logs.test-lab.xenproject.org/osstest/logs/66583/build-amd64-prev/5.ts-xen-build.log
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 06/32] s390: reuse asm-generic/barrier.h
On Mon, 4 Jan 2016 14:20:42 +0100
Peter Zijlstra wrote:
> On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote:
> > On s390 read_barrier_depends, smp_read_barrier_depends
> > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the
> > asm-generic variants exactly. Drop the local definitions and pull in
> > asm-generic/barrier.h instead.
> >
> > This is in preparation to refactoring this code area.
> >
> > Signed-off-by: Michael S. Tsirkin
> > Acked-by: Arnd Bergmann
> > ---
> > arch/s390/include/asm/barrier.h | 10 ++
> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/s390/include/asm/barrier.h
> > b/arch/s390/include/asm/barrier.h
> > index 7ffd0b1..c358c31 100644
> > --- a/arch/s390/include/asm/barrier.h
> > +++ b/arch/s390/include/asm/barrier.h
> > @@ -30,14 +30,6 @@
> > #define smp_rmb() rmb()
> > #define smp_wmb() wmb()
> >
> > -#define read_barrier_depends() do { } while (0)
> > -#define smp_read_barrier_depends() do { } while (0)
> > -
> > -#define smp_mb__before_atomic()smp_mb()
> > -#define smp_mb__after_atomic() smp_mb()
>
> As per:
>
> lkml.kernel.org/r/20150921112252.3c2937e1@mschwide
>
> s390 should change this to barrier() instead of smp_mb() and hence
> should not use the generic versions.
Yes, we wanted to simplify this. Thanks for the reminder, I'll queue
a patch.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 20/62] arm/acpi: Add ACPI support for SMP initialization
On Wed, Dec 30, 2015 at 11:11:08AM +0800, Shannon Zhao wrote: > > > On 2015/11/30 22:57, Julien Grall wrote: > > Hi Shannon, > > > > On 17/11/15 09:40, shannon.z...@linaro.org wrote: > >> > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c > >> > index d800cb6..dede0e1 100644 > >> > --- a/xen/arch/arm/psci.c > >> > +++ b/xen/arch/arm/psci.c > >> > @@ -22,6 +22,7 @@ > >> > #include > >> > #include > >> > #include > >> > +#include > >> > > >> > /* > >> > * While a 64-bit OS can make calls with SMC32 calling conventions, for > >> > @@ -86,6 +87,9 @@ int __init psci_init_0_1(void) > >> > int ret; > >> > const struct dt_device_node *psci; > >> > > >> > +if ( !acpi_disabled ) > >> > +return -EINVAL; > > Please explain in the commit message why PSCI 0.1 is not supported on ACPI. > > Hi, > > I check this again. There are not limitations of supporting PSCI version > in ACPI SPEC. It should support PSCI 0.1 as well. I believe that's an oversight in the ACPI documentation, which should state 0.2+. There was a deliberate decision that the FADT PSCI flag implied PSCI 0.2+, since prior to PSCI 0.2 function IDs were not well-defined, and functions crticial for some uses cases did not exist (e.g. AFFINITY_INFO for kexec-type things). I don't know why that did not make it into the documentation. Charles, thoughts? Mark. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 20/62] arm/acpi: Add ACPI support for SMP initialization
On Mon, Jan 04, 2016 at 03:00:45PM +, Mark Rutland wrote: > On Mon, Jan 04, 2016 at 02:51:51PM +, Stefano Stabellini wrote: > > On Wed, 30 Dec 2015, Shannon Zhao wrote: > > > I check this again. There are not limitations of supporting PSCI version > > > in ACPI SPEC. It should support PSCI 0.1 as well. But look at the code > > > of linux kernel, it says it only supports PSCI 0.2+. > > > > > > #define ACPI_FADT_PSCI_COMPLIANT(1) /* 00: [V5+] PSCI 0.2+ is > > > implemented */ > > > > > > So does it need to be consistent with Linux or support PSCI 0.1 in Xen > > > as well? > > > > I don't think it needs to be consistent with Linux. I would support PSCI > > 0.1 too. > > That's not possible, so I don't follow. Prior to 0.2 the function IDs > are not defined. > > The FADT has a single bit which describes PSCI 0.2+ being implemented, > and does not describe function IDs. I've now spotted that this wording is indeed missing from the ACPI documentation. I believe this is a documentation bug, as the intent was always for the bit to imply PSCI 0.2+. Mark. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
