Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules
>>> On 07.12.15 at 22:27, wrote: > On 12/3/15 2:57 AM, Jan Beulich wrote: > On 03.12.15 at 01:34, wrote: >>> On 12/1/15 5:22 AM, Jan Beulich wrote: >>> On 30.11.15 at 18:53, wrote: > On 11/30/15 8:36 AM, Jan Beulich wrote: > On 24.11.15 at 18:51, wrote: >>> +config ARCH_DEFCONFIG >>> + string >>> + default "arch/x86/configs/x86_64_defconfig" >> >> x86_defconfig perhaps? > > No. I was told to drop support for x86 entirely in an earlier review. > Its not possible to configure for 32-bit x86 in v6. x86 != 32-bit. I think you're mixing this up with ix86 or x86-32. Here I consider x86 as to basic architecture without any particular bit width in mind. >>> >>> ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so >>> the original is correct. There is no defconfig for the ambiguous x86 >>> family. You're either building for x86_64 or x86_32 (which I referred to >>> as x86 in my original response). >>> >>> This defconfig is for the 64-bit architecture of x86 (x86_64) and there >>> for its named correctly. >> >> But there is no x86_32 architecture form the hypervisor build's >> point of view, and hence x86 isn't ambiguous. In fact the mid-term >> plan is to remove leftovers of references to x86_64 (like the >> arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where >> possible. The only place they need to be kept are in the public >> interface. > > That's fine but you don't build things for "x86". You build them for > "x86_64". XEN_TARGET_ARCH takes in "x86_64". The XEN_TARGET_ARCH value is of no interest here. The only fact that I care about is that there's only one x86 configuration, and hence I can't see why it shouldn't be named x86_defconfig. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 65141: regressions - FAIL
>>> On 08.12.15 at 03:46, wrote: > I didn't see an obvious error from the commit, so some debug > would be required to identify the problematic code. However this > issue was not reproduced immediately in our internal environment, > and the guy familiar with this area (Yang) just left Intel. It takes > some time to identify a new developer and get him ramped up to > fix issues in this area. Given that fact, I'd suggest to revert related > code now (as you discussed not the whole commit). In parallel > we'll find someone to look at original commit as a rampup task. Thanks Kevin! Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] help for function xc_map_foreign_bulk() and munmap()
Hi,alls, In xen-4.4.1/tools/libxc/xc_domain_save.c/xc_domain_save(),there are two function calls: region_base = xc_map_foreign_bulk(xch, dom, PROT_READ, pfn_type, pfn_err, batch); munmap(region_base, batch*PAGE_SIZE); I know the function wruncached(io_fd, live,(char*)region_base+(PAGE_SIZE*(j-run)), PAGE_SIZE*run) is writing the memory data to a file, the region_base is the base address.But the region_base is always same,so how it achieved to write the different memory data?maybe the function munmap() is useful. so,could any body tell me what did the function xc_map_foreign_bulk() and munmap() do concretely? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 65519: regressions - FAIL
flight 65519 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/65519/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 65468 build-i386-xsm5 xen-build fail REGR. vs. 65468 build-amd64-xsm 5 xen-build fail REGR. vs. 65468 build-amd64 5 xen-build fail REGR. vs. 65468 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf fb48e7780e1e0e0a7702ed8772e68150a9f8d10e baseline version: ovmf 84c7452165816ed26cd5bdeb5666d4dc0026f116 Last test of basis65468 2015-12-07 08:14:46 Z0 days Failing since 65485 2015-12-07 18:14:23 Z0 days6 attempts Testing same since65489 2015-12-07 22:43:16 Z0 days5 attempts People who touched revisions under test: Ard Biesheuvel Heyi Guo Yonghong Zhu jobs: build-amd64-xsm fail build-i386-xsm fail 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-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 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 fb48e7780e1e0e0a7702ed8772e68150a9f8d10e Author: Heyi Guo Date: Mon Dec 7 16:51:35 2015 + ArmPkg/BdsLib: Send RemainingDevicePath to PXE Load File protocol Load File protocol requires remaining device path rather than whole device path. For PXE, it actually requires end node device path only, or else invalid parameter will be returned directly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo Reviewed-by: Leif Lindholm git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19148 6f19259b-4bc3-4df7-8a09-765794883524 commit 76a5e6c269a2ce559c8b2d93d77c6672591327a5 Author: Ard Biesheuvel Date: Mon Dec 7 09:22:21 2015 + CryptoPkg/OpensslLib: comment out unused code This comments out the pqueue and ts_* source files from the OpensslLib build, since they have no users. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19147 6f19259b-4bc3-4df7-8a09-765794883524 commit e01f529efccd8c85bbb4f2d7d66470c3a281e57d Author: Ard Biesheuvel Date: Mon Dec 7 09:20:20 2015 + CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC Make mVirtualAddressChangeEvent STATIC to prevent it from conflicting with other variables of the same name that may be defined in other libraries (e.g., MdeModulePkg/Universal/Variable/RuntimeDxe) This also removes the risk of mVirtualAddressChangeEvent being merged with other uninitialized variables with external linkage by toolchains that perform COMMON allocation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19146 6f19259b-4bc3-4df7-8a09-765794883524 commit 8fb0d2e3fd488a045899dc2b890fc57b8d793e0b Author: Ard Biesheuvel Date: Mon Dec 7 09:20:09 2015 + CryptoPkg ARM: add ArmSoftFloatLib resolution to CryptoPkg.dsc In order to build the ARM version of CryptoPkg from its own .DSC file, it n
Re: [Xen-devel] [libvirt] [FOR 1.3.0 PATCH] conf: add net device prefix for Xen
On 12/07/2015 11:52 AM, Daniel P. Berrange wrote: > On Mon, Dec 07, 2015 at 09:42:21AM -0700, Jim Fehlig wrote: >> In commit d2e5538b1, the libxl driver was changed to copy interface >> names autogenerated by libxl to the corresponding network def in the >> domain's virDomainDef object. The copied name is freed when the domain >> transitions to the shutoff state. But when migrating a domain, the >> autogenerated name is included in the XML sent to the destination host. >> It is possible an interface with the same name already exists on the >> destination host, causing migration to fail. Indeed the Xen project's >> OSSTEST CI already encountered such a failure. >> >> This patch defines another VIR_NET_GENERATED_PREFIX for Xen, allowing >> the autogenerated names to be excluded when parsing and formatting >> inactive config. >> >> Signed-off-by: Jim Fehlig >> --- >> >> This is an alternative approach to Joao's fix for this regression >> >> https://www.redhat.com/archives/libvir-list/2015-December/msg00197.html >> >> I think it is the same approach used by the qemu driver. My only >> reservation is that it expands the potential for clashes with >> user-defined names. I.e. with this change both 'vnet' and 'vif' are >> reserved prefixes. > Hmm, yes, tricky one. > > If we only care about XML parsing, then you could register a post > parse callback instead to do this. AFAIK, XML parsing is all that's in play here. > I'm not clear why we also have it in the virDomainNetDefFormat > method - and we can't solve that with a post-parse callback. > > > The other option would be to make the reserved prefix be a > capability that the parser/formatter could read. This seems like the best option, since a post-parse callback doesn't solve the problem in virDomainNetDefFormat. It also has the upshot of making the prefix visible and known to users. But I doubt such a change is suitable during 1.3.0 freeze. With the freeze in mind, seems the best solution to the libxl migration regression is revert d2e5538b1. It can be added again post-1.3.0 release, after adding the prefix to capabilities. DV, since you may be making the release soon, feel free to revert d2e5538b1 if you agree. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RESEND][PATCH V9 3/7] libxl: add pvusb API
Any comments?
>>> On 11/25/2015 at 05:46 PM, in message
<1448444775-6974-4-git-send-email-cy...@suse.com>, Chunyan Liu
wrote:
> Add pvusb APIs, including:
> - attach/detach (create/destroy) virtual usb controller.
> - attach/detach usb device
> - list usb controller and usb devices
> - some other helper functions
>
> Signed-off-by: Chunyan Liu
> Signed-off-by: Simon Cao
>
> ---
> changes:
> - update naming, all places indicating usb controller named
> as usbctrl, all places indicating usb device named as usbdev
> - update DEFINE_DEVICE_REMOVE instead of creating a new
> DEFINE_DEVICE_REMOVE_EXT
> - use libxl__xs_read_checked instead of libxl__xs_read
> - update local READ_SUBPATH(_INT) macros to include more common codes
> - save drvpath before unbind
> - get_assigned_devices: call libxl__device_usbdev_list_for_ctrl
> instead of doing all things from scratch
> - usb_interface_xenstore_encode: use special char to avoid confusion
> - usb readdir_r instead of readdir
> - check syscall errno
> - remove usbinfo definition
> - address other comments except:
> libxl__device_usbdev_add/remove and do_usbdev_add/remove, in previous
> discussion, we'd like to get usbctrlinfo once and pass usbctrlinfo to
> do_usbdev_add/remove. However, during update, adding usbdev process
> still needs to try twice to get usbctrlinfo. (Before set_default,
> if usbctrl doesn't exist it doesn't doing getting usbctrlinfo actually;
> after set_default, needs to get usbctrlinfo then). So, finally, just
> change codes to make adding/removing process symmetrical.
>
> tools/libxl/Makefile |2 +-
> tools/libxl/libxl.c | 50 +-
> tools/libxl/libxl.h | 77 ++
> tools/libxl/libxl_device.c |5 +-
> tools/libxl/libxl_internal.h | 18 +
> tools/libxl/libxl_osdeps.h | 13 +
> tools/libxl/libxl_pvusb.c| 1534
> ++
> tools/libxl/libxl_types.idl | 46 +
> tools/libxl/libxl_types_internal.idl |1 +
> tools/libxl/libxl_utils.c| 18 +
> tools/libxl/libxl_utils.h|5 +
> 11 files changed, 1766 insertions(+), 3 deletions(-)
> create mode 100644 tools/libxl/libxl_pvusb.c
>
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 6ff5bee..a36145a 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -103,7 +103,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o
> libxl_dm.o libxl_pci.o \
> libxl_stream_read.o libxl_stream_write.o \
> libxl_save_callout.o _libxl_save_msgs_callout.o \
> libxl_qmp.o libxl_event.o libxl_fork.o \
> - libxl_dom_suspend.o $(LIBXL_OBJS-y)
> + libxl_dom_suspend.o libxl_pvusb.o $(LIBXL_OBJS-y)
> LIBXL_OBJS += libxl_genid.o
> LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index eaa7d75..a479465 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4144,6 +4144,36 @@ out:
> return rc;
> }
>
> +static void libxl__initiate_device_disk_remove(libxl__egc *egc,
> + libxl__ao_device *aodev)
> +{
> +return libxl__initiate_device_remove(egc, aodev);
> +}
> +
> +static void libxl__initiate_device_nic_remove(libxl__egc *egc,
> + libxl__ao_device *aodev)
> +{
> +return libxl__initiate_device_remove(egc, aodev);
> +}
> +
> +static void libxl__initiate_device_vtpm_remove(libxl__egc *egc,
> + libxl__ao_device *aodev)
> +{
> +return libxl__initiate_device_remove(egc, aodev);
> +}
> +
> +static void libxl__initiate_device_vkb_remove(libxl__egc *egc,
> + libxl__ao_device *aodev)
> +{
> +return libxl__initiate_device_remove(egc, aodev);
> +}
> +
> +static void libxl__initiate_device_vfb_remove(libxl__egc *egc,
> + libxl__ao_device *aodev)
> +{
> +return libxl__initiate_device_remove(egc, aodev);
> +}
> +
>
> /
> **/
>
> /* Macro for defining device remove/destroy functions in a compact way */
> @@ -4158,6 +4188,8 @@ out:
> * libxl_device_vkb_destroy
> * libxl_device_vfb_remove
> * libxl_device_vfb_destroy
> + * libxl_device_usbctrl_remove
> + * libxl_device_usbctrl_destroy
> */
> #define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\
> int libxl_device_##type##_##removedestroy(libxl_ctx *ctx, \
> @@ -4179,7 +4211,7 @@ out:
> aodev->dev = device;
[Xen-devel] [ovmf bisection] complete build-i386
branch xen-unstable xenbranch xen-unstable job build-i386 testid xen-build Tree: ovmf https://github.com/tianocore/edk2.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: ovmf https://github.com/tianocore/edk2.git Bug introduced: 48aed71c6572db9204bfa8af090039d5f24f5bea Bug not present: 4aa9826def3bf9d817e7d245d46886a31de92c15 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/65520/ commit 48aed71c6572db9204bfa8af090039d5f24f5bea Author: Yonghong Zhu Date: Mon Dec 7 09:09:31 2015 + BaseTools: process the files by the priority in BUILDRULEORDER By the BUILDRULEORDER feature to process files listed in INF [Sources] sections in priority order, if a filename is listed with multiple extensions, the tools will use only the file that matches the first extension in the space separated list. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu Reviewed-by: Liming Gao git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19143 6f19259b-4bc3-4df7-8a09-765794883524 For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/build-i386.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/ovmf/build-i386.xen-build --summary-out=tmp/65520.bisection-summary --basis-template=65468 --blessings=real,real-bisect ovmf build-i386 xen-build Searching for failure / basis pass: 65509 fail [host=baroque1] / 65468 [host=italia1] 65386 [host=italia0] 65359 [host=italia0] 65336 [host=pinot0] 65319 [host=chardonnay0] 65293 [host=huxelrebe1] 65278 [host=pinot1] 65258 [host=huxelrebe1] 65244 [host=huxelrebe1] 65181 ok. Failure / basis pass flights: 65509 / 65181 (tree with no url: seabios) (tree in basispass but not in latest: qemu) Tree: ovmf https://github.com/tianocore/edk2.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest fb48e7780e1e0e0a7702ed8772e68150a9f8d10e f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 Basis pass ec613395d114ed6f7c13249a199d1e9cc0025326 3fb401edbd8e9741c611bfddf6a2032ca91f55ed 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 Generating revisions with ./adhoc-revtuple-generator https://github.com/tianocore/edk2.git#ec613395d114ed6f7c13249a199d1e9cc0025326-fb48e7780e1e0e0a7702ed8772e68150a9f8d10e git://xenbits.xen.org/qemu-xen.git#3fb401edbd8e9741c611bfddf6a2032ca91f55ed-f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 git://xenbits.xen.org/xen.git#713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1-713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 Loaded 2008 nodes in revision graph Searching for test results: 65181 pass ec613395d114ed6f7c13249a199d1e9cc0025326 3fb401edbd8e9741c611bfddf6a2032ca91f55ed 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65258 [host=huxelrebe1] 65244 [host=huxelrebe1] 65278 [host=pinot1] 65293 [host=huxelrebe1] 65319 [host=chardonnay0] 65336 [host=pinot0] 65359 [host=italia0] 65485 fail 76a5e6c269a2ce559c8b2d93d77c6672591327a5 f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65386 [host=italia0] 65468 [host=italia1] 65487 pass ec613395d114ed6f7c13249a199d1e9cc0025326 3fb401edbd8e9741c611bfddf6a2032ca91f55ed 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65489 fail fb48e7780e1e0e0a7702ed8772e68150a9f8d10e f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65509 fail fb48e7780e1e0e0a7702ed8772e68150a9f8d10e f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65491 fail 76a5e6c269a2ce559c8b2d93d77c6672591327a5 f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65520 fail 48aed71c6572db9204bfa8af090039d5f24f5bea f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65492 pass c972495ed0a939ed30f5ab5fa14f215b8bbe5ed1 44fa27a729e488df221915686bdbdd6fd45536db 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65494 pass ec613395d114ed6f7c13249a199d1e9cc0025326 3fb401edbd8e9741c611bfddf6a2032ca91f55ed 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65497 fail fb48e7780e1e0e0a7702ed8772e68150a9f8d10e f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65499 pass 2e728930aa6aaeff230bb60f36c8e39632399bcc f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65493 fail fb48e7780e1e0e0a7702ed8772e68150a9f8d10e f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65505 pass 79e7b6472797f156d1ff28f3022b25d9c6f250f9 f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 65506 fail fb48e7780e1e0e0a7702ed8772e681
[Xen-devel] [ovmf test] 65509: regressions - FAIL
flight 65509 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/65509/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 65468 build-i386-xsm5 xen-build fail REGR. vs. 65468 build-amd64-xsm 5 xen-build fail REGR. vs. 65468 build-amd64 5 xen-build fail REGR. vs. 65468 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf fb48e7780e1e0e0a7702ed8772e68150a9f8d10e baseline version: ovmf 84c7452165816ed26cd5bdeb5666d4dc0026f116 Last test of basis65468 2015-12-07 08:14:46 Z0 days Failing since 65485 2015-12-07 18:14:23 Z0 days5 attempts Testing same since65489 2015-12-07 22:43:16 Z0 days4 attempts People who touched revisions under test: Ard Biesheuvel Heyi Guo Yonghong Zhu jobs: build-amd64-xsm fail build-i386-xsm fail 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-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 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 fb48e7780e1e0e0a7702ed8772e68150a9f8d10e Author: Heyi Guo Date: Mon Dec 7 16:51:35 2015 + ArmPkg/BdsLib: Send RemainingDevicePath to PXE Load File protocol Load File protocol requires remaining device path rather than whole device path. For PXE, it actually requires end node device path only, or else invalid parameter will be returned directly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo Reviewed-by: Leif Lindholm git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19148 6f19259b-4bc3-4df7-8a09-765794883524 commit 76a5e6c269a2ce559c8b2d93d77c6672591327a5 Author: Ard Biesheuvel Date: Mon Dec 7 09:22:21 2015 + CryptoPkg/OpensslLib: comment out unused code This comments out the pqueue and ts_* source files from the OpensslLib build, since they have no users. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19147 6f19259b-4bc3-4df7-8a09-765794883524 commit e01f529efccd8c85bbb4f2d7d66470c3a281e57d Author: Ard Biesheuvel Date: Mon Dec 7 09:20:20 2015 + CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC Make mVirtualAddressChangeEvent STATIC to prevent it from conflicting with other variables of the same name that may be defined in other libraries (e.g., MdeModulePkg/Universal/Variable/RuntimeDxe) This also removes the risk of mVirtualAddressChangeEvent being merged with other uninitialized variables with external linkage by toolchains that perform COMMON allocation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19146 6f19259b-4bc3-4df7-8a09-765794883524 commit 8fb0d2e3fd488a045899dc2b890fc57b8d793e0b Author: Ard Biesheuvel Date: Mon Dec 7 09:20:09 2015 + CryptoPkg ARM: add ArmSoftFloatLib resolution to CryptoPkg.dsc In order to build the ARM version of CryptoPkg from its own .DSC file, it n
Re: [Xen-devel] [xen-unstable test] 65141: regressions - FAIL
> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, December 08, 2015 12:18 AM > > >>> On 05.12.15 at 09:09, wrote: > > On Wed, 2015-12-02 at 13:51 +, Ian Campbell wrote: > > > >> http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65301/ > >> > >> I think that ought to give a baseline for the bisector to work with. I'll > >> prod it to do so. > > > > Results are below. TL;DR: d02e84b9d9d "vVMX: use latched VMCS machine > > address" is somehow at fault. > > > > It appears to be somewhat machine specific, the one this has been > > failing on is godello* which says "CPU0: Intel(R) Xeon(R) CPU E3-1220 > > v3 @ 3.10GHz stepping 03" in its serial log. > > > > Andy suggested this might be related to cpu_has_vmx_vmcs_shadowing > > so Haswell and newer vs IvyBridge and older. > > Yeah, but on irc it was also made clear that the regression is on a > system without that capability. > > At this point we certainly need to seriously consider reverting the > whole change. The reason I continue to be hesitant is that I'm > afraid this may result in no-one trying to find out what the problem > here is. While I could certainly try to, I'm sure I won't find time to > do so within the foreseeable future. And since we didn't get any > real feedback from Intel so far, I thought I'd ping them to at least > share some status before we decide. That pinging has happened > a few minutes ago. I'd therefore like to give it, say, another day, > and if by then we don't have an estimate for when a fix might > become available, I'd do the revert. Unless of course somebody > feels strongly about doing the revert immediately. > I didn't see an obvious error from the commit, so some debug would be required to identify the problematic code. However this issue was not reproduced immediately in our internal environment, and the guy familiar with this area (Yang) just left Intel. It takes some time to identify a new developer and get him ramped up to fix issues in this area. Given that fact, I'd suggest to revert related code now (as you discussed not the whole commit). In parallel we'll find someone to look at original commit as a rampup task. Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 65506: regressions - FAIL
flight 65506 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/65506/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 65468 build-i386-xsm5 xen-build fail REGR. vs. 65468 build-amd64-xsm 5 xen-build fail REGR. vs. 65468 build-amd64 5 xen-build fail REGR. vs. 65468 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf fb48e7780e1e0e0a7702ed8772e68150a9f8d10e baseline version: ovmf 84c7452165816ed26cd5bdeb5666d4dc0026f116 Last test of basis65468 2015-12-07 08:14:46 Z0 days Failing since 65485 2015-12-07 18:14:23 Z0 days4 attempts Testing same since65489 2015-12-07 22:43:16 Z0 days3 attempts People who touched revisions under test: Ard Biesheuvel Heyi Guo Yonghong Zhu jobs: build-amd64-xsm fail build-i386-xsm fail 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-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 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 fb48e7780e1e0e0a7702ed8772e68150a9f8d10e Author: Heyi Guo Date: Mon Dec 7 16:51:35 2015 + ArmPkg/BdsLib: Send RemainingDevicePath to PXE Load File protocol Load File protocol requires remaining device path rather than whole device path. For PXE, it actually requires end node device path only, or else invalid parameter will be returned directly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo Reviewed-by: Leif Lindholm git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19148 6f19259b-4bc3-4df7-8a09-765794883524 commit 76a5e6c269a2ce559c8b2d93d77c6672591327a5 Author: Ard Biesheuvel Date: Mon Dec 7 09:22:21 2015 + CryptoPkg/OpensslLib: comment out unused code This comments out the pqueue and ts_* source files from the OpensslLib build, since they have no users. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19147 6f19259b-4bc3-4df7-8a09-765794883524 commit e01f529efccd8c85bbb4f2d7d66470c3a281e57d Author: Ard Biesheuvel Date: Mon Dec 7 09:20:20 2015 + CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC Make mVirtualAddressChangeEvent STATIC to prevent it from conflicting with other variables of the same name that may be defined in other libraries (e.g., MdeModulePkg/Universal/Variable/RuntimeDxe) This also removes the risk of mVirtualAddressChangeEvent being merged with other uninitialized variables with external linkage by toolchains that perform COMMON allocation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19146 6f19259b-4bc3-4df7-8a09-765794883524 commit 8fb0d2e3fd488a045899dc2b890fc57b8d793e0b Author: Ard Biesheuvel Date: Mon Dec 7 09:20:09 2015 + CryptoPkg ARM: add ArmSoftFloatLib resolution to CryptoPkg.dsc In order to build the ARM version of CryptoPkg from its own .DSC file, it n
Re: [Xen-devel] [PATCH v2 00/14] Add VMX TSC scaling support
On 12/07/15 17:04, Andrew Cooper wrote: > On 07/12/15 10:16, Haozhong Zhang wrote: > > On 12/07/15 10:03, Egger, Christoph wrote: > >> Did you consider nested virtualization? > >> L1 hypervisor may have a different tsc scaling > >> and L2 guest again may have a different tsc scale ratio. > >> > > Oh, I forgot this. I'll check the nested TSC scaling code (mostly > > about nested SVM TSC ratio, because this patch series does not expose > > VMX TSC scaling to L1 guest). > > > > BTW, are there any practical usage scenarios of nested TSC scaling? If > > any, I may also need to consider adding nested virtualization support > > to VMX TSC scaling. > > I would say that there are genuine uses for nested TSC scaling. An L1 > hypervisor is going to want to scale for the same reasons as the L0 > hypervisor. > nice to know this. > Having said that, if TSC scaling is correctly hidden from the L1 guests, > I would advise against conflating the two issues together. i.e. getting > nested TSC scaling working is not a prerequisite for accepting this series. > agree, I prefer to posting other standalone patches to support nested VMX TSC scaling. Thanks, Haozhong ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 10/14] x86/hvm: Replace architecture TSC scaling by a common function
On 12/07/15 13:55, Boris Ostrovsky wrote:
> On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
> >This patch implements a common function hvm_scale_tsc() to scale TSC by
> >using TSC scaling information collected by architecture code.
> >
> >Signed-off-by: Haozhong Zhang
> >---
> > xen/arch/x86/hvm/hvm.c| 18 +--
> > xen/arch/x86/hvm/svm/svm.c| 12
> > xen/arch/x86/time.c | 2 +-
> > xen/include/asm-x86/hvm/hvm.h | 3 +-
> > xen/include/asm-x86/math64.h | 70
> > +++
> > 5 files changed, 88 insertions(+), 17 deletions(-)
> >
> >diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> >index 52a0ef8..1e3d89f 100644
> >--- a/xen/arch/x86/hvm/hvm.c
> >+++ b/xen/arch/x86/hvm/hvm.c
> >@@ -302,6 +302,20 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
> > return 1;
> > }
> >+u64 hvm_scale_tsc(const struct vcpu *v, u64 tsc)
> >+{
> >+u64 ratio = v->arch.hvm_vcpu.tsc_scaling_ratio;
> >+
> >+if ( !hvm_funcs.tsc_scaling_supported ||
> >+ ratio == hvm_funcs.default_tsc_scaling_ratio )
> >+return tsc;
> >+
> >+BUG_ON(hvm_funcs.tsc_scaling_ratio_frac_bits >= 64 ||
> >+ hvm_funcs.tsc_scaling_ratio_frac_bits == 0);
>
> Since these values never change, I am not sure it's worth testing this. And
> if you think it is then I'd do it somewhere in initialization code.
>
I'll remove this unnecessary check.
> >+
> >+return mul_u64_u64_shr(tsc, ratio,
> >hvm_funcs.tsc_scaling_ratio_frac_bits);
> >+}
> >+
>
>
>
> >diff --git a/xen/include/asm-x86/math64.h b/xen/include/asm-x86/math64.h
> >index 9af6aee..c6a472b 100644
> >--- a/xen/include/asm-x86/math64.h
> >+++ b/xen/include/asm-x86/math64.h
> >@@ -27,4 +27,74 @@ static inline u64 mul_u64_u32_div(u64 a, u32 mul, u32
> >divisor)
> > return rl.ll;
> > }
> >+/*
> >+ * Multiply two 64-bit unsigned integers a and b. The most and least
> >+ * significant 64 bits of the 128-bit result are returned through hi
> >+ * and lo respectively.
> >+ */
> >+static inline void mul64(u64 *lo, u64 *hi, u64 a, u64 b)
>
> Please move these routines (as well as one in previous patch into a
> standalone math patch (and provide attribution to wherever they came from).
>
I'll move them to a standalone patch and add comments for their source.
Thanks,
Haozhong
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 09/14] x86/hvm: Setup TSC scaling ratio
On 12/07/15 13:42, Boris Ostrovsky wrote:
> On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
> >This patch adds a field tsc_scaling_ratio in struct hvm_vcpu to
> >record the TSC scaling ratio, and sets it up when tsc_set_info() is
> >called for a vcpu or when a vcpu is restored or reset.
> >
> >Signed-off-by: Haozhong Zhang
>
> Reviewed-by: Boris Ostrovsky
>
> with a few nits below.
>
> >---
> > xen/arch/x86/hvm/hvm.c| 30 ++
> > xen/arch/x86/hvm/svm/svm.c| 6 --
> > xen/arch/x86/time.c | 13 -
> > xen/include/asm-x86/hvm/hvm.h | 5 +
> > xen/include/asm-x86/hvm/svm/svm.h | 3 ---
> > xen/include/asm-x86/hvm/vcpu.h| 2 ++
> > xen/include/asm-x86/math64.h | 30 ++
> > 7 files changed, 83 insertions(+), 6 deletions(-)
> > create mode 100644 xen/include/asm-x86/math64.h
> >
> >diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> >index 0e63c33..52a0ef8 100644
> >--- a/xen/arch/x86/hvm/hvm.c
> >+++ b/xen/arch/x86/hvm/hvm.c
> >@@ -65,6 +65,7 @@
> > #include
> > #include
> > #include
> >+#include
> > #include
> > #include
> > #include
> >@@ -301,6 +302,29 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
> > return 1;
> > }
> >+void hvm_setup_tsc_scaling(struct vcpu *v)
> >+{
> >+u64 ratio;
> >+
> >+if ( !hvm_funcs.tsc_scaling_supported )
> >+return;
> >+
> >+/*
> >+ * The multiplication of the first two terms may overflow a 64-bit
> >+ * integer, so use mul_u64_u32_div() instead to keep precision.
> >+ */
> >+ratio = mul_u64_u32_div(1ULL << hvm_funcs.tsc_scaling_ratio_frac_bits,
> >+v->domain->arch.tsc_khz, cpu_khz);
> >+
> >+if ( ratio == 0 || ratio > hvm_funcs.max_tsc_scaling_ratio )
> >+return;
> >+
> >+v->arch.hvm_vcpu.tsc_scaling_ratio = ratio;
> >+
> >+if ( hvm_funcs.setup_tsc_scaling )
> >+hvm_funcs.setup_tsc_scaling(v);
> >+}
> >+
> > void hvm_set_guest_tsc_fixed(struct vcpu *v, u64 guest_tsc, u64 at_tsc)
> > {
> > uint64_t tsc;
> >@@ -2024,6 +2048,9 @@ static int hvm_load_cpu_ctxt(struct domain *d,
> >hvm_domain_context_t *h)
> > if ( hvm_funcs.load_cpu_ctxt(v, &ctxt) < 0 )
> > return -EINVAL;
> >+if ( hvm_funcs.tsc_scaling_supported )
> >+hvm_setup_tsc_scaling(v);
> >+
>
>
> I think you can drop the test here (and below) since you do the same check
> inside hvm_setup_tsc_scaling()
>
Yes, the check here is redundant.
>
> > v->arch.hvm_vcpu.msr_tsc_aux = ctxt.msr_tsc_aux;
> > seg.limit = ctxt.idtr_limit;
> >@@ -5584,6 +5611,9 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs,
> >uint16_t ip)
> > hvm_set_segment_register(v, x86_seg_gdtr, ®);
> > hvm_set_segment_register(v, x86_seg_idtr, ®);
> >+if ( hvm_funcs.tsc_scaling_supported )
> >+hvm_setup_tsc_scaling(v);
> >+
> > /* Sync AP's TSC with BSP's. */
> > v->arch.hvm_vcpu.cache_tsc_offset =
> > v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
> >diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> >index 9f741d0..d291327 100644
> >--- a/xen/arch/x86/hvm/svm/svm.c
> >+++ b/xen/arch/x86/hvm/svm/svm.c
> >@@ -811,7 +811,7 @@ static uint64_t svm_scale_tsc(struct vcpu *v, uint64_t
> >tsc)
> > if ( !cpu_has_tsc_ratio || d->arch.vtsc )
> > return tsc;
> >-return scale_tsc(tsc, vcpu_tsc_ratio(v));
> >+return scale_tsc(tsc, v->arch.hvm_vcpu.tsc_scaling_ratio);
> > }
> > static uint64_t svm_get_tsc_offset(uint64_t host_tsc, uint64_t guest_tsc,
> >@@ -987,7 +987,7 @@ static inline void svm_tsc_ratio_save(struct vcpu *v)
> > static inline void svm_tsc_ratio_load(struct vcpu *v)
> > {
> > if ( cpu_has_tsc_ratio && !v->domain->arch.vtsc )
> >-wrmsrl(MSR_AMD64_TSC_RATIO, vcpu_tsc_ratio(v));
> >+wrmsrl(MSR_AMD64_TSC_RATIO, v->arch.hvm_vcpu.tsc_scaling_ratio);
> > }
> > static void svm_ctxt_switch_from(struct vcpu *v)
> >@@ -1193,6 +1193,8 @@ static int svm_vcpu_initialise(struct vcpu *v)
> > svm_guest_osvw_init(v);
> >+v->arch.hvm_vcpu.tsc_scaling_ratio = DEFAULT_TSC_RATIO;
> >+
> > return 0;
> > }
> >diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> >index 732d1e9..d4a94eb 100644
> >--- a/xen/arch/x86/time.c
> >+++ b/xen/arch/x86/time.c
> >@@ -1902,8 +1902,19 @@ void tsc_set_info(struct domain *d,
> > if ( has_hvm_container_domain(d) )
> > {
> > hvm_set_rdtsc_exiting(d, d->arch.vtsc);
> >-if ( d->vcpu && d->vcpu[0] && incarnation == 0 )
> >+if ( d->vcpu && d->vcpu[0] )
> > {
> >+ /*
> >+ * TSC scaling ratio on BSP is set here during initial boot,
> >while
>
> During domain creation rather then during boot.
>
Yes, will change.
> >+ * the same TSC scaling ratio on APs will be set in
> >+ * hvm_vcpu_reset_state().
> >+ */
> >
Re: [Xen-devel] [PATCH v2 07/14] svm: Remove redundant TSC scaling in svm_set_tsc_offset()
On 12/07/15 13:25, Boris Ostrovsky wrote:
> On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
> >Now every caller passes an already scaled offset to
> >svm_set_tsc_offset(), so it's not necessary to recalculate a scaled TSC
> >offset in svm_set_tsc_offset().
> >
> >Signed-off-by: Haozhong Zhang
> >---
> > xen/arch/x86/hvm/svm/svm.c | 15 ++-
> > 1 file changed, 2 insertions(+), 13 deletions(-)
> >
> >diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> >index 9d5f2c3..3d22dfa 100644
> >--- a/xen/arch/x86/hvm/svm/svm.c
> >+++ b/xen/arch/x86/hvm/svm/svm.c
> >@@ -826,19 +826,7 @@ static void svm_set_tsc_offset(struct vcpu *v, u64
> >offset, u64 at_tsc)
> > struct vmcb_struct *n1vmcb, *n2vmcb;
> > uint64_t n2_tsc_offset = 0;
> > struct domain *d = v->domain;
> >-uint64_t host_tsc, guest_tsc;
> >-
> >-guest_tsc = hvm_get_guest_tsc_fixed(v, at_tsc);
> >-
> >-/* Re-adjust the offset value when TSC_RATIO is available */
> >-if ( cpu_has_tsc_ratio && !d->arch.vtsc )
> >-{
> >-if ( at_tsc )
> >-host_tsc = at_tsc;
> >-else
> >-host_tsc = rdtsc();
> >-offset = svm_get_tsc_offset(host_tsc, guest_tsc, vcpu_tsc_ratio(v));
> >-}
> >+uint64_t guest_tsc;
>
> You could declare it at the first use site below.
>
will move to the first use site.
Haozhong
> Other than that,
>
> Reviewed-by: Boris Ostrovsky
>
> > if ( !nestedhvm_enabled(d) ) {
> > vmcb_set_tsc_offset(vmcb, offset);
> >@@ -854,6 +842,7 @@ static void svm_set_tsc_offset(struct vcpu *v, u64
> >offset, u64 at_tsc)
> > n2_tsc_offset = vmcb_get_tsc_offset(n2vmcb) -
> > vmcb_get_tsc_offset(n1vmcb);
> > if ( svm->ns_tscratio != DEFAULT_TSC_RATIO ) {
> >+guest_tsc = hvm_get_guest_tsc_fixed(v, at_tsc);
> > n2_tsc_offset = svm_get_tsc_offset(guest_tsc,
> > guest_tsc + n2_tsc_offset, svm->ns_tscratio);
> > }
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 06/14] x86/time.c: Scale host TSC in pvclock properly
On 12/07/15 13:14, Boris Ostrovsky wrote:
> On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
> >This patch makes the pvclock return the scaled host TSC and
> >corresponding scaling parameters to HVM domains if guest TSC is not
> >emulated and TSC scaling is enabled.
> >
> >Signed-off-by: Haozhong Zhang
>
> +Joao who has been staring at this code.
>
> Joao, can you run this series through your test with non-native frequency?
> (http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg00683.html
> provides an interface to set it in config file).
>
>
> >---
> > xen/arch/x86/time.c | 16
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> >diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> >index 95df4f1..732d1e9 100644
> >--- a/xen/arch/x86/time.c
> >+++ b/xen/arch/x86/time.c
> >@@ -815,10 +815,18 @@ static void __update_vcpu_system_time(struct vcpu *v,
> >int force)
> > }
> > else
> > {
> >-tsc_stamp = t->local_tsc_stamp;
> >-
> >-_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
> >-_u.tsc_shift = (s8)t->tsc_scale.shift;
> >+if ( is_hvm_domain(d) && cpu_has_tsc_ratio )
> >+{
> >+tsc_stamp= hvm_funcs.scale_tsc(v,
> >t->local_tsc_stamp);
> >+_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
> >+_u.tsc_shift = d->arch.vtsc_to_ns.shift;
>
> I am not sure this is correct (which is why I asked Joao to look at this and
> test). The scaler below is calculated as result of TSC calibration across
> physical CPUs and what you use above (vtsc_to_ns) is an uncalibrated value.
>
Because guest TSC is synchronized among all vcpus of a domain, I think
it's safe to use d->arch.vtsc_to_ns here.
Haozhong
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] blkback feature announcement
On 12/07/2015 08:42 PM, Roger Pau Monné wrote: > El 07/12/15 a les 13.00, Jan Beulich ha escrit: >> Hello, >> >> is there a particular reason why "max-ring-page-order" gets written in >> xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and >> "feature-persistent" get written only in connect(), despite both having >> constant values (and hence the node value effectively being known as >> soon as the device exists)? > > No, AFAIK there's no specific reason. > AFAIR, that's for the blkfront resume path. We need to get the "max-ring-page-order" in blkfront_resume() in advance, so that we can know how many ring pages to be used before setup_blkring(). Bob. >> Or in more general terms: Shouldn't it be well defined at what time >> a frontend can rely on certain nodes to be available for inspection? >> And in doing so, I'd expect the determination to be done such that >> widest flexibility is provided towards the actual implementation, i.e. >> nodes should be written as early as possible. (Of course this applies >> to other frontend/backend pairs too.) > > I agree. Regarding blkback the nodes about persistent grants, indirect > descriptors and the ring page order should be written in > xen_blkbk_probe, while the specific information about this virtual disk > (sectors, sector size...) should be written before switching to the > connected state (ie: after hotplug scripts have run). > > Roger. > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/14] x86/time.c: Use correct guest TSC frequency in tsc_get_info()
On 12/07/15 12:53, Boris Ostrovsky wrote:
> On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
> >When the TSC mode of a HVM container is TSC_MODE_DEFAULT or
> >TSC_MODE_PVRDTSCP and no TSC emulation is used, the existing
> >tsc_get_info() uses the host TSC frequency (cpu_khz) as the guest TSC
> >frequency. However, tsc_set_info() may set the guest TSC frequency to a
> >value different than the host. In order to keep consistent to
> >tsc_set_info(), this patch makes tsc_get_info() use the value set by
> >tsc_set_info() as the guest TSC frequency.
> >
> >Signed-off-by: Haozhong Zhang
> >---
> > xen/arch/x86/time.c | 12 +---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> >diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> >index 1091e69..95df4f1 100644
> >--- a/xen/arch/x86/time.c
> >+++ b/xen/arch/x86/time.c
> >@@ -1749,6 +1749,9 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
> >uint64_t *elapsed_nsec, uint32_t *gtsc_khz,
> >uint32_t *incarnation)
> > {
> >+bool_t enable_tsc_scaling = has_hvm_container_domain(d) &&
> >+cpu_has_tsc_ratio;
>
> && !d->arch.vtsc ?
>
> (assuming my comment to the previous patch is correct).
>
enable_tsc_scaling in tsc_get_info() is always used in the condition
!d->arch.vtsc, so it's not necessary to include it again in
enable_tsc_scaling.
>
> >+
> > *incarnation = d->arch.incarnation;
> > *tsc_mode = d->arch.tsc_mode;
> >@@ -1769,7 +1772,7 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
> > }
> > tsc = rdtsc();
> > *elapsed_nsec = scale_delta(tsc, &d->arch.vtsc_to_ns);
> >-*gtsc_khz = cpu_khz;
> >+*gtsc_khz = enable_tsc_scaling ? d->arch.tsc_khz : cpu_khz;
> > break;
> > case TSC_MODE_PVRDTSCP:
> > if ( d->arch.vtsc )
> >@@ -1779,10 +1782,13 @@ void tsc_get_info(struct domain *d, uint32_t
> >*tsc_mode,
> > }
> > else
> > {
> >+struct time_scale *scale = enable_tsc_scaling ?
> >+ &this_cpu(cpu_time).tsc_scale :
> >+ &d->arch.vtsc_to_ns;
>
> IIUIC tsc_scale is host property and so why would it be used if TSC scaling
> is available to guests?
>
scale is used below to convert a host TSC to nanosec. When TSC scaling is used,
d->arch.vtsc_to_ns may not base on the host TSC frequency, so I turn to the host
tsc_scale instead.
Haozhong
> -boris
>
>
> > tsc = rdtsc();
> >-*elapsed_nsec = scale_delta(tsc, &d->arch.vtsc_to_ns) -
> >+*elapsed_nsec = scale_delta(tsc, scale) -
> > d->arch.vtsc_offset;
> >-*gtsc_khz = 0; /* ignored by tsc_set_info */
> >+*gtsc_khz = enable_tsc_scaling ? d->arch.tsc_khz : 0;
> > }
> > break;
> > }
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 65493: regressions - FAIL
flight 65493 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/65493/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 65468 build-i386-xsm5 xen-build fail REGR. vs. 65468 build-amd64-xsm 5 xen-build fail REGR. vs. 65468 build-amd64 5 xen-build fail REGR. vs. 65468 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf fb48e7780e1e0e0a7702ed8772e68150a9f8d10e baseline version: ovmf 84c7452165816ed26cd5bdeb5666d4dc0026f116 Last test of basis65468 2015-12-07 08:14:46 Z0 days Failing since 65485 2015-12-07 18:14:23 Z0 days3 attempts Testing same since65489 2015-12-07 22:43:16 Z0 days2 attempts People who touched revisions under test: Ard Biesheuvel Heyi Guo Yonghong Zhu jobs: build-amd64-xsm fail build-i386-xsm fail 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-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 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 fb48e7780e1e0e0a7702ed8772e68150a9f8d10e Author: Heyi Guo Date: Mon Dec 7 16:51:35 2015 + ArmPkg/BdsLib: Send RemainingDevicePath to PXE Load File protocol Load File protocol requires remaining device path rather than whole device path. For PXE, it actually requires end node device path only, or else invalid parameter will be returned directly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo Reviewed-by: Leif Lindholm git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19148 6f19259b-4bc3-4df7-8a09-765794883524 commit 76a5e6c269a2ce559c8b2d93d77c6672591327a5 Author: Ard Biesheuvel Date: Mon Dec 7 09:22:21 2015 + CryptoPkg/OpensslLib: comment out unused code This comments out the pqueue and ts_* source files from the OpensslLib build, since they have no users. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19147 6f19259b-4bc3-4df7-8a09-765794883524 commit e01f529efccd8c85bbb4f2d7d66470c3a281e57d Author: Ard Biesheuvel Date: Mon Dec 7 09:20:20 2015 + CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC Make mVirtualAddressChangeEvent STATIC to prevent it from conflicting with other variables of the same name that may be defined in other libraries (e.g., MdeModulePkg/Universal/Variable/RuntimeDxe) This also removes the risk of mVirtualAddressChangeEvent being merged with other uninitialized variables with external linkage by toolchains that perform COMMON allocation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19146 6f19259b-4bc3-4df7-8a09-765794883524 commit 8fb0d2e3fd488a045899dc2b890fc57b8d793e0b Author: Ard Biesheuvel Date: Mon Dec 7 09:20:09 2015 + CryptoPkg ARM: add ArmSoftFloatLib resolution to CryptoPkg.dsc In order to build the ARM version of CryptoPkg from its own .DSC file, it n
Re: [Xen-devel] [PATCH v2 03/14] x86/time.c: Use correct guest TSC frequency in tsc_set_info()
On 12/07/15 11:57, Boris Ostrovsky wrote:
> On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
> >When TSC_MODE_PVRDTSCP is used for a HVM container and TSC scaling is
> >available, use the non-zero value of argument gtsc_khz of tsc_set_info()
> >as the guest TSC frequency rather than using the host TSC
> >frequency. Otherwise, TSC scaling will not be able get the correct ratio
> >between the host and guest TSC frequencies.
> >
> >Signed-off-by: Haozhong Zhang
> >---
> > xen/arch/x86/time.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> >diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> >index b5223cf..1091e69 100644
> >--- a/xen/arch/x86/time.c
> >+++ b/xen/arch/x86/time.c
> >@@ -1803,6 +1803,8 @@ void tsc_set_info(struct domain *d,
> >uint32_t tsc_mode, uint64_t elapsed_nsec,
> >uint32_t gtsc_khz, uint32_t incarnation)
> > {
> >+bool_t enable_tsc_scaling;
> >+
> > if ( is_idle_domain(d) || is_hardware_domain(d) )
> > {
> > d->arch.vtsc = 0;
> >@@ -1864,7 +1866,9 @@ void tsc_set_info(struct domain *d,
> > case TSC_MODE_PVRDTSCP:
> > d->arch.vtsc = !boot_cpu_has(X86_FEATURE_RDTSCP) ||
> > !host_tsc_is_safe();
> >-d->arch.tsc_khz = cpu_khz;
> >+enable_tsc_scaling = has_hvm_container_domain(d) &&
> >+ cpu_has_tsc_ratio && d->arch.vtsc;
> >+d->arch.tsc_khz = (enable_tsc_scaling && gtsc_khz) ? gtsc_khz :
> >cpu_khz;
> > set_time_scale(&d->arch.vtsc_to_ns, d->arch.tsc_khz * 1000 );
> > d->arch.ns_to_vtsc = scale_reciprocal(d->arch.vtsc_to_ns);
> > if ( d->arch.vtsc )
> >@@ -1872,7 +1876,10 @@ void tsc_set_info(struct domain *d,
> > else {
> > /* when using native TSC, offset is nsec relative to power-on
> > * of physical machine */
> >-d->arch.vtsc_offset = scale_delta(rdtsc(), &d->arch.vtsc_to_ns)
> >-
> >+struct time_scale *scale = enable_tsc_scaling ?
>
> Do we need this test here? Per previous chunk, enable_tsc_scaling will be
> zero since d->arch.vtsc is false.
>
> Actually, if you are trying to use (or, rather, account for) TSC scaling,
> shouldn't it be !arch.vtsc there?
>
It really should be !arch.vtsc. Don't know why I missed ! here but my
testing code did not.
Thanks,
Haozhong
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 65474: tolerable trouble: broken/fail/pass - PUSHED
flight 65474 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/65474/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 65378 test-amd64-i386-libvirt-pair 4 host-install/dst_host(4) broken REGR. vs. 65378 test-amd64-amd64-xl-rtds 3 host-install(3) broken REGR. vs. 65378 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 65378 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 65378 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail 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-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail 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-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail 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-amd64-amd64-libvirt-vhd 9 debian-di-installfail never pass version targeted for testing: qemuua5582eac15171ffea99f9962dd9a4bf3c1dd2f1c baseline version: qemuu61e3aa25b129b48d8a8cb851aae2a787af7ca5e1 Last test of basis65378 2015-12-04 15:55:10 Z3 days Testing same since65474 2015-12-07 11:13:35 Z0 days1 attempts People who touched revisions under test: Andreas Färber Cao jin Marc-André Lureau Markus Armbruster Peter Maydell jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pa
[Xen-devel] [ovmf test] 65489: regressions - FAIL
flight 65489 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/65489/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 65468 build-i386-xsm5 xen-build fail REGR. vs. 65468 build-amd64-xsm 5 xen-build fail REGR. vs. 65468 build-amd64 5 xen-build fail REGR. vs. 65468 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf fb48e7780e1e0e0a7702ed8772e68150a9f8d10e baseline version: ovmf 84c7452165816ed26cd5bdeb5666d4dc0026f116 Last test of basis65468 2015-12-07 08:14:46 Z0 days Failing since 65485 2015-12-07 18:14:23 Z0 days2 attempts Testing same since65489 2015-12-07 22:43:16 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Heyi Guo Yonghong Zhu jobs: build-amd64-xsm fail build-i386-xsm fail 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-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 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 fb48e7780e1e0e0a7702ed8772e68150a9f8d10e Author: Heyi Guo Date: Mon Dec 7 16:51:35 2015 + ArmPkg/BdsLib: Send RemainingDevicePath to PXE Load File protocol Load File protocol requires remaining device path rather than whole device path. For PXE, it actually requires end node device path only, or else invalid parameter will be returned directly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo Reviewed-by: Leif Lindholm git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19148 6f19259b-4bc3-4df7-8a09-765794883524 commit 76a5e6c269a2ce559c8b2d93d77c6672591327a5 Author: Ard Biesheuvel Date: Mon Dec 7 09:22:21 2015 + CryptoPkg/OpensslLib: comment out unused code This comments out the pqueue and ts_* source files from the OpensslLib build, since they have no users. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19147 6f19259b-4bc3-4df7-8a09-765794883524 commit e01f529efccd8c85bbb4f2d7d66470c3a281e57d Author: Ard Biesheuvel Date: Mon Dec 7 09:20:20 2015 + CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC Make mVirtualAddressChangeEvent STATIC to prevent it from conflicting with other variables of the same name that may be defined in other libraries (e.g., MdeModulePkg/Universal/Variable/RuntimeDxe) This also removes the risk of mVirtualAddressChangeEvent being merged with other uninitialized variables with external linkage by toolchains that perform COMMON allocation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19146 6f19259b-4bc3-4df7-8a09-765794883524 commit 8fb0d2e3fd488a045899dc2b890fc57b8d793e0b Author: Ard Biesheuvel Date: Mon Dec 7 09:20:09 2015 + CryptoPkg ARM: add ArmSoftFloatLib resolution to CryptoPkg.dsc In order to build the ARM version of CryptoPkg from its own .DSC file, it n
[Xen-devel] [linux-next test] 65470: regressions - FAIL
flight 65470 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/65470/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 65420 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 65420 test-amd64-i386-rumpuserxen-i386 10 guest-start fail blocked in 65420 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail blocked in 65420 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stopfail blocked in 65420 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 65420 test-armhf-armhf-xl-xsm 6 xen-boot fail like 65420 test-armhf-armhf-xl-vhd 6 xen-boot fail like 65420 test-armhf-armhf-xl-multivcpu 6 xen-boot fail like 65420 test-armhf-armhf-xl-credit2 6 xen-boot fail like 65420 test-armhf-armhf-libvirt-xsm 6 xen-boot fail like 65420 test-armhf-armhf-libvirt 6 xen-boot fail like 65420 test-armhf-armhf-libvirt-raw 6 xen-boot fail like 65420 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 65420 test-armhf-armhf-xl-rtds 6 xen-boot fail like 65420 test-armhf-armhf-xl-arndale 6 xen-boot fail like 65420 test-armhf-armhf-libvirt-qcow2 6 xen-boot fail like 65420 test-amd64-amd64-libvirt-vhd 9 debian-di-installfail like 65420 test-armhf-armhf-xl 6 xen-boot fail like 65420 test-armhf-armhf-xl-cubietruck 6 xen-boot fail like 65420 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-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-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: linux47ca23615a59f1879e6a2d2fe63d130abdb5c810 baseline version: linuxa2dbb7b56f2c29fc78b18a3fbe47ad80f6912092 Last test of basis (not found) Failing since 0 1970-01-01 00:00:00 Z 16776 days Testing same since65470 2015-12-07 09:32:29 Z0 days1 attempts jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-stub
Re: [Xen-devel] [PATCH v2 0/3] VPMU fixes
On 12/07/2015 04:24 PM, Kleen, Andi wrote: I'm not aware of that specific quirk on Nehalem. Standard perf has a workaround for the errata below, but it sounds different from what you have. But if it's a NHM/WSM problem your model numbers are certainly not enough. That's exactly the problem that we are having --- we don't know who exactly is affected, including whether it's limited to Nehalem. You always need some kind of limiter for the PMI because it is possible to program the PMU that PMIs/NMIs appear back-to-back and lock up the system. But just programming them to 1 is not enough in this case, really have to be limited (perf both accounts and limits the frequency in time and the total CPU consumption of the PMI). Are you referring to 14c63f17b1 / update_perf_cpu_limits()? I think if you have such a generic limiter it would likely be able to handle this issue too. In theory I think we shouldn't need to do this since when guest's VCPU is descheduled its PMU registers are no longer loaded into HW. So if the guest is programming PMU in such a way that it can no longer do any useful work --- well, that's the guest's problem. The quirk that we have in Xen is apparently trying to prevent system lock-up. I should also note that this only observed in HVM (i.e. with VMX) so perhaps this is something specific to virtualization. E.g. getting a PMI while executing a VMRUN or something... Comments of the Nehalem workaround in the main perf code: * Workaround for: * Intel Errata AAK100 (model 26) * Intel Errata AAP53 (model 30) * Intel Errata BD53 (model 44) * * The official story: * These chips need to be 'reset' when adding counters by programming the * magic three (non-counting) events 0x4300B5, 0x4300D2, and 0x4300B1 either * in sequence on the same PMC or on different PMCs. These look like errata for *incorrect* counting and so it's up to guests to work around these (which the guests do, provided they have intel_pmu_nhm_workaround(), or an equivalent in another OS). Thanks. -boris * * In practise it appears some of these events do in fact count, and * we need to programm all 4 events. * The Errata requires below steps: * 1) Clear MSR_IA32_PEBS_ENABLE and MSR_CORE_PERF_GLOBAL_CTRL; * 2) Configure 4 PERFEVTSELx with the magic events and clear *the corresponding PMCx; * 3) set bit0~bit3 of MSR_CORE_PERF_GLOBAL_CTRL; * 4) Clear MSR_CORE_PERF_GLOBAL_CTRL; * 5) Clear 4 pairs of ERFEVTSELx and PMCx; -Andi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 65485: regressions - FAIL
flight 65485 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/65485/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 65468 build-i386-xsm5 xen-build fail REGR. vs. 65468 build-amd64-xsm 5 xen-build fail REGR. vs. 65468 build-amd64 5 xen-build fail REGR. vs. 65468 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 76a5e6c269a2ce559c8b2d93d77c6672591327a5 baseline version: ovmf 84c7452165816ed26cd5bdeb5666d4dc0026f116 Last test of basis65468 2015-12-07 08:14:46 Z0 days Testing same since65485 2015-12-07 18:14:23 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Yonghong Zhu jobs: build-amd64-xsm fail build-i386-xsm fail 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-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 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 76a5e6c269a2ce559c8b2d93d77c6672591327a5 Author: Ard Biesheuvel Date: Mon Dec 7 09:22:21 2015 + CryptoPkg/OpensslLib: comment out unused code This comments out the pqueue and ts_* source files from the OpensslLib build, since they have no users. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19147 6f19259b-4bc3-4df7-8a09-765794883524 commit e01f529efccd8c85bbb4f2d7d66470c3a281e57d Author: Ard Biesheuvel Date: Mon Dec 7 09:20:20 2015 + CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC Make mVirtualAddressChangeEvent STATIC to prevent it from conflicting with other variables of the same name that may be defined in other libraries (e.g., MdeModulePkg/Universal/Variable/RuntimeDxe) This also removes the risk of mVirtualAddressChangeEvent being merged with other uninitialized variables with external linkage by toolchains that perform COMMON allocation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19146 6f19259b-4bc3-4df7-8a09-765794883524 commit 8fb0d2e3fd488a045899dc2b890fc57b8d793e0b Author: Ard Biesheuvel Date: Mon Dec 7 09:20:09 2015 + CryptoPkg ARM: add ArmSoftFloatLib resolution to CryptoPkg.dsc In order to build the ARM version of CryptoPkg from its own .DSC file, it needs a resolution for the ArmSoftFloatLib dependency of OpensslLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19145 6f19259b-4bc3-4df7-8a09-765794883524 commit 7f3f3133ce03c07e893b5bfb7c7700c0201ea5fe Author: Yonghong Zhu Date: Mon Dec 7 09:10:33 2015 + BaseTools: update man page to add some descriptions add the description for --ignore-sources and --check-usage into man page. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu Reviewed-by: Liming Gao git-svn-id:
[Xen-devel] [xen-unstable test] 65463: regressions - trouble: broken/fail/pass
flight 65463 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/65463/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 65114 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail pass in 65429 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 65443 test-armhf-armhf-libvirt-xsm 11 guest-start fail pass in 65443 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) broken blocked in 65114 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail blocked in 65114 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail in 65429 blocked in 65114 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 65114 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail like 65114 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 65114 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 65114 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 65114 test-amd64-amd64-libvirt-vhd 9 debian-di-installfail like 65114 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 65429 never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail in 65429 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 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-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail 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 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-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-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-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-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 0d0f28455d9c019475575d7a36f3c98fa4f0342d baseline version: xen 713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 Last test of basis65114 2015-11-25 19:42:37 Z 12 days Failing since 65141 2015-11-26 20:45:33 Z 11 days 16 attempts Testing same since65372 2015-12-04 12:52:08 Z3 days6 attempts People who touched revisions under test: Andrew Cooper Boris Ostrovsky Daniel De Graaf David Scott David Vrabel Doug Goldstein Ian Campbell Ian Jackson Jan Beulich Jonathan Creekmore Juergen Gross Kai Huang Kevin Tian Len Brown Paul Durrant Robert Hu Roger Pau Monne Roger Pau Monné Wei Liu Xudong Hao Yang Zhang jobs: build-amd64-xsm pass bu
Re: [Xen-devel] [PATCH] xen-blkback: clear PF_NOFREEZE for xen_blkif_schedule()
On Mon, Oct 26, 2015 at 02:47:21PM +0900, Jiri Kosina wrote:
> From: Jiri Kosina
>
> xen_blkif_schedule() kthread calls try_to_freeze() at the beginning of
> every attempt to purge the LRU. This operation can't ever succeed though,
> as the kthread hasn't marked itself as freezable.
!
>
> Before (hopefully eventually) kthread freezing gets converted to fileystem
> freezing, we'd rather mark xen_blkif_schedule() freezable (as it can
> generate I/O during suspend).
>
> Signed-off-by: Jiri Kosina
Thank you for reporting that. Will queue it up for Linux 4.5!
> ---
> drivers/block/xen-blkback/blkback.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/block/xen-blkback/blkback.c
> b/drivers/block/xen-blkback/blkback.c
> index af3caa3..bb65f7c 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -597,6 +597,7 @@ int xen_blkif_schedule(void *arg)
>
> xen_blkif_get(blkif);
>
> + set_freezable();
> while (!kthread_should_stop()) {
> if (unlikely(vbd->size != vbd_sz(vbd)))
> xen_vbd_resize(blkif);
>
> --
> Jiri Kosina
> SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules
On 12/3/15 2:57 AM, Jan Beulich wrote:
On 03.12.15 at 01:34, wrote:
>> On 12/1/15 5:22 AM, Jan Beulich wrote:
>> On 30.11.15 at 18:53, wrote:
On 11/30/15 8:36 AM, Jan Beulich wrote:
On 24.11.15 at 18:51, wrote:
>> +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
>> +
>> +config SRCARCH
>> +string
>> +option env="SRCARCH"
>> +
>> +config ARCH
>> +string
>> +option env="ARCH"
>> +
>> +source "arch/$SRCARCH/Kconfig"
>> +
>> +config XEN_FULLVERSION
>> +string
>> +option env="XEN_FULLVERSION"
>> +
>> +config DEFCONFIG_LIST
>> +string
>> +option defconfig_list
>> +default "$ARCH_DEFCONFIG"
>> +default "arch/$SRCARCH/defconfig"
>
> Linux'es variant has just SRCARCH and the source directive. Why
> do we need so much more here? In any even I again think you
> should at least briefly explain any extensions you do in the commit
> message.
I'm not understanding the question here. Linux has 5 items in their
list. The last two are identical to the 2 that I retained. Given other
evolutions of the patchset I can drop the last one and keep it as just
$ARCH_DEFCONFIG since I've always got that defined for arm and x86.
>>>
>>> Oh, the context was ambiguous: The comment related to everything
>>> quoted, not just the last option. I.e. I'm being irritated by there being
>>> quite a few more config options here compared to Linux.
>>
>> So all these items are in Linux. And they seem to actually be necessary.
>> You'll just find them in different files (e.g. init/Kconfig) that I
>> didn't import because we really didn't need them for anything.
>
> Okay, this makes sense. Remains the question on the
> XEN_FULLVERSION name: Doesn't this collide with the identically
> named make variable? Or is it intentionally named the same? In
> which case - what's the purpose? There's no
> CONFIG_KERNELVERSION resulting from this in Linux (which seems
> in line with documentation).
This is intentional. Its for when you run "make {menu,n,g,x}config" and
it'll show the version info at the top. It also puts the version info as
a comment inside the .config. Just cosmetic stuff.
>
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
>>
>> EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
>>
>> +# Don't break if the build process wasn't called from the top level
>> +XEN_TARGET_ARCH ?= $(shell uname -m)
>
> I don't see the need for this. We already require setting this on the
> command line when invoking a build process bypassing the top level
> directory. Later in the series, when actually using the produced
> xen/.config, I could see this becoming a nice enhancement (by
> reading the value from the file).
One of the early on reviews told me it was not required (and I can
confirm that I can run "git clean -xdf && cd xen && make" and it will
build). This change makes that behavior still work.
>>>
>>> Yes, non-cross builds of course have been working without setting
>>> that variable. I was (not clearly enough) referring to cross builds,
>>> including hypervisor builds on ix86 distros (which I consider at best
>>> kind of cross, but would really deem to be native with there not
>>> being any 32-bit hypervisor anymore).
>>>
>>> So can you clarify what exactly breaks in which way without this
>>> change?
>>
>> The ability to "git clone git://xen && cd xen/xen && make" because I
>> couldn't pick the correct defconfig to use. See the rules just below
>> this reply in xen/Makefile where they are used.
>
> Okay. But - does "uname -m" really produce e.g. "arm32" and "arm64"
> respectively, and not, as I would expect, "armv..." and "aarch64"?
> See the setup of XEN_COMPILE_ARCH in ./Config.mk.
I've switched to pulling in Config.mk
>
>> @@ -216,3 +220,16 @@ FORCE:
>>
>> %/: FORCE
>> $(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
>> +
>> +kconfig := silentoldconfig oldconfig config menuconfig defconfig \
>> +nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
>> +.PHONY: $(kconfig)
>> +$(kconfig):
>> +$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile
>> ARCH=$(XEN_TARGET_ARCH) $@
>> +
>> +$(BASEDIR)/include/config/%.conf:
>> $(BASEDIR)/include/config/auto.conf.cmd
>> +$(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile
>> ARCH=$(XEN_TARGET_ARCH) silentoldconfig
>
> Okay, I have found the Linux original to this and it's the same there,
> but I'd like to ask anyway: How can this work without $* getting
> passed on?
silentoldconfig is the step that actually takes the .config and
generates out all the files like auto.conf and generated/config.h It
should
Re: [Xen-devel] [PATCH v2 0/3] VPMU fixes
I'm not aware of that specific quirk on Nehalem. Standard perf has a workaround for the errata below, but it sounds different from what you have. But if it's a NHM/WSM problem your model numbers are certainly not enough. You always need some kind of limiter for the PMI because it is possible to program the PMU that PMIs/NMIs appear back-to-back and lock up the system. But just programming them to 1 is not enough in this case, really have to be limited (perf both accounts and limits the frequency in time and the total CPU consumption of the PMI). I think if you have such a generic limiter it would likely be able to handle this issue too. Comments of the Nehalem workaround in the main perf code: * Workaround for: * Intel Errata AAK100 (model 26) * Intel Errata AAP53 (model 30) * Intel Errata BD53 (model 44) * * The official story: * These chips need to be 'reset' when adding counters by programming the * magic three (non-counting) events 0x4300B5, 0x4300D2, and 0x4300B1 either * in sequence on the same PMC or on different PMCs. * * In practise it appears some of these events do in fact count, and * we need to programm all 4 events. * The Errata requires below steps: * 1) Clear MSR_IA32_PEBS_ENABLE and MSR_CORE_PERF_GLOBAL_CTRL; * 2) Configure 4 PERFEVTSELx with the magic events and clear *the corresponding PMCx; * 3) set bit0~bit3 of MSR_CORE_PERF_GLOBAL_CTRL; * 4) Clear MSR_CORE_PERF_GLOBAL_CTRL; * 5) Clear 4 pairs of ERFEVTSELx and PMCx; -Andi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 38461: all pass
This run is configured for baseline tests only. flight 38461 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38461/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf 84c7452165816ed26cd5bdeb5666d4dc0026f116 baseline version: ovmf 68312710615c3499341f3e300b0a3921dea5a39b Last test of basis38451 2015-12-05 12:23:32 Z2 days Testing same since38461 2015-12-07 17:54:00 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Baraneedharan Anbazhagan Chao Zhang Daocheng Bu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 84c7452165816ed26cd5bdeb5666d4dc0026f116 Author: Ard Biesheuvel Date: Mon Dec 7 06:33:27 2015 + CryptoPkg: remove global variable 'timeval' from OpenSslSupport.h The header file OpenSslSupport.h not only defines a type 'struct timeval' but also defines a global variable 'timeval' of that type. The RVCT compiler does not merge this definition into a common symbol, resulting in duplicate definition errors in the final link. So remove the variable definition. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Qin Long git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19135 6f19259b-4bc3-4df7-8a09-765794883524 commit 96832eefea1025c130979dec9b7da069f77bcd96 Author: Chao Zhang Date: Mon Dec 7 06:20:36 2015 + SecurityPkg: SecureBootConfigDxe: SecureBoot UI for Customized SecureBoot Mode Add SecureBoot UI support for Customized SecureBoot Mode transition according to Mantis 1263. User can do secure boot mode transition through UI. https://mantis.uefi.org/mantis/view.php?id=1263 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chao Zhang Reviewed-by: Zeng Star Reviewed-by: Long Qin git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19134 6f19259b-4bc3-4df7-8a09-765794883524 commit 4fc08e8d683522f255727626197d919a40d4836c Author: Chao Zhang Date: Mon Dec 7 06:20:02 2015 + SecurityPkg: AuthVariableLib: Customized SecureBoot Mode transition. Implement Customized SecureBoot Mode transition logic according to Mantis 1263, including AuditMode/DeployedMode/PK update management. Also implement image verification logic in AuditMode. Image Certificate & Hash are recorded to EFI Image Execution Table. https://mantis.uefi.org/mantis/view.php?id=1263 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chao Zhang Reviewed-by: Zeng Star Reviewed-by: Long Qin git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19133 6f19259b-4bc3-4df7-8a09-765794883524 commit af9af05bec5b1880f8e4f9142ecc0044fd0acb33 Author: Chao Zhang Date: Mon Dec 7 06:16:23 2015 + SecurityPkg: Add gEdkiiSecureBootModeGuid definition Add gEdkiiSecureBootModeGuid definition for Enable Secure Boot feature defined in UEFI2.5 Mantis 1263. It is a private variable GUID. https://mantis.uefi.org/mantis/view.php?id=1263 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chao Zhang Reviewed-by: Zeng Star Reviewed-by: Long Qin git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19132 6f19259b-4bc3-4df7-8a09-765794883524 commit 0f4f6d202a47e3882c6a7fb7ab9e55dda78a8113 Author: Chao Zhang Date: Mon Dec 7 06:15:49 2015 + MdeModulePkg: VarCheckUefiLib: Add DeployedMode/AuditMode var check logic DeployedMode & AuditMode are UINT8 Global variable according to Enable Secure Boot feature defined in UEFI2.5 Mantis 1263. Add them to var check list.
Re: [Xen-devel] [PATCH v4 2/2] x86/VPMU: implement ipc and arch filter flags
On 11/30/2015 07:39 PM, Brendan Gregg wrote:
This introduces a way to have a restricted VPMU, by specifying one of two
predefined groups of PMCs to make available. For secure environments, this
allows the VPMU to be used without needing to enable all PMCs.
Signed-off-by: Brendan Gregg
Reviewed-by: Boris Ostrovsky
This needs to be reviewed also by Intel maintainers (copied). Plus x86
maintainers.
-boris
---
docs/misc/xen-command-line.markdown | 15 ++-
xen/arch/x86/cpu/vpmu.c | 51 +
xen/arch/x86/cpu/vpmu_intel.c | 50
xen/include/asm-x86/msr-index.h | 1 +
xen/include/public/pmu.h| 14 --
5 files changed, 117 insertions(+), 14 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 70daa84..795661e 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1452,7 +1452,7 @@ Use Virtual Processor ID support if available. This
prevents the need for TLB
flushes on VM entry and exit, increasing performance.
### vpmu
-> `= ( bts )`
+> `= ( | { bts | ipc | arch [, ...] } )`
> Default: `off`
@@ -1468,6 +1468,19 @@ wrong behaviour (see handle\_pmc\_quirk()).
If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
feature is switched on on Intel processors supporting this feature.
+vpmu=ipc enables performance monitoring, but restricts the counters to the
+most minimum set possible: instructions, cycles, and reference cycles. These
+can be used to calculate instructions per cycle (IPC).
+
+vpmu=arch enables performance monitoring, but restricts the counters to the
+pre-defined architectural events only. These are exposed by cpuid, and listed
+in the Pre-Defined Architectural Performance Events table from the Intel 64
+and IA-32 Architectures Software Developer's Manual, Volume 3B, System
+Programming Guide, Part 2.
+
+If a boolean is not used, combinations of flags are allowed, comma separated.
+For example, vpmu=arch,bts.
+
Note that if **watchdog** option is also specified vpmu will be turned off.
*Warning:*
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 2f5156a..46b5324 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -43,34 +43,59 @@ CHECK_pmu_data;
CHECK_pmu_params;
/*
- * "vpmu" : vpmu generally enabled
- * "vpmu=off" : vpmu generally disabled
- * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
+ * "vpmu" : vpmu generally enabled (all counters)
+ * "vpmu=off" : vpmu generally disabled
+ * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
+ * "vpmu=ipc" : vpmu enabled for IPC counters only (most restrictive)
+ * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive)
+ * flag combinations are allowed, eg, "vpmu=ipc,bts".
*/
static unsigned int __read_mostly opt_vpmu_enabled;
unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
unsigned int __read_mostly vpmu_features = 0;
-static void parse_vpmu_param(char *s);
-custom_param("vpmu", parse_vpmu_param);
+static void parse_vpmu_params(char *s);
+custom_param("vpmu", parse_vpmu_params);
static DEFINE_SPINLOCK(vpmu_lock);
static unsigned vpmu_count;
static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
-static void __init parse_vpmu_param(char *s)
+static int parse_vpmu_param(char *s, int len)
{
+if ( ! *s || ! len )
+return 0;
+if ( !strncmp(s, "bts", len) )
+vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
+else if ( !strncmp(s, "ipc", len) )
+vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
+else if ( !strncmp(s, "arch", len) )
+vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
+else
+return 1;
+return 0;
+}
+
+static void __init parse_vpmu_params(char *s)
+{
+char *sep, *p = s;
+
switch ( parse_bool(s) )
{
case 0:
break;
default:
-if ( !strcmp(s, "bts") )
-vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
-else if ( *s )
+while (1)
{
-printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
-break;
+sep = strchr(p, ',');
+if ( sep == NULL )
+sep = strchr(p, 0);
+if ( parse_vpmu_param(p, sep - p) )
+goto error;
+if ( *sep == 0 )
+/* reached end of flags */
+break;
+p = sep + 1;
}
/* fall through */
case 1:
@@ -79,6 +104,10 @@ static void __init parse_vpmu_param(char *s)
opt_vpmu_enabled = 1;
break;
}
+return;
+
+ error:
+printk("VPMU: unknown flags: %s - vpmu disabled!\n", s);
}
void vpmu_lvtpc_update(uint32_t val)
diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index 8d83a1a..a6c5545 100644
--- a/
Re: [Xen-devel] [PATCH v2 11/14] x86/hvm: Move saving/loading vcpu's TSC to common code
On 12/06/2015 03:58 PM, Haozhong Zhang wrote: Both VMX and SVM save/load vcpu's TSC when saving/loading vcpu's context, so this patch moves saving/loading vcpu's TSC to the common functions hvm_[save|load]_cpu_ctxt(). Signed-off-by: Haozhong Zhang Acked-by: Jan Beulich --- xen/arch/x86/hvm/hvm.c | 4 xen/arch/x86/hvm/svm/svm.c | 5 - xen/arch/x86/hvm/vmx/vmx.c | 5 - 3 files changed, 4 insertions(+), 10 deletions(-) Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 12/14] x86/hvm: Detect TSC scaling through hvm_funcs
On 12/06/2015 03:58 PM, Haozhong Zhang wrote: This patch uses hvm_funcs.tsc_scaling_supported instead of the architecture code to detect the TSC scaling support. Signed-off-by: Haozhong Zhang Acked-by: Jan Beulich --- xen/arch/x86/time.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 10/14] x86/hvm: Replace architecture TSC scaling by a common function
On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
This patch implements a common function hvm_scale_tsc() to scale TSC by
using TSC scaling information collected by architecture code.
Signed-off-by: Haozhong Zhang
---
xen/arch/x86/hvm/hvm.c| 18 +--
xen/arch/x86/hvm/svm/svm.c| 12
xen/arch/x86/time.c | 2 +-
xen/include/asm-x86/hvm/hvm.h | 3 +-
xen/include/asm-x86/math64.h | 70 +++
5 files changed, 88 insertions(+), 17 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 52a0ef8..1e3d89f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -302,6 +302,20 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
return 1;
}
+u64 hvm_scale_tsc(const struct vcpu *v, u64 tsc)
+{
+u64 ratio = v->arch.hvm_vcpu.tsc_scaling_ratio;
+
+if ( !hvm_funcs.tsc_scaling_supported ||
+ ratio == hvm_funcs.default_tsc_scaling_ratio )
+return tsc;
+
+BUG_ON(hvm_funcs.tsc_scaling_ratio_frac_bits >= 64 ||
+ hvm_funcs.tsc_scaling_ratio_frac_bits == 0);
Since these values never change, I am not sure it's worth testing this.
And if you think it is then I'd do it somewhere in initialization code.
+
+return mul_u64_u64_shr(tsc, ratio, hvm_funcs.tsc_scaling_ratio_frac_bits);
+}
+
diff --git a/xen/include/asm-x86/math64.h b/xen/include/asm-x86/math64.h
index 9af6aee..c6a472b 100644
--- a/xen/include/asm-x86/math64.h
+++ b/xen/include/asm-x86/math64.h
@@ -27,4 +27,74 @@ static inline u64 mul_u64_u32_div(u64 a, u32 mul, u32
divisor)
return rl.ll;
}
+/*
+ * Multiply two 64-bit unsigned integers a and b. The most and least
+ * significant 64 bits of the 128-bit result are returned through hi
+ * and lo respectively.
+ */
+static inline void mul64(u64 *lo, u64 *hi, u64 a, u64 b)
Please move these routines (as well as one in previous patch into a
standalone math patch (and provide attribution to wherever they came from).
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] [FOR 1.3.0 PATCH] conf: add net device prefix for Xen
On Mon, Dec 07, 2015 at 09:42:21AM -0700, Jim Fehlig wrote:
> In commit d2e5538b1, the libxl driver was changed to copy interface
> names autogenerated by libxl to the corresponding network def in the
> domain's virDomainDef object. The copied name is freed when the domain
> transitions to the shutoff state. But when migrating a domain, the
> autogenerated name is included in the XML sent to the destination host.
> It is possible an interface with the same name already exists on the
> destination host, causing migration to fail. Indeed the Xen project's
> OSSTEST CI already encountered such a failure.
>
> This patch defines another VIR_NET_GENERATED_PREFIX for Xen, allowing
> the autogenerated names to be excluded when parsing and formatting
> inactive config.
>
> Signed-off-by: Jim Fehlig
> ---
>
> This is an alternative approach to Joao's fix for this regression
>
> https://www.redhat.com/archives/libvir-list/2015-December/msg00197.html
>
> I think it is the same approach used by the qemu driver. My only
> reservation is that it expands the potential for clashes with
> user-defined names. I.e. with this change both 'vnet' and 'vif' are
> reserved prefixes.
Hmm, yes, tricky one.
If we only care about XML parsing, then you could register a post
parse callback instead to do this.
I'm not clear why we also have it in the virDomainNetDefFormat
method - and we can't solve that with a post-parse callback.
The other option would be to make the reserved prefix be a
capability that the parser/formatter could read.
>
> src/conf/domain_conf.c | 6 --
> src/conf/domain_conf.h | 4
> src/libxl/libxl_domain.c | 5 +++--
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 2f5c0ed..debcf4e 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -8428,7 +8428,8 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt,
> ifname = virXMLPropString(cur, "dev");
> if (ifname &&
> (flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) &&
> -STRPREFIX(ifname, VIR_NET_GENERATED_PREFIX)) {
> +(STRPREFIX(ifname, VIR_NET_GENERATED_PREFIX) ||
> + STRPREFIX(ifname, VIR_NET_GENERATED_PREFIX_XEN))) {
> /* An auto-generated target name, blank it out */
> VIR_FREE(ifname);
> }
> @@ -19790,7 +19791,8 @@ virDomainNetDefFormat(virBufferPtr buf,
> virBufferEscapeString(buf, "\n",
> def->domain_name);
> if (def->ifname &&
> !((flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE) &&
> - (STRPREFIX(def->ifname, VIR_NET_GENERATED_PREFIX {
> + (STRPREFIX(def->ifname, VIR_NET_GENERATED_PREFIX) ||
> + STRPREFIX(def->ifname, VIR_NET_GENERATED_PREFIX_XEN {
> /* Skip auto-generated target names for inactive config. */
> virBufferEscapeString(buf, "\n", def->ifname);
> }
> diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> index 90d8e13..d2cc26f 100644
> --- a/src/conf/domain_conf.h
> +++ b/src/conf/domain_conf.h
> @@ -1085,6 +1085,10 @@ struct _virDomainNetDef {
> * by libvirt, and cannot be used for a persistent network name. */
> # define VIR_NET_GENERATED_PREFIX "vnet"
>
> +/* Used for prefix of ifname of any network name generated dynamically
> + * by libvirt for Xen, and cannot be used for a persistent network name. */
> +# define VIR_NET_GENERATED_PREFIX_XEN "vif"
> +
> typedef enum {
> VIR_DOMAIN_CHR_DEVICE_STATE_DEFAULT = 0,
> VIR_DOMAIN_CHR_DEVICE_STATE_CONNECTED,
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index ef92974..c5d84a4 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -734,7 +734,7 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
> for (i = 0; i < vm->def->nnets; i++) {
> virDomainNetDefPtr net = vm->def->nets[i];
>
> -if (STRPREFIX(net->ifname, "vif"))
> +if (STRPREFIX(net->ifname, VIR_NET_GENERATED_PREFIX_XEN))
> VIR_FREE(net->ifname);
> }
> }
> @@ -918,7 +918,8 @@ libxlDomainCreateIfaceNames(virDomainDefPtr def,
> libxl_domain_config *d_config)
> if (net->ifname)
> continue;
>
> -ignore_value(virAsprintf(&net->ifname, "vif%d.%d%s",
> +ignore_value(virAsprintf(&net->ifname,
> + VIR_NET_GENERATED_PREFIX_XEN "%d.%d%s",
> def->id, x_nic->devid, suffix));
> }
> }
> --
> 2.6.1
>
> --
> libvir-list mailing list
> libvir-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.or
Re: [Xen-devel] [PATCH v2 09/14] x86/hvm: Setup TSC scaling ratio
On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
This patch adds a field tsc_scaling_ratio in struct hvm_vcpu to
record the TSC scaling ratio, and sets it up when tsc_set_info() is
called for a vcpu or when a vcpu is restored or reset.
Signed-off-by: Haozhong Zhang
Reviewed-by: Boris Ostrovsky
with a few nits below.
---
xen/arch/x86/hvm/hvm.c| 30 ++
xen/arch/x86/hvm/svm/svm.c| 6 --
xen/arch/x86/time.c | 13 -
xen/include/asm-x86/hvm/hvm.h | 5 +
xen/include/asm-x86/hvm/svm/svm.h | 3 ---
xen/include/asm-x86/hvm/vcpu.h| 2 ++
xen/include/asm-x86/math64.h | 30 ++
7 files changed, 83 insertions(+), 6 deletions(-)
create mode 100644 xen/include/asm-x86/math64.h
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0e63c33..52a0ef8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -65,6 +65,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -301,6 +302,29 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
return 1;
}
+void hvm_setup_tsc_scaling(struct vcpu *v)
+{
+u64 ratio;
+
+if ( !hvm_funcs.tsc_scaling_supported )
+return;
+
+/*
+ * The multiplication of the first two terms may overflow a 64-bit
+ * integer, so use mul_u64_u32_div() instead to keep precision.
+ */
+ratio = mul_u64_u32_div(1ULL << hvm_funcs.tsc_scaling_ratio_frac_bits,
+v->domain->arch.tsc_khz, cpu_khz);
+
+if ( ratio == 0 || ratio > hvm_funcs.max_tsc_scaling_ratio )
+return;
+
+v->arch.hvm_vcpu.tsc_scaling_ratio = ratio;
+
+if ( hvm_funcs.setup_tsc_scaling )
+hvm_funcs.setup_tsc_scaling(v);
+}
+
void hvm_set_guest_tsc_fixed(struct vcpu *v, u64 guest_tsc, u64 at_tsc)
{
uint64_t tsc;
@@ -2024,6 +2048,9 @@ static int hvm_load_cpu_ctxt(struct domain *d,
hvm_domain_context_t *h)
if ( hvm_funcs.load_cpu_ctxt(v, &ctxt) < 0 )
return -EINVAL;
+if ( hvm_funcs.tsc_scaling_supported )
+hvm_setup_tsc_scaling(v);
+
I think you can drop the test here (and below) since you do the same
check inside hvm_setup_tsc_scaling()
v->arch.hvm_vcpu.msr_tsc_aux = ctxt.msr_tsc_aux;
seg.limit = ctxt.idtr_limit;
@@ -5584,6 +5611,9 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs,
uint16_t ip)
hvm_set_segment_register(v, x86_seg_gdtr, ®);
hvm_set_segment_register(v, x86_seg_idtr, ®);
+if ( hvm_funcs.tsc_scaling_supported )
+hvm_setup_tsc_scaling(v);
+
/* Sync AP's TSC with BSP's. */
v->arch.hvm_vcpu.cache_tsc_offset =
v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 9f741d0..d291327 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -811,7 +811,7 @@ static uint64_t svm_scale_tsc(struct vcpu *v, uint64_t tsc)
if ( !cpu_has_tsc_ratio || d->arch.vtsc )
return tsc;
-return scale_tsc(tsc, vcpu_tsc_ratio(v));
+return scale_tsc(tsc, v->arch.hvm_vcpu.tsc_scaling_ratio);
}
static uint64_t svm_get_tsc_offset(uint64_t host_tsc, uint64_t guest_tsc,
@@ -987,7 +987,7 @@ static inline void svm_tsc_ratio_save(struct vcpu *v)
static inline void svm_tsc_ratio_load(struct vcpu *v)
{
if ( cpu_has_tsc_ratio && !v->domain->arch.vtsc )
-wrmsrl(MSR_AMD64_TSC_RATIO, vcpu_tsc_ratio(v));
+wrmsrl(MSR_AMD64_TSC_RATIO, v->arch.hvm_vcpu.tsc_scaling_ratio);
}
static void svm_ctxt_switch_from(struct vcpu *v)
@@ -1193,6 +1193,8 @@ static int svm_vcpu_initialise(struct vcpu *v)
svm_guest_osvw_init(v);
+v->arch.hvm_vcpu.tsc_scaling_ratio = DEFAULT_TSC_RATIO;
+
return 0;
}
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 732d1e9..d4a94eb 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1902,8 +1902,19 @@ void tsc_set_info(struct domain *d,
if ( has_hvm_container_domain(d) )
{
hvm_set_rdtsc_exiting(d, d->arch.vtsc);
-if ( d->vcpu && d->vcpu[0] && incarnation == 0 )
+if ( d->vcpu && d->vcpu[0] )
{
+ /*
+ * TSC scaling ratio on BSP is set here during initial boot, while
During domain creation rather then during boot.
+ * the same TSC scaling ratio on APs will be set in
+ * hvm_vcpu_reset_state().
+ */
+if ( !d->arch.vtsc && hvm_funcs.tsc_scaling_supported )
+hvm_setup_tsc_scaling(d->vcpu[0]);
+
+if ( incarnation )
+return;
+
/*
* set_tsc_offset() is called from hvm_vcpu_initialise() before
* tsc_set_info(). New vtsc mode may require recomputing TSC
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 8b10a6
Re: [Xen-devel] Xc_mem_access_enable_emulate() is currently a no-operation
On 12/07/2015 07:55 PM, Lengyel, Tamas wrote: > > > On Mon, Dec 7, 2015 at 4:09 AM, Razvan Cojocaru > mailto:rcojoc...@bitdefender.com>> wrote: > > Hello, > > While looking at some code with Tamas these past few days, we discovered > that xc_mem_access_enable_emulate() doesn't actually do anything other > that setting the mem_access_emulate_enabled flag. > > Fixing that would likely be trivial (if the flag is not set, > p2m_mem_access_emulate_check() should just return). However, my question > is: do we really need that function? Are there cases where it would make > sense to use the vm_event subsystem but disable emulation support? After > all, if the client code wants to use emulation support it can call > xc_mem_access_enable_emulate(), and if not it can simply not set the > EMULATE flags in the vm_event replies. > > As far as I'm concerned, the libxc function can go (along with the > per-domain flag), but then again we're emulation-intensive so it's quite > possible that I'm not seeing the proper use case for this. > > Thoughts? > > > It may make sense to gate the allocation of struct arch_vm_event to only > happen when emulation has been enabled beforehand for the domain (the > struct is used only for this purpose). Most places where it is used its > checked for by unlikely(v->arch.vm_event) checks anyway so I feel like > this was the original intention of having this flag to begin with. It's > not checked everywhere like this though so we need to verify that all > places that use it do check before using it. I think the vm_event cleanup series (which introduced xc_mem_access_enable_emulate()) hit staging some months before I've changed the code to dynamically allocate that struct. Also, the struct is not only used for emulation. Please see the struct monitor_write_data write_data; member, that regulates CR and MSR writes. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 08/14] x86/hvm: Collect information of TSC scaling ratio
On 12/06/2015 03:58 PM, Haozhong Zhang wrote: Both VMX TSC scaling and SVM TSC ratio use the 64-bit TSC scaling ratio, but the number of fractional bits of the ratio is different between VMX and SVM. This patch adds the architecture code to collect the number of fractional bits and other related information into fields of struct hvm_function_table so that they can be used in the common code. Signed-off-by: Haozhong Zhang Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 07/14] svm: Remove redundant TSC scaling in svm_set_tsc_offset()
On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
Now every caller passes an already scaled offset to
svm_set_tsc_offset(), so it's not necessary to recalculate a scaled TSC
offset in svm_set_tsc_offset().
Signed-off-by: Haozhong Zhang
---
xen/arch/x86/hvm/svm/svm.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 9d5f2c3..3d22dfa 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -826,19 +826,7 @@ static void svm_set_tsc_offset(struct vcpu *v, u64 offset,
u64 at_tsc)
struct vmcb_struct *n1vmcb, *n2vmcb;
uint64_t n2_tsc_offset = 0;
struct domain *d = v->domain;
-uint64_t host_tsc, guest_tsc;
-
-guest_tsc = hvm_get_guest_tsc_fixed(v, at_tsc);
-
-/* Re-adjust the offset value when TSC_RATIO is available */
-if ( cpu_has_tsc_ratio && !d->arch.vtsc )
-{
-if ( at_tsc )
-host_tsc = at_tsc;
-else
-host_tsc = rdtsc();
-offset = svm_get_tsc_offset(host_tsc, guest_tsc, vcpu_tsc_ratio(v));
-}
+uint64_t guest_tsc;
You could declare it at the first use site below.
Other than that,
Reviewed-by: Boris Ostrovsky
if ( !nestedhvm_enabled(d) ) {
vmcb_set_tsc_offset(vmcb, offset);
@@ -854,6 +842,7 @@ static void svm_set_tsc_offset(struct vcpu *v, u64 offset,
u64 at_tsc)
n2_tsc_offset = vmcb_get_tsc_offset(n2vmcb) -
vmcb_get_tsc_offset(n1vmcb);
if ( svm->ns_tscratio != DEFAULT_TSC_RATIO ) {
+guest_tsc = hvm_get_guest_tsc_fixed(v, at_tsc);
n2_tsc_offset = svm_get_tsc_offset(guest_tsc,
guest_tsc + n2_tsc_offset, svm->ns_tscratio);
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 06/14] x86/time.c: Scale host TSC in pvclock properly
On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
This patch makes the pvclock return the scaled host TSC and
corresponding scaling parameters to HVM domains if guest TSC is not
emulated and TSC scaling is enabled.
Signed-off-by: Haozhong Zhang
+Joao who has been staring at this code.
Joao, can you run this series through your test with non-native
frequency?
(http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg00683.html
provides an interface to set it in config file).
---
xen/arch/x86/time.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 95df4f1..732d1e9 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -815,10 +815,18 @@ static void __update_vcpu_system_time(struct vcpu *v, int
force)
}
else
{
-tsc_stamp = t->local_tsc_stamp;
-
-_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
-_u.tsc_shift = (s8)t->tsc_scale.shift;
+if ( is_hvm_domain(d) && cpu_has_tsc_ratio )
+{
+tsc_stamp= hvm_funcs.scale_tsc(v, t->local_tsc_stamp);
+_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
+_u.tsc_shift = d->arch.vtsc_to_ns.shift;
I am not sure this is correct (which is why I asked Joao to look at this
and test). The scaler below is calculated as result of TSC calibration
across physical CPUs and what you use above (vtsc_to_ns) is an
uncalibrated value.
-boris
+}
+else
+{
+tsc_stamp= t->local_tsc_stamp;
+_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
+_u.tsc_shift = (s8)t->tsc_scale.shift;
+}
}
_u.tsc_timestamp = tsc_stamp;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] AVC denied for pcilevel in stubdom test case
Hi Daniel
I notice there is avc denied message in our stubdom test case, which
should probably be fixed in default policy.
Dec 6 19:56:57.681026 (XEN) avc: denied { pcilevel } for domid=2 target=1
scontext=system_u:system_r:dm_dom_t tcontext=system_u:system_r:domU_t_target
tclass=hvm
See following link for more information.
http://logs.test-lab.xenproject.org/osstest/logs/65443/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/serial-merlot1.log
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] fyi, Xen's EFI workarounds (/mapbs & efi=no-rs) on SuperMicro hardware; fixes solve 1/2 problems & SM responds that can't/won't fix their firmware
> > Now attached. > >> > >> xen.efi /noexitboot /mapbs > >> > >> And you can try without 'efi=no-rs'. > >> > >> However I am wondering - why are you using '/mapbs' ? What did it > >> help? (The combination of 'efi=no-rs' means you are in effect not > >> using _any_ EFI operations - so doing /mapbs is not needed). > >> > >> > >> ___ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel > > Konrad, Heya!! > > Can we land the /noexitboot (probably better to call it /noexitbs to > match rs) into the tree? It is up to the EFI maintainer (Jan) who would like the vendors to fix their broken firmware before adding this gross hack in. > > I have to have a very similar patch locally to bring up my machine and > it would make sense that if you and I are seeing this problem then > others are. I think the way going forward is to make Xen capable of working in the VirtualAddress instead of the 1:1. The problem isn't fixing the code (it blows up if you try enabling) - it is that we lose kexec support unless we also make kexec be less Linux-centric when booting under EFI. This is a topic I think we should bring up at the XenHackathon(Dev summit?) in Cambridge, UK to hash out. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xc_mem_access_enable_emulate() is currently a no-operation
On Mon, Dec 7, 2015 at 4:09 AM, Razvan Cojocaru wrote: > Hello, > > While looking at some code with Tamas these past few days, we discovered > that xc_mem_access_enable_emulate() doesn't actually do anything other > that setting the mem_access_emulate_enabled flag. > > Fixing that would likely be trivial (if the flag is not set, > p2m_mem_access_emulate_check() should just return). However, my question > is: do we really need that function? Are there cases where it would make > sense to use the vm_event subsystem but disable emulation support? After > all, if the client code wants to use emulation support it can call > xc_mem_access_enable_emulate(), and if not it can simply not set the > EMULATE flags in the vm_event replies. > > As far as I'm concerned, the libxc function can go (along with the > per-domain flag), but then again we're emulation-intensive so it's quite > possible that I'm not seeing the proper use case for this. > > Thoughts? > It may make sense to gate the allocation of struct arch_vm_event to only happen when emulation has been enabled beforehand for the domain (the struct is used only for this purpose). Most places where it is used its checked for by unlikely(v->arch.vm_event) checks anyway so I feel like this was the original intention of having this flag to begin with. It's not checked everywhere like this though so we need to verify that all places that use it do check before using it. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 05/14] x86/hvm: Scale host TSC when setting/getting guest TSC
On 12/06/2015 03:58 PM, Haozhong Zhang wrote: The existing hvm_[set|get]_guest_tsc_fixed() calculate the guest TSC by adding the TSC offset to the host TSC. When the TSC scaling is enabled, the host TSC should be scaled first. This patch adds the scaling logic to those two functions. Signed-off-by: Haozhong Zhang Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/14] x86/time.c: Use correct guest TSC frequency in tsc_get_info()
On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
When the TSC mode of a HVM container is TSC_MODE_DEFAULT or
TSC_MODE_PVRDTSCP and no TSC emulation is used, the existing
tsc_get_info() uses the host TSC frequency (cpu_khz) as the guest TSC
frequency. However, tsc_set_info() may set the guest TSC frequency to a
value different than the host. In order to keep consistent to
tsc_set_info(), this patch makes tsc_get_info() use the value set by
tsc_set_info() as the guest TSC frequency.
Signed-off-by: Haozhong Zhang
---
xen/arch/x86/time.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 1091e69..95df4f1 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1749,6 +1749,9 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
uint64_t *elapsed_nsec, uint32_t *gtsc_khz,
uint32_t *incarnation)
{
+bool_t enable_tsc_scaling = has_hvm_container_domain(d) &&
+cpu_has_tsc_ratio;
&& !d->arch.vtsc ?
(assuming my comment to the previous patch is correct).
+
*incarnation = d->arch.incarnation;
*tsc_mode = d->arch.tsc_mode;
@@ -1769,7 +1772,7 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
}
tsc = rdtsc();
*elapsed_nsec = scale_delta(tsc, &d->arch.vtsc_to_ns);
-*gtsc_khz = cpu_khz;
+*gtsc_khz = enable_tsc_scaling ? d->arch.tsc_khz : cpu_khz;
break;
case TSC_MODE_PVRDTSCP:
if ( d->arch.vtsc )
@@ -1779,10 +1782,13 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
}
else
{
+struct time_scale *scale = enable_tsc_scaling ?
+ &this_cpu(cpu_time).tsc_scale :
+ &d->arch.vtsc_to_ns;
IIUIC tsc_scale is host property and so why would it be used if TSC
scaling is available to guests?
-boris
tsc = rdtsc();
-*elapsed_nsec = scale_delta(tsc, &d->arch.vtsc_to_ns) -
+*elapsed_nsec = scale_delta(tsc, scale) -
d->arch.vtsc_offset;
-*gtsc_khz = 0; /* ignored by tsc_set_info */
+*gtsc_khz = enable_tsc_scaling ? d->arch.tsc_khz : 0;
}
break;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 65468: all pass - PUSHED
flight 65468 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65468/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 84c7452165816ed26cd5bdeb5666d4dc0026f116
baseline version:
ovmf 68312710615c3499341f3e300b0a3921dea5a39b
Last test of basis65386 2015-12-04 21:43:13 Z2 days
Testing same since65468 2015-12-07 08:14:46 Z0 days1 attempts
People who touched revisions under test:
Ard Biesheuvel
Baraneedharan Anbazhagan
Chao Zhang
Daocheng Bu
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=84c7452165816ed26cd5bdeb5666d4dc0026f116
+ . ./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 ovmf
84c7452165816ed26cd5bdeb5666d4dc0026f116
+ branch=ovmf
+ revision=84c7452165816ed26cd5bdeb5666d4dc0026f116
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x84c7452165816ed26cd5bdeb5666d4dc0026f116 = 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://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : 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-
[Xen-devel] [OSSTEST v2 PATCH 00/16] Test database handling
Ian Jackson writes (""):
> I'm intending to be able to do database schema updates. But I don't
> want to play around with such code on a live database. So I need a
> test database.
Sorry about the subject-less mail. Here is a followup with a Subject
to make this easier to find in the future.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 03/16] Configuration: No longer set password=<~/.xen-osstest/db-password>
Instead, expect the user to provide ~/.pgpass.
This is a good idea because we don't really want to be handling
passwords ourselves if we can help it. And, we are shortly going to
want to do some exciting mangling of the database access
configuration, which would be complicated by the presence of this
password expansion.
This may break for some users of existing Executive (non-standalone)
setups which are using production-config-cambridge or the default
built-in configuration.
DEPLOYMENT NOTE: After this passes the push gate in Cambridge,
/export/home/osstest/.{xen-,}osstest/db-password should be deleted to
avoid confusion in the future.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
Osstest.pm |3 +--
production-config-cambridge |2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Osstest.pm b/Osstest.pm
index ec50d60..95e4d46 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -191,8 +191,7 @@ sub readglobalconfig () {
# dynamic default config settings
$c{ExecutiveDbnamePat} ||= "dbname=;user=;".
- "host=.db.$c{DnsDomain};".
- "password=<~/.xen-osstest/db-password>"
+ "host=.db.$c{DnsDomain}"
if defined $c{DnsDomain};
# 1. <\w+> is replaced with variables:
# database name
diff --git a/production-config-cambridge b/production-config-cambridge
index f801303..412766c 100644
--- a/production-config-cambridge
+++ b/production-config-cambridge
@@ -23,7 +23,7 @@ HostDB_Executive_NoConfigDB 1
OwnerDaemonHost owner.daemon.osstest.xs.citrite.net
QueueDaemonHost queue.daemon.osstest.xs.citrite.net
-ExecutiveDbnamePat
dbname=;user=;host=osstestdb.xs.citrite.net;password=<~/.xen-osstest/db-password>
+ExecutiveDbnamePat dbname=;user=;host=osstestdb.xs.citrite.net
HostnameSortSwapWords 1
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 04/16] mg-debug-fail: New utility script for debugging
Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- v2: Use "egrep ''" rather than "egrep .". Both sanitise missing-final-newline but "egrep ''" will print blank lines, which is desirable here. --- mg-debug-fail | 13 + 1 file changed, 13 insertions(+) create mode 100755 mg-debug-fail diff --git a/mg-debug-fail b/mg-debug-fail new file mode 100755 index 000..a163aef --- /dev/null +++ b/mg-debug-fail @@ -0,0 +1,13 @@ +#!/bin/sh +# +# This script can be provided anywhere an executable or command name is +# wanted. It prints its arguments, and its stdin, to its stderr, and +# then exits nonzero. +# +# When using this it may be useful to provide &2 +exit 127 -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 16/16] mg-schema-test-database: Add workflow doc comment
Signed-off-by: Ian Jackson
---
v2: New patch
---
mg-schema-test-database | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/mg-schema-test-database b/mg-schema-test-database
index 90a361b..d704950 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -34,7 +34,42 @@
# NB that you can't drop a test database with these daemons running,
# because Postgres will refuse to drop a database that anyone is
# connected to.
-
+#
+#
+# Expected usage workflow:
+#
+# 1. Optionally, arrange for some hosts to be allocated to a suitable task
+#OSSTEST_TASK=iwj@testing ./mg-allocate [-U ...] a-host
+#
+# 2. Create the test DB using the script
+#./mg-schema-test-database create [_SUFFIX] iwj@testing
+#
+# 3. Using the `export OSSTEST_CONFIG=' line printed by the above,
+# play about in the test DB. `a-host' will be `idle' in the test DB:
+#OSSTEST_CONFIG=\
+#/u/iwj/.xen-osstest/config:local-config.test-database_iwj \
+# ./mg-allocate a-host
+#
+# 3a. Maybe run ./mg-schema-test-database daemons (if full-on queue
+# running is desired).
+#
+# 3b. Meanwhile from the point of view of other users of the main DB,
+# `a-host' is borrowed by a special task, but the rest of the main
+# DB and its hosts can carry on.
+#
+# 3c. When talking to the real database, while you have a test DB set
+# up, you have to set OSSTEST_DB_USEREAL_IGNORETEST eg
+#OSSTEST_DB_USEREAL_IGNORETEST=osstest_test_iwj ./sg-run-job etc. etc.
+# This is just to stop you operating on the real DB by mistake.
+#
+# 4. When you are done,
+#./mg-schema-test-database drop [_SUFFIX]
+# This will throw away all of the information in the test DB.
+#
+# 5. OSSTEST_TASK=iwj@testing ./mg-allocate !a-host
+# Hosts that were marked in the main DB as borrowed, are returned by
+# mg-schema-test-database to the main DB task that previously owned
+# them, but not freed. So you need to explicitly free them.
set -e -o posix ${OSSTEST_DEBUG:+-x}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 15/16] mg-schema-test-database: Safety catch in JobDB database open
When we open the `osstest' database, see whether this is a parent DB
(main DB) from which a test DB has been spawned by this user.
If it has, bomb out, unless the user has specified a suitable regexp
matching the DB name in the env var
OSSTEST_DB_USEREAL_IGNORETEST
This means that when a test database is in play, the user who created
it cannot accidentally operate on the real DB.
The safety catch does not affect Tcl programs, which get the DB config
directly, but in general that just means sg-execute-flight and
sg-run-job which already have a fair amount of safety catch because
they demand flight numbers.
mg-schema-test-database hits this feature over the head. We assume
that the caller of mg-schema-test-database knows what they are doing;
particularly, that if they create nested test DBs (!), they do not
need the assitance of this feature to stop themselves operating
mg-schema-test-database incorrectly. Anyone who creates nested test
DBs will hopefully recognise the potential for confusion!
Signed-off-by: Ian Jackson
---
Osstest/JobDB/Executive.pm | 33 -
mg-schema-test-database|2 ++
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index 2572f5f..29dbc6f 100644
--- a/Osstest/JobDB/Executive.pm
+++ b/Osstest/JobDB/Executive.pm
@@ -51,8 +51,39 @@ sub current_flight ($) { #method
return $ENV{'OSSTEST_FLIGHT'};
}
+sub _check_testdbs ($) {
+my ($dbh) = @_;
+
+my $re = $ENV{OSSTEST_DB_USEREAL_IGNORETEST} // '';
+return if $re eq '.*'; # needed by mg-schema-test-database during setup
+
+# mg-schema-test-database creates a task
+# xdbref/DBNAME with username ${Username}@
+my $sth = $dbh->prepare(fetchrow_hashref()) {
+ next if $row->{dbname} =~ m/^$re$/o;
+ $allok = 0;
+ print STDERR <{dbname} ($row->{username}, "$row->{comment}")
+END
+}
+die "Test dbs exist. Set OSSTEST_DB_USEREAL_IGNORETEST to regexp ?\n"
+ unless $allok;
+}
+
sub open ($) { #method
-return opendb('osstestdb');
+my $dbh = opendb('osstestdb');
+_check_testdbs($dbh);
+return $dbh;
}
sub dbfl_check ($$) { #method
diff --git a/mg-schema-test-database b/mg-schema-test-database
index b41a99b..90a361b 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -47,6 +47,8 @@ cmd="$1"; shift
localconfig=local-config.test-database
+export OSSTEST_DB_USEREAL_IGNORETEST='.*'
+
maindbname=$(perl -we '
use Osstest;
use Osstest::Executive;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 14/16] mg-schema-test-database: Bump flight sequence number in test DB
This makes test flights have different numbers to those currently in production, which will help avoid accidents. Signed-off-by: Ian Jackson --- v2: New patch --- mg-schema-test-database | 13 + 1 file changed, 13 insertions(+) diff --git a/mg-schema-test-database b/mg-schema-test-database index 78f26db..b41a99b 100755 --- a/mg-schema-test-database +++ b/mg-schema-test-database @@ -430,6 +430,19 @@ END rm -f $t.tabledata.* + printf "flightseq..." + + lastflight=$(psql_query
[Xen-devel] (no subject)
I'm intending to be able to do database schema updates. But I don't want to play around with such code on a live database. So I need a test database. Thus, a yak: arrangements to make a test database. As I say, I have tested this and it now does the right things in, apparently, the right order, and seems to leave things in a good state even when it collapses halfway or is ^C'd. In v2 I have addressed the comments, and added a couple of new safety catches. For ease of review these are mostly as followup patches to the mg-schema-test-database script, rather than folded in. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 01/16] tcl daemons: log host and port number we bind to, at startup
If the socket setup fails, this makes it easier to see what the
program was trying to do.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
tcl/daemonlib.tcl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tcl/daemonlib.tcl b/tcl/daemonlib.tcl
index 972b5e2..b76ff12 100644
--- a/tcl/daemonlib.tcl
+++ b/tcl/daemonlib.tcl
@@ -210,7 +210,7 @@ proc main-daemon {which setup} {
fconfigure stdout -buffering line
fconfigure stderr -buffering none
-log "starting"
+log "starting $host:$port"
uplevel 1 $setup
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 12/16] Configuration: Introduce $c{Username}
This makes it easier to share the output of whoami. As a beneficial
side effect it can now be overridden.
Replace many open-coded calls to `whoami` etc. with references to
$c{Username}.
Signed-off-by: Ian Jackson
---
v2: New patch
---
Osstest.pm |5 +++--
Osstest/Executive.pm| 15 ---
README |4
mg-crontab-install |2 +-
mg-execute-flight |2 +-
mg-schema-test-database |4 ++--
6 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/Osstest.pm b/Osstest.pm
index 20b8f62..d4ddda7 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -209,6 +209,7 @@ sub readglobalconfig () {
my $whoami = `whoami` or die $!;
chomp($whoami) or die;
+$c{Username} ||= $whoami;
my $nodename = `uname -n` or die $!;
chomp($nodename) or die;
@@ -219,7 +220,7 @@ sub readglobalconfig () {
$c{TftpPath} ||= "/tftpboot/";
$c{TftpPxeDir} ||= "pxelinux.cfg/";
$c{TftpPxeTemplates} ||= '%ipaddrhex% 01-%etherhyph%';
-$c{TftpPlayDir} ||= "$whoami/osstest/";
+$c{TftpPlayDir} ||= "$c{Username}/osstest/";
$c{TftpTmpDir} ||= "$c{TftpPlayDir}tmp/";
$c{TftpDiBase} ||= "$c{TftpPlayDir}debian-installer";
@@ -229,7 +230,7 @@ sub readglobalconfig () {
$c{TftpGrubVersion} ||= 'current';
$c{WebspaceFile} ||= "$ENV{'HOME'}/public_html/";
-$c{WebspaceUrl} ||= "http://$myfqdn/~$whoami/";;
+$c{WebspaceUrl} ||= "http://$myfqdn/~$c{Username}/";;
$c{WebspaceCommon} ||= 'osstest/';
$c{WebspaceLog} ||= '/var/log/apache2/access.log';
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 2214084..fcef83f 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -134,19 +134,14 @@ sub opendb_state () {
return opendb('statedb');
}
-our $whoami;
-
sub db_pg_dsn ($) {
my ($dbname) = @_;
my $pg= $c{"ExecutiveDbname_$dbname"};
if (!defined $pg) {
- if (!defined $whoami) {
- $whoami = `whoami`; die if $?; chomp $whoami;
- }
my $pat= $c{ExecutiveDbnamePat};
my %vars= ('dbname' => $dbname,
- 'whoami' => $whoami);
+ 'whoami' => $c{Username});
$pat =~ s#\<(\w+)\>#
my $val=$vars{$1}; defined $val or die "$pat $1 ?";
$val;
@@ -449,10 +444,9 @@ sub findtask () {
my $q;
my $what;
if (!defined $spec) {
-$!=0; $?=0; my $whoami= `whoami`; defined $whoami or die "$? $!";
$!=0; $?=0; my $node= `uname -n`; defined $node or die "$? $!";
-chomp($whoami); chomp($node); $node =~ s/\..*//;
-my $refkey= "$whoami\@$node";
+chomp($node); $node =~ s/\..*//;
+my $refkey= "$c{Username}\@$node";
$what= "static $refkey";
$q= $dbh_tests->prepare(/dev/null; tty`
diff --git a/mg-schema-test-database b/mg-schema-test-database
index 73d92f3..b1b5e60 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -174,7 +174,7 @@ borrowtaskid () {
"
}
-username=`whoami`
+username=`getconfig Username`
nodename=`uname -n`
suffix=_$username
invocation_now=`date +%s`
@@ -223,7 +223,7 @@ create)
moretasks error \
"WHERE type = 'static'
AND refkey = :'refkey'" \
- -v refkey="$(whoami)@$(uname -n)"
+ -v refkey="${username}@$(uname -n)"
fi
tasks_cond=${tasks// / OR T=}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 05/16] mg-debug-fail: Catch attempts to read from a tty
When stdin is a tty, do not try to dump it. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- mg-debug-fail |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mg-debug-fail b/mg-debug-fail index a163aef..47ad68a 100755 --- a/mg-debug-fail +++ b/mg-debug-fail @@ -3,10 +3,10 @@ # This script can be provided anywhere an executable or command name is # wanted. It prints its arguments, and its stdin, to its stderr, and # then exits nonzero. -# -# When using this it may be useful to provide /dev/null 2>&1; then + exec &2 -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 06/16] cri-getconfig: Provide get_psql_cmd and get_pgdump_cmd
This is for (non-standalone-mode) shell scripts which want to access
the postgresql database.
get_psql_command provides `-v ON_ERROR_STOP' because it is not the
default (!) and no sane caller would not want it.
No callers as yet.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
v2: Fix typo in comment.
---
cri-getconfig | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/cri-getconfig b/cri-getconfig
index ee1cc40..973f1c0 100644
--- a/cri-getconfig
+++ b/cri-getconfig
@@ -40,7 +40,38 @@ getrepos() {
echo $repos
}
-# Good grief, handling background proceesses from shell is a pain.
+get_psql_cmd () {
+ perl -we '
+ use Osstest;
+ use Osstest::Executive;
+ use DBI;
+ csreadconfig();
+ print "psql",
+" -d ", $dbh_tests->{pg_db},
+" -h ", $dbh_tests->{pg_host},
+" -p ", $dbh_tests->{pg_port},
+" -U ", $dbh_tests->{pg_user},
+" -v ON_ERROR_STOP=1\n"
+or die $!;
+'
+}
+
+get_pgdump_cmd () {
+ perl -we '
+ use Osstest;
+ use Osstest::Executive;
+ use DBI;
+ csreadconfig();
+ print "pg_dump",
+" -h ", $dbh_tests->{pg_host},
+" -p ", $dbh_tests->{pg_port},
+" -U ", $dbh_tests->{pg_user},
+" ",$dbh_tests->{pg_db}, "\n"
+or die $!;
+'
+}
+
+# Good grief, handling background processes from shell is a pain.
#
# For stupid historical reasons, background processes start with
# SIGINT (and QUIT) ignored (SuSv3 2.11). bash does not currently
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 10/16] mg-schema-test-database: Move setting of test_cfg_setting to dbname
This will makes it available to a wider subset of the script, which is
going to be important in a moment.
No functional change.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
mg-schema-test-database | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mg-schema-test-database b/mg-schema-test-database
index 1226761..a1eb49c 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -56,6 +56,12 @@ dbname () {
dbname="${maindbname}_test$suffix"
t="tmp/testdb$suffix"
tcfg=local-config.test-database$suffix
+
+ test_cfg_setting="$(perl -we '
+ use Osstest;
+ print globalconfigfiles() or die $!;
+ '):$tcfg"
+
}
psql_query_internal () {
@@ -254,12 +260,6 @@ END
'
mv -f $tcfg.tmp $tcfg
- # this makes `withtest' work
- test_cfg_setting="$(perl -we '
- use Osstest;
- print globalconfigfiles() or die $!;
- '):$tcfg"
-
# Extract the schema for reference
$(get_pgdump_cmd) -s -O -x >$t.schema
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 08/16] Osstest.pm: Break out and export globalconfigfiles
No functional change; no callers as yet.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
Osstest.pm |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Osstest.pm b/Osstest.pm
index 95e4d46..20b8f62 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -30,7 +30,7 @@ BEGIN {
@ISA = qw(Exporter);
@EXPORT = qw(
readglobalconfig %c $mjobdb $mhostdb
- augmentconfigdefaults
+ augmentconfigdefaults globalconfigfiles
csreadconfig
getmethod
postfork
@@ -124,6 +124,10 @@ sub getmethod {
return $r;
}
+sub globalconfigfiles () {
+ $ENV{'OSSTEST_CONFIG'} || "$ENV{'HOME'}/.xen-osstest/config";
+}
+
sub readglobalconfig () {
our $readglobalconfig_done;
return if $readglobalconfig_done;
@@ -135,7 +139,7 @@ sub readglobalconfig () {
$c{AuthorizedKeysFiles} = '';
$c{AuthorizedKeysAppend} = '';
-my $cfgfiles = $ENV{'OSSTEST_CONFIG'} ||
"$ENV{'HOME'}/.xen-osstest/config";
+my $cfgfiles = globalconfigfiles();
my $readcfg;
$readcfg = sub ($$) {
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 09/16] mg-schema-test-database: New script
This allows a user in non-standalone mode to make a whole new test
database, which is largely a clone of the original database.
The new db refers to the same resources (hosts), and more-or-less
safely borrows some of those hosts.
Currently we don't do anything about the queue and owner daemons.
This means that queue-daemon-based resource allocation is broken when
clients are pointed at the test db. But non-queue-based allocation
(eg, ./mg-allocate without -U) works, and the test db can be used for
db-related experiments and even support individual ts-* scripts (other
than ts-hosts-allocate of course).
Signed-off-by: Ian Jackson
---
v2: Do not set *Daemon{Host,Port} - move this chunk to a later patch
---
mg-schema-test-database | 452 +++
1 file changed, 452 insertions(+)
create mode 100755 mg-schema-test-database
diff --git a/mg-schema-test-database b/mg-schema-test-database
new file mode 100755
index 000..1226761
--- /dev/null
+++ b/mg-schema-test-database
@@ -0,0 +1,452 @@
+#!/bin/bash
+#
+# usages:
+#
+#
+# ./mg-schema-test-database create [_SUFFIX] [TASK...] \
+# [-fMINFLIGHT | -f-NUMFLIGHTS]
+#
+# does `drop' and then creates
+# - the databaseosstestdb_test_SUFFIX
+# - a file local-config.test-database_SUFFIX
+#
+# default for SUFFIX is your local username
+#
+# Resources owned in the main db by a task in the list of specified
+# TASKs become idle in the test copy. Others become allocated to
+# a specially-created `owned by someone in real db' task.
+#
+#
+# ./mg-schema-test-database drop [_SUFFIX]
+#
+# deletes your test database and removes the local-config file
+#
+#
+
+set -e -o posix ${OSSTEST_DEBUG:+-x}
+
+. ./cri-getconfig
+. ./mgi-common
+
+if [ $# -lt 1 ]; then fail "need operation"; fi
+
+cmd="$1"; shift
+
+localconfig=local-config.test-database
+
+maindbname=$(perl -we '
+ use Osstest;
+ use Osstest::Executive;
+ use DBI;
+ csreadconfig();
+ print $dbh_tests->{pg_db},"\n"
+or die $!;
+')
+
+parse_only_suffix () {
+ for arg in "$@"; do
+ case "$arg" in
+ _*) suffix="$arg" ;;
+ *) fail 'bad usage' ;;
+ esac
+ done
+}
+
+dbname () {
+ dbname="${maindbname}_test$suffix"
+ t="tmp/testdb$suffix"
+ tcfg=local-config.test-database$suffix
+}
+
+psql_query_internal () {
+ $(get_psql_cmd) -At -R' ' -f- "$@"
+}
+
+psql_query () {
+if [ x$OSSTEST_DEBUG != x ]; then
+ tee /dev/stderr | psql_query_internal "$@"
+ else
+ psql_query_internal "$@"
+ fi
+}
+
+psql_do_cmd () {
+ echo "$(get_psql_cmd) ${OSSTEST_DEBUG:+-e -a}"
+}
+
+psql_do () {
+ $(psql_do_cmd) -q -f- "$@"
+}
+
+moretasks () {
+ local ifnone="$1"; shift
+ local where="$1"; shift
+ local r
+ r=$(
+ psql_query "$@" <&2 "warning: $m"
+ ;;
+ *)
+ fail-bad-moretasks-ifnone-"$ifnone"
+ ;;
+ esac
+ fi
+
+ tasks+=" $r"
+}
+
+withtest () {
+ OSSTEST_CONFIG="$test_cfg_setting" "$@"
+}
+
+each_copy_table () {
+ local tab=$1; shift
+ local cond=$1; shift
+
+ p=$t.tabledata.$tab
+ rm -f $p
+
+ cat <>$t.export
+ \\COPY (SELECT * FROM $tab WHERE $cond) TO $p $copyhow
+END
+ cat <>$t.import
+ \\COPY $tab FROM $p $copyhow
+END
+}
+
+make_xdbref_task () {
+ local refkey=$1; shift
+ local comment=$1; shift
+ local refinfo=$1; shift
+ echo "
+ INSERT INTO tasks
+ (type, refkey, username, comment, live, refinfo)
+ VALUES ('xdbref','$refkey','$username@$nodename',
+ '$comment','t','$refinfo');
+ "
+}
+
+taskid () {
+ local type=$1; shift
+ local refkey=$1; shift
+ local xcond=$1
+ echo "(SELECT taskid FROM tasks WHERE
+ type='$type' AND refkey='$refkey' $xcond)"
+}
+borrowtaskid () {
+ local bt=$1
+ taskid xdbref $dbname "
+ AND live AND refinfo IS NOT NULL AND refinfo='$bt'
+ "
+}
+
+username=`whoami`
+nodename=`uname -n`
+suffix=_$username
+invocation_now=`date +%s`
+
+case "$cmd" in
+
+#== CREATE ==
+
+create)
+ #-- argument parsing --
+
+ tasks=''
+ minflight=-1000
+ for arg in "$@"; do
+ case "$arg" in
+ *@*)
+ moretasks warning \
+ "WHERE type = 'static'
+ AND refkey LIKE :'pattern'" \
+ -v pattern="${arg//\*/%}" \
+ ;;
+ *" "*" "*)
+ local rhs="${arg#* }"
+ moretasks error
[Xen-devel] [OSSTEST PATCH 02/16] cri-getconfig: Break out exec_resetting_sigint.
Move this oddity (and the associated comment) from
standalone-generate-dump-flight-runvars to cri-getconfig. We are
going to want it elsewhere.
We put this in cri-getconfig because that is the one library of
generic shell functions which everything includes. Perhaps this file
is misnamed.
No overall functional change.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
cri-getconfig | 30 ++
standalone-generate-dump-flight-runvars | 28 +---
2 files changed, 31 insertions(+), 27 deletions(-)
diff --git a/cri-getconfig b/cri-getconfig
index 0589bf0..ee1cc40 100644
--- a/cri-getconfig
+++ b/cri-getconfig
@@ -39,3 +39,33 @@ getrepos() {
fi
echo $repos
}
+
+# Good grief, handling background proceesses from shell is a pain.
+#
+# For stupid historical reasons, background processes start with
+# SIGINT (and QUIT) ignored (SuSv3 2.11). bash does not currently
+# offer a way to ask it not to do this; nor is there a reliable way to
+# put the SIGINT handling back to normal.
+#
+# "trap - INT" can be used to put the handling back in recent versions
+# of bash (eg Debian jessie), but earlier versions are buggy, so
+# we use perl.
+#
+# However, there is still a race: if the signal arrives just after the
+# fork, after the shell has (in the child) set it to to IGN, but
+# before Perl has put it back, the child might still escape.
+# There is no reasonable way to deal with this race. So the result
+# may still be slightly racy in the case that s-g-d-f-r is ^C'd right
+# after starting.
+#
+# Hopefully in the future we can fix this with something like
+# "shopt -s no_async_sig_ignore". See
+# https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00077.html
+#
+exec_resetting_sigint () {
+ exec perl -e '
+ $SIG{$_}=DFL foreach qw(INT QUIT HUP);
+ kill 1, $$ unless getppid=='$$';
+ exec @ARGV or die $!;
+ ' "$@"
+}
diff --git a/standalone-generate-dump-flight-runvars
b/standalone-generate-dump-flight-runvars
index e91026a..3b20c62 100755
--- a/standalone-generate-dump-flight-runvars
+++ b/standalone-generate-dump-flight-runvars
@@ -58,35 +58,9 @@ perbranch () {
flight=check_${branch//[-._]/_}
}
-# Good grief, handling background proceesses from shell is a pain.
-#
-# For stupid historical reasons, background processes start with
-# SIGINT (and QUIT) ignored (SuSv3 2.11). bash does not currently
-# offer a way to ask it not to do this; nor is there a reliable way to
-# put the SIGINT handling back to normal.
-#
-# "trap - INT" can be used to put the handling back in recent versions
-# of bash (eg Debian jessie), but earlier versions are buggy, so
-# we use perl.
-#
-# However, there is still a race: if the signal arrives just after the
-# fork, after the shell has (in the child) set it to to IGN, but
-# before Perl has put it back, the child might still escape.
-# There is no reasonable way to deal with this race. So the result
-# may still be slightly racy in the case that s-g-d-f-r is ^C'd right
-# after starting.
-#
-# Hopefully in the future we can fix this with something like
-# "shopt -s no_async_sig_ignore". See
-# https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00077.html
-
for branch in $@; do
perbranch
-perl -e '
-$SIG{$_}=DFL foreach qw(INT QUIT HUP);
- kill 1, $$ unless getppid=='$$';
- exec @ARGV or die $!;
-' \
+exec_resetting_sigint \
./standalone make-flight -f $flight $branch >$log 2>&1 &
procs+=" $branch=$!"
done
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 07/16] cri-getconfig: Provide debugging for get_psql_cmd
This allows us to execute only the first SQL
invocations. The first non-executed one is dumped, instead, by having
get_psql_command print a rune involving ./mg-debug-fail (which the
caller will then execute).
The locking makes things work roughly-correctly if get_psql_cmd is run
in multiple processes at once: it is not defined exactly which
invocations get which counter values, but they will all work properly
and get exactly one counter value each.
If set -x is in force, turn it off for get_psql_cmd: our perl rune is
uninteresting to see repeated ad infinitum in debugging output.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
cri-getconfig | 16
1 file changed, 16 insertions(+)
diff --git a/cri-getconfig b/cri-getconfig
index 973f1c0..7b75700 100644
--- a/cri-getconfig
+++ b/cri-getconfig
@@ -41,6 +41,22 @@ getrepos() {
}
get_psql_cmd () {
+ # To use this:
+ # on each test run, rm -f t.psql-counter
+ # and set OSSTEST_PSQL_ONLY_DO to an integer
+ if [ "x$OSSTEST_PSQL_ONLY_DO" != x ]; then
+ local f=t.psql-counter
+ psql_counter=$( with-lock-ex -w $f.lock bash -ec '
+ psql_counter=$(cat '$f' || echo 0)
+ echo $(( $psql_counter + 1 )) >'$f'.tmp
+ mv -f '$f'.tmp '$f'
+ echo $psql_counter' )
+ if ! [ $psql_counter -lt $OSSTEST_PSQL_ONLY_DO ]; then
+ printf './mg-debug-fail '
+ fi
+ fi
+
+ set +x
perl -we '
use Osstest;
use Osstest::Executive;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 13/16] mg-schema-test-database: Change username for back-to-main-db xref
The `username' of the xdbref task in the test db, referring to the
main db, is changed to `PARENT' (from `@').
Currently this is purely cosmetic, but it is going to be useful to
distinguish the two cases:
* This is a test DB and contains references to a parent
* This is a parent DB (probably the main DB) which contains
references to child test DBS.
Signed-off-by: Ian Jackson
---
v2: New patch
---
mg-schema-test-database |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/mg-schema-test-database b/mg-schema-test-database
index b1b5e60..78f26db 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -152,10 +152,11 @@ make_xdbref_task () {
local refkey=$1; shift
local comment=$1; shift
local refinfo=$1; shift
+ local taskusername=$1; shift
echo "
INSERT INTO tasks
(type, refkey, username, comment, live, refinfo)
- VALUES ('xdbref','$refkey','$username@$nodename',
+ VALUES ('xdbref','$refkey','$taskusername',
'$comment','t','$refinfo');
"
}
@@ -373,7 +374,8 @@ END
for task in $tasks; do
psql_do <>$t.import
[Xen-devel] [OSSTEST PATCH 11/16] mg-schema-test-database: Sort out daemons; provide `daemons' subcommand
We arrange for the test configuration to look for the daemons on a
different host and port, and we provide a convenient way to run such a
pair of daemons.
Signed-off-by: Ian Jackson
---
v2: Moved setting of *Daemon{Host,Port} to this patch (was
previously in `mg-schema-test-database: New script')
---
mg-schema-test-database | 63 ++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/mg-schema-test-database b/mg-schema-test-database
index a1eb49c..73d92f3 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -4,7 +4,8 @@
#
#
# ./mg-schema-test-database create [_SUFFIX] [TASK...] \
-# [-fMINFLIGHT | -f-NUMFLIGHTS]
+# [-fMINFLIGHT | -f-NUMFLIGHTS] \
+# [-hCTRL_DAEMONS_HOST] [-fOWNER_D_PORT[,QUEUE_D_PORT]]
#
# does `drop' and then creates
# - the databaseosstestdb_test_SUFFIX
@@ -16,12 +17,24 @@
# TASKs become idle in the test copy. Others become allocated to
# a specially-created `owned by someone in real db' task.
#
+# Default for CTRL_DAEMONS_HOST is localhost; if no port is supplied,
+# we use the corresponding production port + 2; if only one port is
+# supplied we use that and the next port number.
+#
#
# ./mg-schema-test-database drop [_SUFFIX]
#
# deletes your test database and removes the local-config file
#
#
+# ./mg-schema-test-database daemons [_SUFFIX]
+#
+# synchronously runs owner and queue daemons for your test database
+#
+# NB that you can't drop a test database with these daemons running,
+# because Postgres will refuse to drop a database that anyone is
+# connected to.
+
set -e -o posix ${OSSTEST_DEBUG:+-x}
@@ -114,6 +127,9 @@ END
}
withtest () {
+ if ! [ -e "$tcfg" ]; then
+ fail "test $dbname not set up ($tcfg does not exist)"
+ fi
OSSTEST_CONFIG="$test_cfg_setting" "$@"
}
@@ -194,6 +210,10 @@ create)
;;
-f*)minflight="${arg#-f}"
;;
+ -h*)ctrlhost="${arg#-h}"
+ ;;
+ -p*)ctrlports="${arg#-p}"
+ ;;
*) fail "bad arg to create"
;;
esac
@@ -224,6 +244,18 @@ END
;;
esac
+ if [ "x$ctrlhost" = x ]; then
+ ctrlhost=localhost
+ fi
+ case "$ctrlports" in
+ *,*);;
+ ?*) ctrlports+=,$(( $ctrlports + 1 )) ;;
+ '')
+ ctrlports=$(( $(getconfig OwnerDaemonPort) + 2)),$((
+ $(getconfig QueueDaemonPort) + 2))
+ ;;
+ esac
+
#-- preparation and data-gathering --
bad=$( psql_query <$tcfg.tmp -we '
@@ -258,6 +292,12 @@ END
"port=$dbh_tests->{pg_port}\n"
or die $!;
'
+ cat >>$tcfg.tmp
[Xen-devel] [PATCH OSSTEST] mg-hosts: document "power" command
Signed-off-by: Wei Liu --- mg-hosts | 7 +++ 1 file changed, 7 insertions(+) diff --git a/mg-hosts b/mg-hosts index a911099..0d02c56 100755 --- a/mg-hosts +++ b/mg-hosts @@ -24,6 +24,13 @@ # of osstest. Will use "sudo". The HOST(s) must be # allocated (via mg-allocate HOST). # +# ./mg-hosts power HOST ACTION +# Power cycles the host. Host must be allocated to the current +# user. Actions are: +#"0" or "on": power on +#"1" or "off" : power off +#"c" or "r" : reboot +# # ./mg-hosts create-like SOURCE-HOST NEW-HOST[,NEW-HOST...] # Create new host(s). This does NOT copy the # flags and properties (!) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 8/8] treewide: Remove newlines inside DEFINE_PER_CPU() macros
On 2015-12-07 18:04, Joe Perches wrote: > On Mon, 2015-12-07 at 17:53 +0100, Michal Marek wrote: >> On 2015-12-07 17:33, David Laight wrote: >>> From: Michal Marek Sent: 04 December 2015 15:26 Otherwise make tags can't parse them: ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern "\1" >>> ... >>> >>> Seems to me you need to fix ctags. >> >> I'm sure the maintainers of ctags and etags would accept patches to >> describe a custom context-free grammar via commandline options, but >> until then, let's continue using the regular expressions in tags.sh and >> remove newlines in macros that tags.sh is trying to expand. >> > > Do you have a list of the most common macros? In practice, it's only DEFINE_PER_CPU and its sibling DEFINE_PER_CPU_SHARED_ALIGNED, where we try to pick the second argument to the macro and the first argument can be lengthy. > Perhaps it'd be good to add exceptions to checkpatch > 80 column line rules for them. Your call. But this is a fairly rare occurrence -- 10 cases so far. Michal ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] fyi, Xen's EFI workarounds (/mapbs & efi=no-rs) on SuperMicro hardware; fixes solve 1/2 problems & SM responds that can't/won't fix their firmware
On 12/7/15 8:20 AM, Konrad Rzeszutek Wilk wrote: > On Mon, Dec 07, 2015 at 09:20:12AM -0500, Konrad Rzeszutek Wilk wrote: >> On Sat, Dec 05, 2015 at 12:54:56PM -0800, PGNet Dev wrote: >>> On 12/05/2015 11:44 AM, Konrad Rzeszutek Wilk wrote: > Two issues exist with the SuperMicro EFI > > (1) firmware EFI mis-mapping causing Xen PANIC on restart Can you try 'reboot=acpi' ? >>> ... > I.e., what combination of > > /mapbs > efi=no-rs > reboot=acpi > All? It should be on the Xen command line. >>> >>> with /mapbs on the EFI exec line, >>> >>> grep mapbs /boot/grub2/grub.cfg >>> chainloader $cmdpath/xen-4.6.0_04-398.efi xen-4.6.0_04-398.efi >>> config.1 >>> /mapbs >>> >>> and on the Xen Cmd Line, >>> >>> grep efi= /boot/efi/EFI/opensuse/xen-4.6.0_04-398.cfg >>> options= dom0_mem=3072M,max:3072M ... loglvl=all >>> guest_loglvl=all >>> efi=no-rs reboot=acpi >> >>> >>> not clear to me what effect, if any, the addition of 'reboot=acpi' and >>> '/mapbs' has, relative to just 'efi=no-rs' has. >> >> >> Are you by chance an lawyer? :-) >> >> Try without /mapbs, efi=nr-rs and with reboot=acpi. That should use EFI >> routines >> for everything (including reboot). Doing the 'reboot=acpi' will override >> the reboot routine to only use the ACPI method. >> >> Granted if you did 'efi=nr-rs' we bypass EFI altogether and use 'acpi' >> method. >> >> My theory was that if use some EFI routines it inits the firmware enough >> that ACPI reboot should work. But it may be that it is just not happy. >> >> There is an extra patch you can try to determine if the failure is >> due to us doing ExitBootServices and not using virtual addresses (which >> for example is the reason that under Lenovo it goes haywire). >> >> See attached patch (against staging). With that you would do: > > Now attached. >> >> xen.efi /noexitboot /mapbs >> >> And you can try without 'efi=no-rs'. >> >> However I am wondering - why are you using '/mapbs' ? What did it >> help? (The combination of 'efi=no-rs' means you are in effect not >> using _any_ EFI operations - so doing /mapbs is not needed). >> >> >> ___ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel Konrad, Can we land the /noexitboot (probably better to call it /noexitbs to match rs) into the tree? I have to have a very similar patch locally to bring up my machine and it would make sense that if you and I are seeing this problem then others are. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/14] Add VMX TSC scaling support
On 07/12/15 10:16, Haozhong Zhang wrote: > On 12/07/15 10:03, Egger, Christoph wrote: >> Did you consider nested virtualization? >> L1 hypervisor may have a different tsc scaling >> and L2 guest again may have a different tsc scale ratio. >> > Oh, I forgot this. I'll check the nested TSC scaling code (mostly > about nested SVM TSC ratio, because this patch series does not expose > VMX TSC scaling to L1 guest). > > BTW, are there any practical usage scenarios of nested TSC scaling? If > any, I may also need to consider adding nested virtualization support > to VMX TSC scaling. I would say that there are genuine uses for nested TSC scaling. An L1 hypervisor is going to want to scale for the same reasons as the L0 hypervisor. Having said that, if TSC scaling is correctly hidden from the L1 guests, I would advise against conflating the two issues together. i.e. getting nested TSC scaling working is not a prerequisite for accepting this series. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 8/8] treewide: Remove newlines inside DEFINE_PER_CPU() macros
On Mon, 2015-12-07 at 17:53 +0100, Michal Marek wrote: > On 2015-12-07 17:33, David Laight wrote: > > From: Michal Marek > > > Sent: 04 December 2015 15:26 > > > Otherwise make tags can't parse them: > > > > > > ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern > > > "\1" > > ... > > > > Seems to me you need to fix ctags. > > I'm sure the maintainers of ctags and etags would accept patches to > describe a custom context-free grammar via commandline options, but > until then, let's continue using the regular expressions in tags.sh and > remove newlines in macros that tags.sh is trying to expand. > Do you have a list of the most common macros? Perhaps it'd be good to add exceptions to checkpatch 80 column line rules for them. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 1/9] xen/x86: set the vPMU interface based on the presence of a lapic
>>> On 07.12.15 at 17:48, wrote: > --- > xen/arch/x86/cpu/vpmu.c | 11 ++- > xen/arch/x86/cpu/vpmu_amd.c | 6 +++--- > xen/arch/x86/cpu/vpmu_intel.c | 6 +++--- > xen/arch/x86/hvm/svm/svm.c| 2 +- > xen/arch/x86/hvm/vmx/vmx.c| 2 +- > 5 files changed, 14 insertions(+), 13 deletions(-) You should be Cc-ing the VMX maintainers, or this is likely to never get the necessary ack (even more so with the recent restoration of maintainership for xen/arch/x86/cpu/vpmu_intel.c). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 03/14] x86/time.c: Use correct guest TSC frequency in tsc_set_info()
On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
When TSC_MODE_PVRDTSCP is used for a HVM container and TSC scaling is
available, use the non-zero value of argument gtsc_khz of tsc_set_info()
as the guest TSC frequency rather than using the host TSC
frequency. Otherwise, TSC scaling will not be able get the correct ratio
between the host and guest TSC frequencies.
Signed-off-by: Haozhong Zhang
---
xen/arch/x86/time.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index b5223cf..1091e69 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1803,6 +1803,8 @@ void tsc_set_info(struct domain *d,
uint32_t tsc_mode, uint64_t elapsed_nsec,
uint32_t gtsc_khz, uint32_t incarnation)
{
+bool_t enable_tsc_scaling;
+
if ( is_idle_domain(d) || is_hardware_domain(d) )
{
d->arch.vtsc = 0;
@@ -1864,7 +1866,9 @@ void tsc_set_info(struct domain *d,
case TSC_MODE_PVRDTSCP:
d->arch.vtsc = !boot_cpu_has(X86_FEATURE_RDTSCP) ||
!host_tsc_is_safe();
-d->arch.tsc_khz = cpu_khz;
+enable_tsc_scaling = has_hvm_container_domain(d) &&
+ cpu_has_tsc_ratio && d->arch.vtsc;
+d->arch.tsc_khz = (enable_tsc_scaling && gtsc_khz) ? gtsc_khz :
cpu_khz;
set_time_scale(&d->arch.vtsc_to_ns, d->arch.tsc_khz * 1000 );
d->arch.ns_to_vtsc = scale_reciprocal(d->arch.vtsc_to_ns);
if ( d->arch.vtsc )
@@ -1872,7 +1876,10 @@ void tsc_set_info(struct domain *d,
else {
/* when using native TSC, offset is nsec relative to power-on
* of physical machine */
-d->arch.vtsc_offset = scale_delta(rdtsc(), &d->arch.vtsc_to_ns) -
+struct time_scale *scale = enable_tsc_scaling ?
Do we need this test here? Per previous chunk, enable_tsc_scaling will
be zero since d->arch.vtsc is false.
Actually, if you are trying to use (or, rather, account for) TSC
scaling, shouldn't it be !arch.vtsc there?
-boris
+ &this_cpu(cpu_time).tsc_scale :
+ &d->arch.vtsc_to_ns;
+d->arch.vtsc_offset = scale_delta(rdtsc(), scale) -
elapsed_nsec;
}
break;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 4/9] x86/hvm: loosen up the ASSERT in hvm_cr4_guest_reserved_bits and hvm_efer_valid
On 07/12/15 16:48, Roger Pau Monne wrote:
> Loosen up the condition so we make sure that the current vcpu belongs to the
> same domain.
>
> Signed-off-by: Roger Pau Monné
> Cc: Jan Beulich
> Cc: Andrew Cooper
The "v == current" is a genuine restriction on hvm_cpuid(), but only
matters for areas not probed by these two uses.
Reviewed-by: Andrew Cooper
Longterm, I will remove the restriction, but there is a substantial
quantity of work before that can happen.
> ---
> xen/arch/x86/hvm/hvm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index af3d4d7..92d57ff 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1842,7 +1842,7 @@ static const char * hvm_efer_valid(const struct vcpu
> *v, uint64_t value,
> {
> unsigned int level;
>
> -ASSERT(v == current);
> +ASSERT(v->domain == current->domain);
> hvm_cpuid(0x8000, &level, NULL, NULL, NULL);
> if ( level >= 0x8001 )
> {
> @@ -1912,7 +1912,7 @@ static unsigned long hvm_cr4_guest_reserved_bits(const
> struct vcpu *v,
> {
> unsigned int level;
>
> -ASSERT(v == current);
> +ASSERT(v->domain == current->domain);
> hvm_cpuid(0, &level, NULL, NULL, NULL);
> if ( level >= 1 )
> hvm_cpuid(1, NULL, NULL, &leaf1_ecx, &leaf1_edx);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 8/8] treewide: Remove newlines inside DEFINE_PER_CPU() macros
On 2015-12-07 17:33, David Laight wrote: > From: Michal Marek >> Sent: 04 December 2015 15:26 >> Otherwise make tags can't parse them: >> >> ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern >> "\1" > ... > > Seems to me you need to fix ctags. I'm sure the maintainers of ctags and etags would accept patches to describe a custom context-free grammar via commandline options, but until then, let's continue using the regular expressions in tags.sh and remove newlines in macros that tags.sh is trying to expand. Michal ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 02/14] x86/time.c: Fix domain type check in tsc_set_info()
On 12/06/2015 03:58 PM, Haozhong Zhang wrote: Replace is_hvm_domain() in tsc_set_info() by has_hvm_container_domain() to keep consistent with other domain type checks in tsc_set_info(). Signed-off-by: Haozhong Zhang Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v10 6/9] libxc/xen: introduce a start info structure for HVMlite guests
This structure contains the physical address of the command line, as well as
the physical address of the list of loaded modules. The physical address of
this structure is passed to the guest at boot time in the %ebx register.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Acked-by: Wei Liu
Acked-by: Jan Beulich
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v8:
- Slightly reword comment.
Changes since v7:
- Add a comment to clarify that nothing will be loaded at physical address
0.
- Add Andrew Cooper Reviewed-by.
- Add Wei Liu Ack.
Changes since v6:
- Add a check to make sure the start info data is placed below 4GB.
- Make sure byte addresses are treated as uintptr_t.
- Fix single-line comment.
Changes since v5:
- Change some of the calculations performed to get the total size of the
start_info region.
- Replace the mention of HVMlite in a comment with PVH.
- Don't use 64bit integers in hvm_modlist_entry.
---
tools/libxc/xc_dom_x86.c | 68 +++-
xen/include/public/xen.h | 23
2 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 1d4ad3e..d058949 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -633,7 +633,70 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
special_pfn(SPECIALPAGE_SHARING));
-if ( dom->device_model )
+if ( !dom->device_model )
+{
+struct xc_dom_seg seg;
+struct hvm_start_info *start_info;
+char *cmdline;
+struct hvm_modlist_entry *modlist;
+void *start_page;
+size_t cmdline_size = 0;
+size_t start_info_size = sizeof(*start_info);
+
+if ( dom->cmdline )
+{
+cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
+start_info_size += cmdline_size;
+
+}
+if ( dom->ramdisk_blob )
+start_info_size += sizeof(*modlist); /* Limited to one module. */
+
+rc = xc_dom_alloc_segment(dom, &seg, "HVMlite start info", 0,
+ start_info_size);
+if ( rc != 0 )
+{
+DOMPRINTF("Unable to reserve memory for the start info");
+goto out;
+}
+
+start_page = xc_map_foreign_range(xch, domid, start_info_size,
+ PROT_READ | PROT_WRITE,
+ seg.pfn);
+if ( start_page == NULL )
+{
+DOMPRINTF("Unable to map HVM start info page");
+goto error_out;
+}
+
+start_info = start_page;
+cmdline = start_page + sizeof(*start_info);
+modlist = start_page + sizeof(*start_info) + cmdline_size;
+
+if ( dom->cmdline )
+{
+strncpy(cmdline, dom->cmdline, MAX_GUEST_CMDLINE);
+cmdline[MAX_GUEST_CMDLINE - 1] = '\0';
+start_info->cmdline_paddr = (seg.pfn << PAGE_SHIFT) +
+((uintptr_t)cmdline - (uintptr_t)start_info);
+}
+
+if ( dom->ramdisk_blob )
+{
+modlist[0].paddr = dom->ramdisk_seg.vstart - dom->parms.virt_base;
+modlist[0].size = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
+start_info->modlist_paddr = (seg.pfn << PAGE_SHIFT) +
+((uintptr_t)modlist - (uintptr_t)start_info);
+start_info->nr_modules = 1;
+}
+
+start_info->magic = HVM_START_MAGIC_VALUE;
+
+munmap(start_page, start_info_size);
+
+dom->start_info_pfn = seg.pfn;
+}
+else
{
/*
* Allocate and clear additional ioreq server pages. The default
@@ -1032,6 +1095,9 @@ static int vcpu_hvm(struct xc_dom_image *dom)
/* Set the IP. */
bsp_ctx.cpu.rip = dom->parms.phys_entry;
+if ( dom->start_info_pfn )
+bsp_ctx.cpu.rbx = dom->start_info_pfn << PAGE_SHIFT;
+
/* Set the end descriptor. */
bsp_ctx.end_d.typecode = HVM_SAVE_CODE(END);
bsp_ctx.end_d.instance = 0;
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index ff5547e..7b629b1 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -784,6 +784,29 @@ struct start_info {
};
typedef struct start_info start_info_t;
+/*
+ * Start of day structure passed to PVH guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so
+ * a 0 value in any of the address fields should be treated
+ * as not present.
+ */
+struct hvm_start_info {
+#define HVM_START_MAGIC_VALUE 0x336ec578
+uint32_t magic; /* Contains the magic value 0x336ec578 */
+/* ("xEn3" with the 0x80 bit of the "E" set).*/
+uint32_t flags; /* SIF_x
[Xen-devel] [PATCH v10 5/9] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs
Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls from HVM
guests.
This patch introduces a new structure (vcpu_hvm_context) that should be used
in conjuction with the VCPUOP_initialise hypercall in order to initialize
vCPUs for HVM guests.
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Campbell
Cc: Stefano Stabellini
---
Changes since v9:
- s/arch_initialize_vcpu/arch_initialise_vcpu.
- s/default_initalize_vcpu/default_initialise_vcpu.
- Expanded the SEG macro in order to also de the sanity checking.
- Removed setting the .sel field in the 32bit macro.
- Removed setting the .sel and .base fields in the 64bit SEG macro.
- Fixed the calls to hvm_cr4_guest_reserved_bits and hvm_efer_valid in
order to perform the checking against the guest cpuid features.
- Moved the prototype of default_initialise_vcpu so it's after
arch_initialise_vcpu.
- Remove the HVM wrappers around vcpu_op, all vcpu ops are now available to
HVM guests.
Changes since v8:
- Create a generic default_initalize_vcpu function that can be shared with
x86 PV guests and ARM guests.
- Pass check_segment register by reference.
- Check that code/data segments always have the 'S' attribute bit set.
- Fix some of the checks done in check_segment.
- Fix indentation of gprintk calls.
- Remove failure messages in case the padding fields are not zero.
- Make hvm_efer_valid and hvm_cr4_guest_reserved_bits global and use them
to check the input values provided by the user.
- Only check the attribute field in order to figure out if a segment is
null.
- Make sure the TR segment is a system segment.
Changes since v7:
- Improved error messages.
- Set EFER.LMA if EFER.LME is set by the user.
- Fix calculation of CS limit.
- Add more checks to segment registers.
- Add checks to make sure padding fields are 0.
- Remove ugly arch ifdefs from common domain.c.
- Add the implicit padding of vcpu_hvm_x86_32 explicitly in the structure.
- Simplify the compat vcpu code since it's only used on x86.
Changes since v6:
- Add comments to clarify some initializations.
- Introduce a generic default_initialize_vcpu that's used to initialize a
ARM vCPU or a x86 PV vCPU.
- Move the undef of the SEG macro.
- Fix the size of the eflags register, it should be 32bits.
- Add a comment regarding the value of the 12-15 bits of the _ar fields.
- Remove the 16bit strucutre, the 32bit one can be used to start the cpu in
real mode.
- Add some sanity checks to the values passed in.
- Add paddings to vcpu_hvm_context so the layout on 32/64bits is the same.
- Add support for the compat version of VCPUOP_initialise.
Changes since v5:
- Fix a coding style issue.
- Merge the code from wip-dmlite-v5-refactor by Andrew in order to reduce
bloat.
- Print the offending %cr3 in case of error when using shadow.
- Reduce the scope of local variables in arch_initialize_vcpu.
- s/current->domain/v->domain/g in arch_initialize_vcpu.
- Expand the comment in public/vcpu.h to document the usage of
vcpu_hvm_context for HVM guests.
- Add myself as the copyright holder for the public hvm_vcpu.h header.
Changes since v4:
- Don't assume mode is 64B, add an explicit check.
- Don't set TF_kernel_mode, it is only needed for PV guests.
- Don't set CR0_ET unconditionally.
---
xen/arch/arm/domain.c | 5 +
xen/arch/x86/domain.c | 308 ++
xen/arch/x86/hvm/hvm.c| 61 +---
xen/common/compat/domain.c| 50 +--
xen/common/domain.c | 41 +++--
xen/include/Makefile | 1 +
xen/include/asm-x86/domain.h | 3 +
xen/include/asm-x86/hvm/hvm.h | 5 +
xen/include/public/hvm/hvm_vcpu.h | 144 ++
xen/include/public/vcpu.h | 6 +-
xen/include/xen/domain.h | 3 +
xen/include/xlat.lst | 3 +
12 files changed, 541 insertions(+), 89 deletions(-)
create mode 100644 xen/include/public/hvm/hvm_vcpu.h
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 860ac7d..3d274ae 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -756,6 +756,11 @@ int arch_set_info_guest(
return 0;
}
+int arch_initialise_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+return default_initialise_vcpu(v, arg);
+}
+
int arch_vcpu_reset(struct vcpu *v)
{
vcpu_end_shutdown_deferral(v);
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index df40dc6..ca5247d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1188,6 +1189,313 @@ int arch_set_info_guest(
#undef c
}
+static inline int check_segment(struct segment_register *reg,
+enum x86_segment seg)
+{
+
+if ( reg->att
[Xen-devel] [PATCH v10 8/9] libxl: allow the creation of HVM domains without a device model.
Replace the firmware loaded into HVM guests with an OS kernel. Since the HVM
builder now uses the PV xc_dom_* set of functions this kernel will be parsed
and loaded inside the guest like on PV, but the container is a pure HVM
guest.
Also, if device_model_version is set to none or a device model for the
specified domain is not present unconditinally set the nic type to
LIBXL_NIC_TYPE_VIF.
Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
Changes since v7:
- Add LIBXL_HAVE_DEVICE_MODEL_VERSION_NONE.
Changes since v5:
- Add Wei Liu Acked-by.
Changes since v4:
- Set dom->mmio_size to match the size of the special pages if there's no
device model for the guest. This implies moving NR_SPECIAL_PAGES and
X86_HVM_END_SPECIAL_REGION to a public header so they can be known by
libxl when creating the memory map.
- Reword the xl.cfg man page description of the "none" device model option.
- Use libxl__device_model_version_running instead of creating a new
function.
Changes since v3:
- Add explicit /* fall through */ comments.
- Expand libxl__device_nic_setdefault so that it sets the right nic type
for HVMlite guests.
- Remove stray space in hvm_build_set_params.
- Fix the error paths of libxl__domain_firmware.
---
docs/man/xl.cfg.pod.5| 5 +++
tools/libxc/include/xc_dom.h | 2 ++
tools/libxc/xc_dom_x86.c | 15 -
tools/libxl/libxl.c | 44 ++
tools/libxl/libxl.h | 8 +
tools/libxl/libxl_create.c | 16 +-
tools/libxl/libxl_dm.c | 3 +-
tools/libxl/libxl_dom.c | 74 ++--
tools/libxl/libxl_internal.h | 9 +-
tools/libxl/libxl_types.idl | 1 +
tools/libxl/libxl_x86.c | 15 ++---
tools/libxl/xl_cmdimpl.c | 2 ++
12 files changed, 144 insertions(+), 50 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 3b695bd..8899f75 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1789,6 +1789,11 @@ This device-model is the default for Linux dom0.
Use the device-model based upon the historical Xen fork of Qemu.
This device-model is still the default for NetBSD dom0.
+=item B
+
+Don't use any device model. This requires a kernel capable of booting
+without emulated devices.
+
=back
It is recommended to accept the default value for new guests. If
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index efa6c6e..2460818 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -20,6 +20,8 @@
#include
#define INVALID_PFN ((xen_pfn_t)-1)
+#define X86_HVM_NR_SPECIAL_PAGES8
+#define X86_HVM_END_SPECIAL_REGION 0xff000u
/* --- typedefs and structs */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index d058949..3960875 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -58,8 +58,8 @@
#define SPECIALPAGE_IOREQ5
#define SPECIALPAGE_IDENT_PT 6
#define SPECIALPAGE_CONSOLE 7
-#define NR_SPECIAL_PAGES 8
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+#define special_pfn(x) \
+(X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES + (x))
#define NR_IOREQ_SERVER_PAGES 8
#define ioreq_server_pfn(x) (special_pfn(0) - NR_IOREQ_SERVER_PAGES + (x))
@@ -589,7 +589,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
void *hvm_info_page;
uint32_t *ident_pt, domid = dom->guest_domid;
int rc;
-xen_pfn_t special_array[NR_SPECIAL_PAGES];
+xen_pfn_t special_array[X86_HVM_NR_SPECIAL_PAGES];
xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
xc_interface *xch = dom->xch;
@@ -604,18 +604,19 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
}
/* Allocate and clear special pages. */
-for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
+for ( i = 0; i < X86_HVM_NR_SPECIAL_PAGES; i++ )
special_array[i] = special_pfn(i);
-rc = xc_domain_populate_physmap_exact(xch, domid, NR_SPECIAL_PAGES, 0, 0,
- special_array);
+rc = xc_domain_populate_physmap_exact(xch, domid, X86_HVM_NR_SPECIAL_PAGES,
+ 0, 0, special_array);
if ( rc != 0 )
{
DOMPRINTF("Could not allocate special pages.");
goto error_out;
}
-if ( xc_clear_domain_pages(xch, domid, special_pfn(0), NR_SPECIAL_PAGES) )
+if ( xc_clear_domain_pages(xch, domid, special_pfn(0),
+ X86_HVM_NR_SPECIAL_PAGES) )
goto error_out;
xc_hvm_param_set(xch, domid, HVM_PARAM_STORE_PFN,
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bd3aac8..db4f4e2 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1065,11 +1065,14 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
}
[Xen-devel] [PATCH v10 4/9] x86/hvm: loosen up the ASSERT in hvm_cr4_guest_reserved_bits and hvm_efer_valid
Loosen up the condition so we make sure that the current vcpu belongs to the
same domain.
Signed-off-by: Roger Pau Monné
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index af3d4d7..92d57ff 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1842,7 +1842,7 @@ static const char * hvm_efer_valid(const struct vcpu *v,
uint64_t value,
{
unsigned int level;
-ASSERT(v == current);
+ASSERT(v->domain == current->domain);
hvm_cpuid(0x8000, &level, NULL, NULL, NULL);
if ( level >= 0x8001 )
{
@@ -1912,7 +1912,7 @@ static unsigned long hvm_cr4_guest_reserved_bits(const
struct vcpu *v,
{
unsigned int level;
-ASSERT(v == current);
+ASSERT(v->domain == current->domain);
hvm_cpuid(0, &level, NULL, NULL, NULL);
if ( level >= 1 )
hvm_cpuid(1, NULL, NULL, &leaf1_ecx, &leaf1_edx);
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v10 2/9] xen/x86: allow disabling all emulated devices inside of Xen
Only allow enabling or disabling all the emulated devices inside of Xen,
right now Xen doesn't support enabling specific emulated devices only.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v7:
- Rework if condition.
Changes since v5:
- Add Andrew Cooper Reviewed-by.
---
xen/arch/x86/domain.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 2a8d5c1..df40dc6 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -532,8 +532,8 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
d->domain_id, config->emulation_flags);
return -EINVAL;
}
-if ( is_hvm_domain(d) ? (config->emulation_flags != XEN_X86_EMU_ALL)
- : (config->emulation_flags != 0) )
+if ( config->emulation_flags != 0 &&
+ (!is_hvm_domain(d) || config->emulation_flags != XEN_X86_EMU_ALL)
)
{
printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
"with the current selection of emulators: %#x\n",
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v10 1/9] xen/x86: set the vPMU interface based on the presence of a lapic
Instead of choosing the interface to expose to guests based on the guest
type, do it based on whether the guest has an emulated local apic or not.
Signed-off-by: Roger Pau Monné
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v8:
- Don't add the xenpmu hypercalls to the HVM hypercall table (yet).
- Add Jan Beulich Acked-by.
Changes since v7:
- Merge vpmu work from Boris.
Changes since v6:
- Major rework of the approach.
- Drop Andrew Cooper Acked-by.
Changes since v4:
- Add Andrew Cooper Acked-by.
---
xen/arch/x86/cpu/vpmu.c | 11 ++-
xen/arch/x86/cpu/vpmu_amd.c | 6 +++---
xen/arch/x86/cpu/vpmu_intel.c | 6 +++---
xen/arch/x86/hvm/svm/svm.c| 2 +-
xen/arch/x86/hvm/vmx/vmx.c| 2 +-
5 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index d870dcc..4856e98 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -94,7 +94,7 @@ void vpmu_lvtpc_update(uint32_t val)
vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
/* Postpone APIC updates for PV(H) guests if PMU interrupt is pending */
-if ( is_hvm_vcpu(curr) || !vpmu->xenpmu_data ||
+if ( has_vlapic(curr->domain) || !vpmu->xenpmu_data ||
!vpmu_is_set(vpmu, VPMU_CACHED) )
apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
}
@@ -129,7 +129,7 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
* and since do_wr/rdmsr may load VPMU context we should save
* (and unload) it again.
*/
-if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+if ( !has_vlapic(curr->domain) && vpmu->xenpmu_data &&
vpmu_is_set(vpmu, VPMU_CACHED) )
{
vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
@@ -184,7 +184,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
return;
/* PV(H) guest */
-if ( !is_hvm_vcpu(sampling) || (vpmu_mode & XENPMU_MODE_ALL) )
+if ( !has_vlapic(sampling->domain) || (vpmu_mode & XENPMU_MODE_ALL) )
{
const struct cpu_user_regs *cur_regs;
uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
@@ -411,7 +411,8 @@ int vpmu_load(struct vcpu *v, bool_t from_guest)
/* Only when PMU is counting, we load PMU context immediately. */
if ( !vpmu_is_set(vpmu, VPMU_RUNNING) ||
- (!is_hvm_vcpu(vpmu_vcpu(vpmu)) && vpmu_is_set(vpmu, VPMU_CACHED)) )
+ (!has_vlapic(vpmu_vcpu(vpmu)->domain) &&
+ vpmu_is_set(vpmu, VPMU_CACHED)) )
return 0;
if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
@@ -637,7 +638,7 @@ long do_xenpmu_op(unsigned int op,
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
struct xen_pmu_data *xenpmu_data;
struct vpmu_struct *vpmu;
-if ( !opt_vpmu_enabled )
+if ( !opt_vpmu_enabled || has_vlapic(current->domain) )
return -EOPNOTSUPP;
ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index 04da81a..990e6f3 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -238,7 +238,7 @@ static int amd_vpmu_load(struct vcpu *v, bool_t from_guest)
bool_t is_running = 0;
struct xen_pmu_amd_ctxt *guest_ctxt = &vpmu->xenpmu_data->pmu.c.amd;
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
ctxt = vpmu->context;
ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
@@ -314,7 +314,7 @@ static int amd_vpmu_save(struct vcpu *v, bool_t to_guest)
{
struct xen_pmu_amd_ctxt *guest_ctxt, *ctxt;
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
ctxt = vpmu->context;
guest_ctxt = &vpmu->xenpmu_data->pmu.c.amd;
memcpy(&guest_ctxt->regs[0], &ctxt->regs[0], regs_sz);
@@ -525,7 +525,7 @@ int svm_vpmu_initialise(struct vcpu *v)
vpmu->context = ctxt;
vpmu->priv_context = NULL;
-if ( !is_hvm_vcpu(v) )
+if ( !has_vlapic(v->domain) )
{
/* Copy register offsets to shared area */
ASSERT(vpmu->xenpmu_data);
diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index d5ea7fe..d5fde80 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -336,7 +336,7 @@ static int core2_vpmu_save(struct vcpu *v, bool_t to_guest)
if ( to_guest )
{
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
memcpy((void *)(&vpmu->xenpmu_data->pmu.c.intel) + regs_off,
vpmu->context + regs_off, regs_sz);
}
@@ -441,7 +441,7 @@ static int core2_vpmu_load(struct vcpu *v, bool_t
from_guest)
{
int ret;
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
memcpy(vpmu->context + regs_off,
(void *)&v->arch.vpmu.xenpmu_data->pmu.c.intel + regs_off,
@@ -501,7 +501,7 @@ static int core2_vpmu_alloc_resource
[Xen-devel] [PATCH v10 7/9] libxc: switch xc_dom_elfloader to be used with HVMlite domains
Allow xc_dom_elfloader to report a guest type as hvm-3.0-x86_32 if it's
running inside of a HVM container and has the PHYS32_ENTRY elfnote set.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
Only xc_dom_elfloader has been switched to support HVMlite, other loaders
should also be switched once we have a HVMlite compatible kernel that uses
them.
---
Changes since v5:
- Add Wei Liu Ack.
Changes since v4:
- Add Andrew Cooper Reviewed-by.
---
tools/libxc/xc_dom_elfloader.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 36a115e..2ae575e 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -56,6 +56,10 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
{
uint64_t machine = elf_uval(elf, elf->ehdr, e_machine);
+if ( dom->container_type == XC_DOM_HVM_CONTAINER &&
+ dom->parms.phys_entry != UNSET_ADDR )
+return "hvm-3.0-x86_32";
+
switch ( machine )
{
case EM_386:
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 01/14] svm: Fix incorrect TSC scaling
On 12/06/2015 03:58 PM, Haozhong Zhang wrote: SVM TSC ratio is incorrectly used in the current svm_get_tsc_offset(). This patch replaces the scaling logic in svm_get_tsc_offset() with a correct implementation. Signed-off-by: Haozhong Zhang Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v10 3/9] libxc: allow creating domains without emulated devices.
Introduce a new flag in xc_dom_image that turns on and off the emulated
devices. This prevents creating the VGA hole, the hvm_info page and the
ioreq server pages. libxl unconditionally sets it to true for all HVM
domains at the moment.
Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
Reviewed-by: Andrew Cooper
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
Changes since v5:
- Add Andrew Cooper Reviewed-by.
Changes since v4:
- Store the size of the VGA hole inside of the xc_dom_image struct and set
it from libxl.
- Rename dom->emulation to dom->device_model (no functional change).
- Add Wei Liu Acked-by.
Changes since v3:
- Explain the meaning of the "emulation" xc_dom_image field.
---
tools/libxc/include/xc_dom.h | 4 +++
tools/libxc/xc_dom_x86.c | 73
tools/libxl/libxl_dom.c | 2 ++
tools/libxl/libxl_internal.h | 1 +
4 files changed, 47 insertions(+), 33 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 3c94b57..efa6c6e 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -200,6 +200,10 @@ struct xc_dom_image {
xen_paddr_t mmio_size;
xen_paddr_t lowmem_end;
xen_paddr_t highmem_end;
+xen_pfn_t vga_hole_size;
+
+/* If unset disables the setup of the IOREQ pages. */
+bool device_model;
/* Extra ACPI tables passed to HVMLOADER */
struct xc_hvm_firmware_module acpi_module;
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 71b042e..1d4ad3e 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -50,8 +50,6 @@
#define X86_CR0_PE 0x01
#define X86_CR0_ET 0x10
-#define VGA_HOLE_SIZE (0x20)
-
#define SPECIALPAGE_PAGING 0
#define SPECIALPAGE_ACCESS 1
#define SPECIALPAGE_SHARING 2
@@ -595,12 +593,15 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
xc_interface *xch = dom->xch;
-if ( (hvm_info_page = xc_map_foreign_range(
- xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
- HVM_INFO_PFN)) == NULL )
-goto error_out;
-build_hvm_info(hvm_info_page, dom);
-munmap(hvm_info_page, PAGE_SIZE);
+if ( dom->device_model )
+{
+if ( (hvm_info_page = xc_map_foreign_range(
+ xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
+ HVM_INFO_PFN)) == NULL )
+goto error_out;
+build_hvm_info(hvm_info_page, dom);
+munmap(hvm_info_page, PAGE_SIZE);
+}
/* Allocate and clear special pages. */
for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
@@ -632,30 +633,33 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
special_pfn(SPECIALPAGE_SHARING));
-/*
- * Allocate and clear additional ioreq server pages. The default
- * server will use the IOREQ and BUFIOREQ special pages above.
- */
-for ( i = 0; i < NR_IOREQ_SERVER_PAGES; i++ )
-ioreq_server_array[i] = ioreq_server_pfn(i);
-
-rc = xc_domain_populate_physmap_exact(xch, domid, NR_IOREQ_SERVER_PAGES, 0,
- 0, ioreq_server_array);
-if ( rc != 0 )
+if ( dom->device_model )
{
-DOMPRINTF("Could not allocate ioreq server pages.");
-goto error_out;
-}
+/*
+ * Allocate and clear additional ioreq server pages. The default
+ * server will use the IOREQ and BUFIOREQ special pages above.
+ */
+for ( i = 0; i < NR_IOREQ_SERVER_PAGES; i++ )
+ioreq_server_array[i] = ioreq_server_pfn(i);
-if ( xc_clear_domain_pages(xch, domid, ioreq_server_pfn(0),
- NR_IOREQ_SERVER_PAGES) )
+rc = xc_domain_populate_physmap_exact(xch, domid,
NR_IOREQ_SERVER_PAGES, 0,
+ 0, ioreq_server_array);
+if ( rc != 0 )
+{
+DOMPRINTF("Could not allocate ioreq server pages.");
goto error_out;
+}
-/* Tell the domain where the pages are and how many there are */
-xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_SERVER_PFN,
- ioreq_server_pfn(0));
-xc_hvm_param_set(xch, domid, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
- NR_IOREQ_SERVER_PAGES);
+if ( xc_clear_domain_pages(xch, domid, ioreq_server_pfn(0),
+ NR_IOREQ_SERVER_PAGES) )
+goto error_out;
+
+/* Tell the domain where the pages are and how many there are */
+xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_SERVER_PFN,
+ ioreq_server_pfn(0));
+xc_hvm_param_set(xch, domid, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+ NR_IOREQ_SERVER_PAGES);
+}
/*
* Identity-map page table is require
[Xen-devel] [linux-linus test] 65459: regressions - FAIL
flight 65459 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/65459/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-freebsd10-i386 6 xen-bootfail REGR. vs. 59254 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-rumpuserxen-i386 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 59254 test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254 test-amd64-i386-pair 9 xen-boot/src_host fail REGR. vs. 59254 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-libvirt 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-raw6 xen-bootfail baseline untested test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-armhf-armhf-xl-vhd 6 xen-bootfail baseline untested test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail baseline untested test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail baseline untested test-amd64-amd64-libvirt-vhd 9 debian-di-install fail baseline untested test-armhf-armhf-libvirt-raw 6 xen-bootfail baseline untested test-armhf-armhf-libvirt-qcow2 6 xen-boot fail baseline untested test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 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 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: linux527e9316f8ec44bd53d90fb9f611fa752bb9 baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 151 days Failing since 59348 2015-07-10 04:24:05 Z 150 days 102 attempts Testing same since65459 2015-12-07 04:22:08 Z0 days1 attempts 3356 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm
[Xen-devel] [PATCH v10 0/9] Introduce HVM without dm and new boot ABI
This are the remaining patches of the HVMlite series. They have been successfully tested on the following hardware: - Intel Core i3-5010U. - AMD Opteron 4184. With both hap=0 and hap=1 in the configuration file. I've been able to boot a SMP guest in this mode with a virtual hard drive and a virtual network card, all working fine AFAICT. Migration/save/restore has also been tested with a SMP guest using the FreeBSD kernel provided below. The series has been compile tested on arm32. The series can also be found in the following git repo: git://xenbits.xen.org/people/royger/xen.git branch hvm_without_dm_v10 And for the FreeBSD part: git://xenbits.xen.org/people/royger/freebsd.git branch new_entry_point_v5 In case someone wants to give it a try, I've uploaded a FreeBSD kernel that should work when booted into this mode: https://people.freebsd.org/~royger/kernel_no_dm This FreeBSD kernel starts the APs in long mode. There are examples for starting the APs in other modes in the sys/x86/xen/pv.c file. The config file that I've used is: kernel="/path/to/kernel_no_dm" builder="hvm" device_model_version="none" memory=128 vcpus=2 name = "freebsd" Of course if you have a FreeBSD disk already setup it can also be added to the configuration file, and the following line can be used to point FreeBSD to the disk: extra="vfs.root.mountfrom=ufs:/dev/ufsid/" As usual, each patch has it's own changelog. J xen/x86: set the vPMU interface based on the presence A xen/x86: allow disabling all emulated devices inside AWlibxc: allow creating domains without emulated N x86/hvm: loosen up the ASSERT in hvm_cr4_guest_reserved_bits M xen/x86: allow HVM guests to use hypercalls to bring AWJ libxc/xen: introduce a start info structure for AWlibxc: switch xc_dom_elfloader to be used with HVMlite Wlibxl: allow the creation of HVM domains without a AW M libxl: add support for migrating HVM guests without a A = Acked/Reviewed by Andrew Cooper. W = Acked/Reviewed by Wei Liu. J = Acked/Reviewed by Jan Beulich. M = Modified in this version. N = New in this version. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v10 9/9] libxl: add support for migrating HVM guests without a device model
Only some minor libxl changes are needed in order to be able to migrate HVM
guests without a device model, no hypervisor changes are needed.
This change prevents sending the emulator context if the device model
version is set to none.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
Changes since v9:
- Use the correct type to store the device model version.
- Initialize device_model_version in libxl__stream_write_init.
- Add Andrew Reviewed-by and Wei Acked-by.
Changes since v8:
- Cache device model version inside of the libxl__stream_write_state
structure.
- Add a seatbelt by setting the emulator id to UNKNOWN in the HVMlite case.
This can be used to assert we don't reach certain paths.
- Remove stray STATE_AO_GC in emulator_xenstore_record_done.
Changes since v7:
- Prevent sending the emulator context and xenstore record in
write_emulator_context_record and write_emulator_xenstore_record.
- Error out if an emulator record is received for a no-dm guest.
---
tools/libxl/libxl_dom.c | 3 +++
tools/libxl/libxl_dom_suspend.c | 2 ++
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_stream_read.c | 16
tools/libxl/libxl_stream_write.c | 21 -
5 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 0f166e9..e730912 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1318,6 +1318,9 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
break;
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+break;
default:
LOG(ERROR,"logdirty switch failed"
", no valid device model version found, abandoning suspend");
diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 4cc01ad..3313ad1 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -43,6 +43,8 @@ int libxl__domain_suspend_device_model(libxl__gc *gc,
if (ret)
unlink(filename);
break;
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+break;
default:
return ERROR_INVAL;
}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c8402de..7ec2eb3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3037,6 +3037,9 @@ struct libxl__stream_write_state {
libxl__datacopier_state dc;
sws_record_done_cb record_done_callback;
+/* Cache device model version. */
+libxl_device_model_version device_model_version;
+
/* Only used when constructing EMULATOR records. */
libxl__datacopier_state emu_dc;
libxl__carefd *emu_carefd;
diff --git a/tools/libxl/libxl_stream_read.c b/tools/libxl/libxl_stream_read.c
index 4ec29da..258dec4 100644
--- a/tools/libxl/libxl_stream_read.c
+++ b/tools/libxl/libxl_stream_read.c
@@ -539,6 +539,14 @@ static bool process_record(libxl__egc *egc,
break;
case REC_TYPE_EMULATOR_XENSTORE_DATA:
+if (dcs->guest_config->b_info.device_model_version ==
+LIBXL_DEVICE_MODEL_VERSION_NONE) {
+rc = ERROR_FAIL;
+LOG(ERROR,
+"Received a xenstore emulator record when none was expected");
+goto err;
+}
+
if (rec->hdr.length < sizeof(libxl__sr_emulator_hdr)) {
rc = ERROR_FAIL;
LOG(ERROR,
@@ -560,6 +568,14 @@ static bool process_record(libxl__egc *egc,
break;
case REC_TYPE_EMULATOR_CONTEXT:
+if (dcs->guest_config->b_info.device_model_version ==
+LIBXL_DEVICE_MODEL_VERSION_NONE) {
+rc = ERROR_FAIL;
+LOG(ERROR,
+"Received an emulator context record when none was expected");
+goto err;
+}
+
write_emulator_blob(egc, stream, rec);
break;
diff --git a/tools/libxl/libxl_stream_write.c b/tools/libxl/libxl_stream_write.c
index 52a60d7..80d9208 100644
--- a/tools/libxl/libxl_stream_write.c
+++ b/tools/libxl/libxl_stream_write.c
@@ -167,6 +167,8 @@ static void setup_emulator_write(libxl__egc *egc,
void *body,
sws_record_done_cb cb)
{
+assert(stream->emu_sub_hdr.id != EMULATOR_UNKNOWN);
+assert(stream->device_model_version != LIBXL_DEVICE_MODEL_VERSION_NONE);
setup_generic_write(egc, stream, what, hdr, emu_hdr, body, cb);
}
@@ -207,6 +209,7 @@ void libxl__stream_write_init(libxl__stream_write_state
*stream)
FILLZERO(stream->emu_rec_hdr);
FILLZERO(stream->emu_sub_hdr);
stream->emu_body = NULL;
+stream->device_model_version = LIBXL_DEVICE_MODEL_VERSION_UNKNOWN;
}
void libxl__stream_
Re: [Xen-devel] [xen-unstable test] 65141: regressions - FAIL
>>> On 07.12.15 at 17:28, wrote: > One approach to fixing might be to disentangle the various things which > this patch did, such that the actual culprit is a smaller thing to analyse. Yes, if we're going to revert, I'll try to do something in that direction. I don't expect there to be too much room for splitting though. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] xen/MSI-X: latch MSI-X table writes
>>> On 07.12.15 at 13:41, wrote: > I know that in your opinion is superfluous, nonetheless could you please > add 2-3 lines of in-code comment right here, to explain what you are > doing with the check? Something like: > > /* > * Update the entry addr and data to the latest values only when the > * entry is masked or they are all masked, as required by the spec. > * Addr and data changes while the MSI-X entry is unmasked will be > * delayed until the next masking->unmasking. > */ Btw, will it be okay to just resend this one patch as v3, or do I need to resend the whole series (the rest of which didn't change)? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [FOR 1.3.0 PATCH] conf: add net device prefix for Xen
In commit d2e5538b1, the libxl driver was changed to copy interface
names autogenerated by libxl to the corresponding network def in the
domain's virDomainDef object. The copied name is freed when the domain
transitions to the shutoff state. But when migrating a domain, the
autogenerated name is included in the XML sent to the destination host.
It is possible an interface with the same name already exists on the
destination host, causing migration to fail. Indeed the Xen project's
OSSTEST CI already encountered such a failure.
This patch defines another VIR_NET_GENERATED_PREFIX for Xen, allowing
the autogenerated names to be excluded when parsing and formatting
inactive config.
Signed-off-by: Jim Fehlig
---
This is an alternative approach to Joao's fix for this regression
https://www.redhat.com/archives/libvir-list/2015-December/msg00197.html
I think it is the same approach used by the qemu driver. My only
reservation is that it expands the potential for clashes with
user-defined names. I.e. with this change both 'vnet' and 'vif' are
reserved prefixes.
src/conf/domain_conf.c | 6 --
src/conf/domain_conf.h | 4
src/libxl/libxl_domain.c | 5 +++--
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 2f5c0ed..debcf4e 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -8428,7 +8428,8 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt,
ifname = virXMLPropString(cur, "dev");
if (ifname &&
(flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) &&
-STRPREFIX(ifname, VIR_NET_GENERATED_PREFIX)) {
+(STRPREFIX(ifname, VIR_NET_GENERATED_PREFIX) ||
+ STRPREFIX(ifname, VIR_NET_GENERATED_PREFIX_XEN))) {
/* An auto-generated target name, blank it out */
VIR_FREE(ifname);
}
@@ -19790,7 +19791,8 @@ virDomainNetDefFormat(virBufferPtr buf,
virBufferEscapeString(buf, "\n",
def->domain_name);
if (def->ifname &&
!((flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE) &&
- (STRPREFIX(def->ifname, VIR_NET_GENERATED_PREFIX {
+ (STRPREFIX(def->ifname, VIR_NET_GENERATED_PREFIX) ||
+ STRPREFIX(def->ifname, VIR_NET_GENERATED_PREFIX_XEN {
/* Skip auto-generated target names for inactive config. */
virBufferEscapeString(buf, "\n", def->ifname);
}
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 90d8e13..d2cc26f 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1085,6 +1085,10 @@ struct _virDomainNetDef {
* by libvirt, and cannot be used for a persistent network name. */
# define VIR_NET_GENERATED_PREFIX "vnet"
+/* Used for prefix of ifname of any network name generated dynamically
+ * by libvirt for Xen, and cannot be used for a persistent network name. */
+# define VIR_NET_GENERATED_PREFIX_XEN "vif"
+
typedef enum {
VIR_DOMAIN_CHR_DEVICE_STATE_DEFAULT = 0,
VIR_DOMAIN_CHR_DEVICE_STATE_CONNECTED,
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index ef92974..c5d84a4 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -734,7 +734,7 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
for (i = 0; i < vm->def->nnets; i++) {
virDomainNetDefPtr net = vm->def->nets[i];
-if (STRPREFIX(net->ifname, "vif"))
+if (STRPREFIX(net->ifname, VIR_NET_GENERATED_PREFIX_XEN))
VIR_FREE(net->ifname);
}
}
@@ -918,7 +918,8 @@ libxlDomainCreateIfaceNames(virDomainDefPtr def,
libxl_domain_config *d_config)
if (net->ifname)
continue;
-ignore_value(virAsprintf(&net->ifname, "vif%d.%d%s",
+ignore_value(virAsprintf(&net->ifname,
+ VIR_NET_GENERATED_PREFIX_XEN "%d.%d%s",
def->id, x_nic->devid, suffix));
}
}
--
2.6.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 8/8] treewide: Remove newlines inside DEFINE_PER_CPU() macros
From: Michal Marek > Sent: 04 December 2015 15:26 > Otherwise make tags can't parse them: > > ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern "\1" ... Seems to me you need to fix ctags. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 65141: regressions - FAIL
On Mon, 2015-12-07 at 09:18 -0700, Jan Beulich wrote: > > > > On 05.12.15 at 09:09, wrote: > > On Wed, 2015-12-02 at 13:51 +, Ian Campbell wrote: > > > > > http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65301/ > > > > > > I think that ought to give a baseline for the bisector to work with. > > > I'll > > > prod it to do so. > > > > Results are below. TL;DR: d02e84b9d9d "vVMX: use latched VMCS machine > > address" is somehow at fault. > > > > It appears to be somewhat machine specific, the one this has been > > failing on is godello* which says "CPU0: Intel(R) Xeon(R) CPU E3-1220 > > v3 @ 3.10GHz stepping 03" in its serial log. > > > > Andy suggested this might be related to cpu_has_vmx_vmcs_shadowing > > so Haswell and newer vs IvyBridge and older. > > Yeah, but on irc it was also made clear that the regression is on a > system without that capability. What I was trying to say he said was that the difference between working and broken hosts might be spread along the lines of >=Haswell vs <=IvyBridge. How that maps onto E3-1220, which is what is exhibiting the issue, I leave to you guys. > At this point we certainly need to seriously consider reverting the > whole change. The reason I continue to be hesitant is that I'm > afraid this may result in no-one trying to find out what the problem > here is. While I could certainly try to, I'm sure I won't find time to > do so within the foreseeable future. And since we didn't get any > real feedback from Intel so far, I thought I'd ping them to at least > share some status before we decide. That pinging has happened > a few minutes ago. I'd therefore like to give it, say, another day, > and if by then we don't have an estimate for when a fix might > become available, I'd do the revert. Unless of course somebody > feels strongly about doing the revert immediately. I don't mind waiting. One approach to fixing might be to disentangle the various things which this patch did, such that the actual culprit is a smaller thing to analyse. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 3/3] xen/virtio_ring: introduce cpu_to_virtio_addr and virtio_addr_to_cpu
When running on Xen inside as virtual machine (nested virt scenario),
addresses need to be translated from phys to machine to get the actual
guest pseudo-physical address.
Introduce a new pair of functions, cpu_to_virtio_addr and
virtio_addr_to_cpu, which call the appriopriate __virtio64_to_cpu and
__cpu_to_virtio64 functions after doing the phys_to_bus and bus_to_phys
translations for Xen.
No changes in behavior for the non-Xen case.
Signed-off-by: Stefano Stabellini
---
I realize that this patch is not very nice, but at least it is easy to
understand. I welcome any suggestions on how to improve it.
I considered introducing regular dma API calls, like
dma_map/unmap_single and dma_map/unmap_sg. However they would make the
non-Xen code path more complex than it is today. We would also need to
keep track of the physical or virtual address in addition to the dma
address for each vring_desc to be able to free the memory in detach_buf.
---
drivers/virtio/virtio_ring.c |9 +
include/linux/virtio_config.h | 14 ++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 096b857..34a1d42 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -16,6 +16,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include
#include
#include
#include
@@ -172,7 +173,7 @@ static inline int virtqueue_add(struct virtqueue *_vq,
if (desc) {
/* Use a single buffer which doesn't continue */
vq->vring.desc[head].flags = cpu_to_virtio16(_vq->vdev,
VRING_DESC_F_INDIRECT);
- vq->vring.desc[head].addr = cpu_to_virtio64(_vq->vdev,
virt_to_phys(desc));
+ vq->vring.desc[head].addr = cpu_to_virtio_addr(_vq->vdev,
virt_to_phys(desc));
/* avoid kmemleak false positive (hidden by virt_to_phys) */
kmemleak_ignore(desc);
vq->vring.desc[head].len = cpu_to_virtio32(_vq->vdev, total_sg
* sizeof(struct vring_desc));
@@ -206,7 +207,7 @@ static inline int virtqueue_add(struct virtqueue *_vq,
for (n = 0; n < out_sgs; n++) {
for (sg = sgs[n]; sg; sg = sg_next(sg)) {
desc[i].flags = cpu_to_virtio16(_vq->vdev,
VRING_DESC_F_NEXT);
- desc[i].addr = cpu_to_virtio64(_vq->vdev, sg_phys(sg));
+ desc[i].addr = cpu_to_virtio_addr(_vq->vdev,
sg_phys(sg));
desc[i].len = cpu_to_virtio32(_vq->vdev, sg->length);
prev = i;
i = virtio16_to_cpu(_vq->vdev, desc[i].next);
@@ -215,7 +216,7 @@ static inline int virtqueue_add(struct virtqueue *_vq,
for (; n < (out_sgs + in_sgs); n++) {
for (sg = sgs[n]; sg; sg = sg_next(sg)) {
desc[i].flags = cpu_to_virtio16(_vq->vdev,
VRING_DESC_F_NEXT | VRING_DESC_F_WRITE);
- desc[i].addr = cpu_to_virtio64(_vq->vdev, sg_phys(sg));
+ desc[i].addr = cpu_to_virtio_addr(_vq->vdev,
sg_phys(sg));
desc[i].len = cpu_to_virtio32(_vq->vdev, sg->length);
prev = i;
i = virtio16_to_cpu(_vq->vdev, desc[i].next);
@@ -433,7 +434,7 @@ static void detach_buf(struct vring_virtqueue *vq, unsigned
int head)
/* Free the indirect table */
if (vq->vring.desc[i].flags & cpu_to_virtio16(vq->vq.vdev,
VRING_DESC_F_INDIRECT))
- kfree(phys_to_virt(virtio64_to_cpu(vq->vq.vdev,
vq->vring.desc[i].addr)));
+ kfree(phys_to_virt(virtio_addr_to_cpu(vq->vq.vdev,
vq->vring.desc[i].addr)));
while (vq->vring.desc[i].flags & cpu_to_virtio16(vq->vq.vdev,
VRING_DESC_F_NEXT)) {
i = virtio16_to_cpu(vq->vq.vdev, vq->vring.desc[i].next);
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index e5ce8ab..861803f 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -6,6 +6,8 @@
#include
#include
#include
+#include
+#include
/**
* virtio_config_ops - operations for configuring a virtio device
@@ -237,11 +239,23 @@ static inline u64 virtio64_to_cpu(struct virtio_device
*vdev, __virtio64 val)
return __virtio64_to_cpu(virtio_is_little_endian(vdev), val);
}
+static inline u64 virtio_addr_to_cpu(struct virtio_device *vdev, __virtio64
val)
+{
+ val = xen_pv_domain() ? xen_bus_to_phys(val) : val;
+ return __virtio64_to_cpu(virtio_is_little_endian(vdev), val);
+}
+
static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val)
{
return __cpu_to_virtio64(virtio_is_little_endian(vdev), val);
}
+static inline __virtio64 cpu_to_virtio_addr(struct virtio_device *vdev, u64
val)
+{
+ val = xen_pv_domain() ? xen_phys_to_bus(va
[Xen-devel] [PATCH RFC 2/3] xen/virtio: allocate a contiguous region to be use as virtio queue
When running on Xen inside as virtual machine (nested virt scenario),
memory allocated by alloc_pages_exact might not actually be contiguous.
Call xen_swiotlb_alloc_coherent instead, which is going to take care of
making the buffer contiguous in machine memory.
No changes in behavior for the non-Xen case.
Signed-off-by: Stefano Stabellini
---
Alternatively we could call dma_alloc_coherent in all cases, but that
would make the non-Xen code path more complex.
---
drivers/virtio/virtio_pci_legacy.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.c
index 48bc979..27359ac 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -18,6 +18,8 @@
*/
#include "virtio_pci_common.h"
+#include
+#include
/* virtio config->get_features() implementation */
static u64 vp_get_features(struct virtio_device *vdev)
@@ -122,6 +124,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device
*vp_dev,
unsigned long size;
u16 num;
int err;
+ dma_addr_t dma_addr;
/* Select the queue we're interested in */
iowrite16(index, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_SEL);
@@ -135,12 +138,20 @@ static struct virtqueue *setup_vq(struct
virtio_pci_device *vp_dev,
info->msix_vector = msix_vec;
size = PAGE_ALIGN(vring_size(num, VIRTIO_PCI_VRING_ALIGN));
- info->queue = alloc_pages_exact(size, GFP_KERNEL|__GFP_ZERO);
+ /* activate the queue */
+ if (xen_domain()) {
+ info->queue = xen_swiotlb_alloc_coherent(NULL,
+ size,
+ &dma_addr,
+ GFP_KERNEL|__GFP_ZERO,
+ NULL);
+ } else {
+ info->queue = alloc_pages_exact(size, GFP_KERNEL|__GFP_ZERO);
+ dma_addr = virt_to_phys(info->queue);
+ }
if (info->queue == NULL)
return ERR_PTR(-ENOMEM);
-
- /* activate the queue */
- iowrite32(virt_to_phys(info->queue) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT,
+ iowrite32(dma_addr >> VIRTIO_PCI_QUEUE_ADDR_SHIFT,
vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
/* create the vring */
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 1/3] xen: export xen_phys_to_bus, xen_bus_to_phys and xen_virt_to_bus
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: david.vra...@citrix.com
---
drivers/xen/swiotlb-xen.c | 31 ---
include/xen/swiotlb-xen.h | 32
2 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 79bc493..56014d5 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -75,37 +75,6 @@ static unsigned long xen_io_tlb_nslabs;
static u64 start_dma_addr;
-/*
- * Both of these functions should avoid PFN_PHYS because phys_addr_t
- * can be 32bit when dma_addr_t is 64bit leading to a loss in
- * information if the shift is done before casting to 64bit.
- */
-static inline dma_addr_t xen_phys_to_bus(phys_addr_t paddr)
-{
- unsigned long bfn = pfn_to_bfn(PFN_DOWN(paddr));
- dma_addr_t dma = (dma_addr_t)bfn << PAGE_SHIFT;
-
- dma |= paddr & ~PAGE_MASK;
-
- return dma;
-}
-
-static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
-{
- unsigned long pfn = bfn_to_pfn(PFN_DOWN(baddr));
- dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
- phys_addr_t paddr = dma;
-
- paddr |= baddr & ~PAGE_MASK;
-
- return paddr;
-}
-
-static inline dma_addr_t xen_virt_to_bus(void *address)
-{
- return xen_phys_to_bus(virt_to_phys(address));
-}
-
static int check_pages_physically_contiguous(unsigned long pfn,
unsigned int offset,
size_t length)
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 8b2eb93..d55aee8 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -3,9 +3,41 @@
#include
#include
+#include
extern int xen_swiotlb_init(int verbose, bool early);
+/*
+ * Both of these functions should avoid PFN_PHYS because phys_addr_t
+ * can be 32bit when dma_addr_t is 64bit leading to a loss in
+ * information if the shift is done before casting to 64bit.
+ */
+static inline dma_addr_t xen_phys_to_bus(phys_addr_t paddr)
+{
+ unsigned long bfn = pfn_to_bfn(PFN_DOWN(paddr));
+ dma_addr_t dma = (dma_addr_t)bfn << PAGE_SHIFT;
+
+ dma |= paddr & ~PAGE_MASK;
+
+ return dma;
+}
+
+static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
+{
+ unsigned long pfn = bfn_to_pfn(PFN_DOWN(baddr));
+ dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
+ phys_addr_t paddr = dma;
+
+ paddr |= baddr & ~PAGE_MASK;
+
+ return paddr;
+}
+
+static inline dma_addr_t xen_virt_to_bus(void *address)
+{
+ return xen_phys_to_bus(virt_to_phys(address));
+}
+
extern void
*xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 0/3] Xen on Virtio
Hi all, this patch series introduces support for running Linux on top of Xen inside a virtual machine with virtio devices (nested virt scenario). The problem is that Linux virtio drivers use virt_to_phys to get the guest pseudo-physical addresses to pass to the backend, which doesn't work as expected on Xen. Switching the virtio drivers to the dma APIs (dma_alloc_coherent, dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as Xen support in Linux provides an implementation of the dma API which takes care of the additional address conversions. However using the dma API would increase the complexity of the non-Xen case too. We would also need to keep track of the physical or virtual address in addition to the dma address for each vring_desc to be able to free the memory in detach_buf (see patch #3). Instead this series adds few obvious checks to perform address translations in a couple of key places, without changing non-Xen code paths. You are welcome to suggest improvements or alternative implementations. Thanks, Stefano Stefano Stabellini (3): xen: export xen_phys_to_bus, xen_bus_to_phys and xen_virt_to_bus xen/virtio: allocate a contiguous region to be use as virtio queue xen/virtio_ring: introduce cpu_to_virtio_addr and virtio_addr_to_cpu drivers/virtio/virtio_pci_legacy.c | 19 +++ drivers/virtio/virtio_ring.c |9 + drivers/xen/swiotlb-xen.c | 31 --- include/linux/virtio_config.h | 14 ++ include/xen/swiotlb-xen.h | 32 5 files changed, 66 insertions(+), 39 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 65141: regressions - FAIL
>>> On 05.12.15 at 09:09, wrote: > On Wed, 2015-12-02 at 13:51 +, Ian Campbell wrote: > >> http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65301/ >> >> I think that ought to give a baseline for the bisector to work with. I'll >> prod it to do so. > > Results are below. TL;DR: d02e84b9d9d "vVMX: use latched VMCS machine > address" is somehow at fault. > > It appears to be somewhat machine specific, the one this has been > failing on is godello* which says "CPU0: Intel(R) Xeon(R) CPU E3-1220 > v3 @ 3.10GHz stepping 03" in its serial log. > > Andy suggested this might be related to cpu_has_vmx_vmcs_shadowing > so Haswell and newer vs IvyBridge and older. Yeah, but on irc it was also made clear that the regression is on a system without that capability. At this point we certainly need to seriously consider reverting the whole change. The reason I continue to be hesitant is that I'm afraid this may result in no-one trying to find out what the problem here is. While I could certainly try to, I'm sure I won't find time to do so within the foreseeable future. And since we didn't get any real feedback from Intel so far, I thought I'd ping them to at least share some status before we decide. That pinging has happened a few minutes ago. I'd therefore like to give it, say, another day, and if by then we don't have an estimate for when a fix might become available, I'd do the revert. Unless of course somebody feels strongly about doing the revert immediately. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] xen/MSI-X: latch MSI-X table writes
>>> On 07.12.15 at 13:41, wrote:
> On Tue, 24 Nov 2015, Jan Beulich wrote:
>> @@ -332,6 +334,13 @@ static int xen_pt_msix_update_one(XenPCI
>>
>> pirq = entry->pirq;
>
> I know that in your opinion is superfluous, nonetheless could you please
> add 2-3 lines of in-code comment right here, to explain what you are
> doing with the check? Something like:
>
> /*
> * Update the entry addr and data to the latest values only when the
> * entry is masked or they are all masked, as required by the spec.
> * Addr and data changes while the MSI-X entry is unmasked will be
> * delayed until the next masking->unmasking.
> */
>
>
>> +if (pirq == XEN_PT_UNASSIGNED_PIRQ || s->msix->maskall ||
>> +(vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
>> +entry->addr = entry->latch(LOWER_ADDR) |
>> + ((uint64_t)entry->latch(UPPER_ADDR) << 32);
>> +entry->data = entry->latch(DATA);
>> +}
Adding a comment like this is fine of course, namely if it helps
acceptance.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 09/11] mg-schema-test-database: New script
On Mon, 2015-12-07 at 15:12 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH 09/11] mg-schema-test-database:
> New script"):
> > On Fri, 2015-12-04 at 19:35 +, Ian Jackson wrote:
> > > This allows a user in non-standalone mode to make a whole new test
> > > database, which is largely a clone of the original database.
> > >
> > > The new db refers to the same resources (hosts), and more-or-less
> > > safely borrows some of those hosts.
> >
> > "more-or-less" ? ;-)
>
> This is a reference to the lack of owner/queue daemon handling. (And
> of course, the general limitations of `safety' in this kind of
> context.)
>
> > What's the overall idiom for use here, something like:
> >
> > Against the production DB:
> > OSSTEST_TASK=ianc@testing-something ./mg-allocate [-U ...] a-host
> >
> > ./mg-schema-test-database create [_SUFFIX] ianc@testing-something
> >
> > Ending up in a state where a-host is allocated in the production db and
> > idle in this new test db and all other hosts are allocated in the test
> > db
> > and left to go about their usual business in the production db?
>
> Exactly. Maybe I should copy this to the doc comment :-).
Please feel free to nab it.
> > I glanced through this, but TBH I don't think picking through it line
> > by
> > line will be very productive, I trust you've tested it and its ok...
>
> Due to being incompetent I've hammered each part of it quite a bit and
> the all the resulting database states (even intermediate ones) look
> good.
:-)
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 04/11] mg-debug-fail: New utility script for debugging
On Mon, 2015-12-07 at 15:40 +, Ian Campbell wrote:
> On Mon, 2015-12-07 at 15:10 +, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [OSSTEST PATCH 04/11] mg-debug-fail: New
> > utility script for debugging"):
> > > On Fri, 2015-12-04 at 19:35 +, Ian Jackson wrote:
> > > > diff --git a/mg-debug-fail b/mg-debug-fail
> > > > new file mode 100755
> > > > index 000..64fa235
> > > > --- /dev/null
> > > > +++ b/mg-debug-fail
> > > > @@ -0,0 +1,13 @@
> > > > +#!/bin/sh
> > > > +#
> > > > +# This script can be provided anywhere an executable or command
> > > > name
> > > > is
> > > > +# wanted. It prints its arguments, and its stdin, to its stderr,
> > > > and
> > > > +# then exits nonzero.
> > > > +#
> > > > +# When using this it may be useful to provide > > > +# redirection for the whole program under test. Otherwise things
> > > > +# can mysteriously hang.
> > >
> > > "egrep . - /dev/null" is too noisy, it adds a "(standard input):"
> > > prefix
> > > which I don't think you want. But "egrep -h . - /dev/null" seems to
> > > remedy
> > > this without the possibility of these mysterious hangs.
> >
> > This is confusing to me. The problem is that mg-debug-fail does not
> > know whether to try to read and print its stdin. Sometimes its stdin
> > will be the stdin for some utility that it is standing in for, and
> > should be dumped. Whereas sometimes its stdin is the user's tty,
> > which should be left alone.
> >
> > This difficulty is fixed in the next patch. None of your suggestions
> > seem to address it. What problem do you think they are solving ?
>
> I think I got off on a bit of a tangent, and hadn't seen the next patch
> yet.
By which I mean:
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 04/11] mg-debug-fail: New utility script for debugging
On Mon, 2015-12-07 at 15:10 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH 04/11] mg-debug-fail: New
> utility script for debugging"):
> > On Fri, 2015-12-04 at 19:35 +, Ian Jackson wrote:
> > > diff --git a/mg-debug-fail b/mg-debug-fail
> > > new file mode 100755
> > > index 000..64fa235
> > > --- /dev/null
> > > +++ b/mg-debug-fail
> > > @@ -0,0 +1,13 @@
> > > +#!/bin/sh
> > > +#
> > > +# This script can be provided anywhere an executable or command name
> > > is
> > > +# wanted. It prints its arguments, and its stdin, to its stderr,
> > > and
> > > +# then exits nonzero.
> > > +#
> > > +# When using this it may be useful to provide > > +# redirection for the whole program under test. Otherwise things
> > > +# can mysteriously hang.
> >
> > "egrep . - /dev/null" is too noisy, it adds a "(standard input):"
> > prefix
> > which I don't think you want. But "egrep -h . - /dev/null" seems to
> > remedy
> > this without the possibility of these mysterious hangs.
>
> This is confusing to me. The problem is that mg-debug-fail does not
> know whether to try to read and print its stdin. Sometimes its stdin
> will be the stdin for some utility that it is standing in for, and
> should be dumped. Whereas sometimes its stdin is the user's tty,
> which should be left alone.
>
> This difficulty is fixed in the next patch. None of your suggestions
> seem to address it. What problem do you think they are solving ?
I think I got off on a bit of a tangent, and hadn't seen the next patch
yet.
> > Also, what does egrep give us here over just cat?
>
> I meant to write egrep ''
> and its advantage is that it sanitises missing trailing newline.
>
> But maybe we want to preserve missing trailing newline.
I don't think so, I just didn't know about that behaviour of egrep, it
sounds useful.
>
> An alternative to replace the egrep would be
> sed 's/^/mg-debug-fail-stdin: /' >&2
> which preserves missing trailing newline but annotates the output.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 07/11] cri-getconfig: Provide debugging for get_psql_cmd
On Mon, 2015-12-07 at 15:02 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH 07/11] cri-getconfig: Provide
> debugging for get_psql_cmd"):
> > On Fri, 2015-12-04 at 19:35 +, Ian Jackson wrote:
> > > If set -x is in force, turn it off for get_psql_cmd: our perl rune is
> > > uninteresting to see repeated ad infinitum in debugging output.
> >
> > I should probably know this, but what is the scope of the set +x here?
> > Is
> > it confined to get_psql_cmd or will callers find things going
> > surprisingly
> > quiet?
>
> get_psql_cmd is generally used inside $( ), which limits the scope of
> the +x. Code which wraps get_psql_cmd might do some things after
> calling it, but not very much.
>
> > Experimentally I think it is the latter, which is a shame. Maybe just
> > wrap
> > the set+perl in ()s ?
>
> That would improve things if anyone is likely to redirect
> get_psql_cmd into a file, but that seems unlikely. I'll do that if
> you want, though.
You make a good point about it usually being in $(), so no need.
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
