Re: [Xen-devel] [PATCH v7 1/9] x86/xpti: avoid copying L4 page table contents when possible
On 16/04/18 20:22, Juergen Gross wrote: > On 16/04/18 17:34, Tim Deegan wrote: >> Hi, >> >> At 02:43 -0600 on 13 Apr (1523587395), Jan Beulich wrote: >> On 12.04.18 at 20:09, wrote: For mitigation of Meltdown the current L4 page table is copied to the cpu local root page table each time a 64 bit pv guest is entered. Copying can be avoided in cases where the guest L4 page table hasn't been modified while running the hypervisor, e.g. when handling interrupts or any hypercall not modifying the L4 page table or %cr3. So add a per-cpu flag indicating whether the copying should be performed and set that flag only when loading a new %cr3 or modifying the L4 page table. This includes synchronization of the cpu local root page table with other cpus, so add a special synchronization flag for that case. A simple performance check (compiling the hypervisor via "make -j 4") in dom0 with 4 vcpus shows a significant improvement: - real time drops from 112 seconds to 103 seconds - system time drops from 142 seconds to 131 seconds Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich --- V7: - add missing flag setting in shadow code >>> >>> This now needs an ack from Tim (now Cc-ed). >> >> I may be misunderstanding how this flag is supposed to work, but this >> seems at first glance to do both too much and too little. The sl4 >> table that's being modified may be in use on any number of other >> pcpus, and might not be in use on the current pcpu. > > Okay. > >> It looks like the do_mmu_update path issues a flush IPI; I think that >> the equivalent IPI would be a better place to hook if you can. > > I want to catch only cases where the L4 table is being modified. > >> Also I'm not sure why the flag needs to be set in >> l4e_propagate_from_guest() as well as shadow_set_l4e(). Can you >> elaborate? > > I narrowed down iteratively where the setting of the flag is mandatory. > Doing it in shadow_set_l4e() seemed to look right, but it wasn't enough. > Setting it also in l4e_propagate_from_guest() showed no further problems > migrating the guest. I just revisited this after looking into the code. Seems I remembered the sequence of narrowing down wrong. l4e_propagate_from_guest() doesn't need to set the flag. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On 04/17/2018 11:57 PM, Dongwon Kim wrote: On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: Yeah, I definitely agree on the idea of expanding the use case to the general domain where dmabuf sharing is used. However, what you are targetting with proposed changes is identical to the core design of hyper_dmabuf. On top of this basic functionalities, hyper_dmabuf has driver level inter-domain communication, that is needed for dma-buf remote tracking (no fence forwarding though), event triggering and event handling, extra meta data exchange and hyper_dmabuf_id that represents grefs (grefs are shared implicitly on driver level) This really isn't a positive design aspect of hyperdmabuf imo. The core code in xen-zcopy (ignoring the ioctl side, which will be cleaned up) is very simple & clean. If there's a clear need later on we can extend that. But for now xen-zcopy seems to cover the basic use-case needs, so gets the job done. Also it is designed with frontend (common core framework) + backend (hyper visor specific comm and memory sharing) structure for portability. We just can't limit this feature to Xen because we want to use the same uapis not only for Xen but also other applicable hypervisor, like ACORN. See the discussion around udmabuf and the needs for kvm. I think trying to make an ioctl/uapi that works for multiple hypervisors is misguided - it likely won't work. On top of that the 2nd hypervisor you're aiming to support is ACRN. That's not even upstream yet, nor have I seen any patches proposing to land linux support for ACRN. Since it's not upstream, it doesn't really matter for upstream consideration. I'm doubting that ACRN will use the same grant references as xen, so the same uapi won't work on ACRN as on Xen anyway. Yeah, ACRN doesn't have grant-table. Only Xen supports it. But that is why hyper_dmabuf has been architectured with the concept of backend. If you look at the structure of backend, you will find that backend is just a set of standard function calls as shown here: struct hyper_dmabuf_bknd_ops { /* backend initialization routine (optional) */ int (*init)(void); /* backend cleanup routine (optional) */ int (*cleanup)(void); /* retreiving id of current virtual machine */ int (*get_vm_id)(void); /* get pages shared via hypervisor-specific method */ int (*share_pages)(struct page **pages, int vm_id, int nents, void **refs_info); /* make shared pages unshared via hypervisor specific method */ int (*unshare_pages)(void **refs_info, int nents); /* map remotely shared pages on importer's side via * hypervisor-specific method */ struct page ** (*map_shared_pages)(unsigned long ref, int vm_id, int nents, void **refs_info); /* unmap and free shared pages on importer's side via * hypervisor-specific method */ int (*unmap_shared_pages)(void **refs_info, int nents); /* initialize communication environment */ int (*init_comm_env)(void); void (*destroy_comm)(void); /* upstream ch setup (receiving and responding) */ int (*init_rx_ch)(int vm_id); /* downstream ch setup (transmitting and parsing responses) */ int (*init_tx_ch)(int vm_id); int (*send_req)(int vm_id, struct hyper_dmabuf_req *req, int wait); }; All of these can be mapped with any hypervisor specific implementation. We designed backend implementation for Xen using grant-table, Xen event and ring buffer communication. For ACRN, we have another backend using Virt-IO for both memory sharing and communication. We tried to define this structure of backend to make it general enough (or it can be even modified or extended to support more cases.) so that it can fit to other hypervisor cases. Only requirements/expectation on the hypervisor are page-level memory sharing and inter-domain communication, which I think are standard features of modern hypervisor. And please review common UAPIs that hyper_dmabuf and xen-zcopy supports. They are very general. One is getting FD (dmabuf) and get those shared. The other is generating dmabuf from global handle (secure handle hiding gref behind it). On top of this, hyper_dmabuf has "unshare" and "query" which are also useful for any cases. So I don't know why we wouldn't want to try to make these standard in most of hypervisor cases instead of limiting it to certain hypervisor like Xen. Frontend-backend structre is optimal for this I think. So I am wondering we can start with this hyper_dmabuf then modify it for your use-case if needed and polish and fix any glitches if we want to to use this for all general dma-buf usecases. Imo xen-zcopy is a much more reasonable starting point for upstream, which can then
[Xen-devel] Xen 4.11 RC1
Hi all, Xen 4.11 rc1 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.11.0-rc1 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.11.0-rc1/xen-4.11.0-rc1.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.11.0-rc1/xen-4.11.0-rc1.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (jgr...@suse.com). There will be a Xen Test Day. The announcement for that will be sent out soon. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/xen: Remove use of VLAs
On 04/17/2018 07:33 PM, Laura Abbott wrote: > On 04/17/2018 12:16 AM, Juergen Gross wrote: >> On 16/04/18 15:27, Boris Ostrovsky wrote: >>> On 04/13/2018 06:11 PM, Laura Abbott wrote: There's an ongoing effort to remove VLAs[1] from the kernel to eventually turn on -Wvla. The few VLAs in use have an upper bound based on a size of 64K. This doesn't produce an excessively large stack so just switch the upper bound. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Laura Abbott --- arch/x86/xen/enlighten_pv.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index c36d23aa6c35..d96a5a535cbb 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -421,8 +421,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr) { unsigned long va = dtr->address; unsigned int size = dtr->size + 1; - unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE); >>> >>> >>> >>> Isn't dtr->size always either GDT_SIZE or 0? >> >> GDT_SIZE - 1 :-) >> - unsigned long frames[pages]; + unsigned long frames[DIV_ROUND_UP(SZ_64K, PAGE_SIZE)]; >> >> So we could just go with one frame and modify the BUG_ON() further below >> accordingly. >> > > Do you want to just remove the loop as well since we're never going > to do more than one frame? We end up with net code deletion. > Yes, the loop, as well as the comment about max size being 64K can all be removed. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/xen: Remove use of VLAs
On 04/17/2018 12:16 AM, Juergen Gross wrote: On 16/04/18 15:27, Boris Ostrovsky wrote: On 04/13/2018 06:11 PM, Laura Abbott wrote: There's an ongoing effort to remove VLAs[1] from the kernel to eventually turn on -Wvla. The few VLAs in use have an upper bound based on a size of 64K. This doesn't produce an excessively large stack so just switch the upper bound. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Laura Abbott --- arch/x86/xen/enlighten_pv.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index c36d23aa6c35..d96a5a535cbb 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -421,8 +421,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr) { unsigned long va = dtr->address; unsigned int size = dtr->size + 1; - unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE); Isn't dtr->size always either GDT_SIZE or 0? GDT_SIZE - 1 :-) - unsigned long frames[pages]; + unsigned long frames[DIV_ROUND_UP(SZ_64K, PAGE_SIZE)]; So we could just go with one frame and modify the BUG_ON() further below accordingly. Do you want to just remove the loop as well since we're never going to do more than one frame? We end up with net code deletion. Thanks, Laura Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 122347: regressions - FAIL
flight 122347 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/122347/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 118324 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. vs. 118324 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 118324 test-armhf-armhf-xl-multivcpu 11 debian-fixupfail REGR. vs. 118324 test-armhf-armhf-libvirt-xsm 11 debian-fixup fail REGR. vs. 118324 test-armhf-armhf-xl-xsm 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324 test-armhf-armhf-xl-arndale 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-xl-credit2 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-libvirt 10 debian-install fail REGR. vs. 118324 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118324 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118324 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxa27fc14219f2e3c4a46ba9177b04d9b52c875532 baseline version: linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5 Last test of basis 118324 2018-01-25 07:31:24 Z 82 days Failing since118362 2018-01-26 16:56:17 Z 81 days 71 attempts Testing same since 122347 2018-04-17 09:04:18 Z0 days1 attempts 3304 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > > Yeah, I definitely agree on the idea of expanding the use case to the > > general domain where dmabuf sharing is used. However, what you are > > targetting with proposed changes is identical to the core design of > > hyper_dmabuf. > > > > On top of this basic functionalities, hyper_dmabuf has driver level > > inter-domain communication, that is needed for dma-buf remote tracking > > (no fence forwarding though), event triggering and event handling, extra > > meta data exchange and hyper_dmabuf_id that represents grefs > > (grefs are shared implicitly on driver level) > > This really isn't a positive design aspect of hyperdmabuf imo. The core > code in xen-zcopy (ignoring the ioctl side, which will be cleaned up) is > very simple & clean. > > If there's a clear need later on we can extend that. But for now xen-zcopy > seems to cover the basic use-case needs, so gets the job done. > > > Also it is designed with frontend (common core framework) + backend > > (hyper visor specific comm and memory sharing) structure for portability. > > We just can't limit this feature to Xen because we want to use the same > > uapis not only for Xen but also other applicable hypervisor, like ACORN. > > See the discussion around udmabuf and the needs for kvm. I think trying to > make an ioctl/uapi that works for multiple hypervisors is misguided - it > likely won't work. > > On top of that the 2nd hypervisor you're aiming to support is ACRN. That's > not even upstream yet, nor have I seen any patches proposing to land linux > support for ACRN. Since it's not upstream, it doesn't really matter for > upstream consideration. I'm doubting that ACRN will use the same grant > references as xen, so the same uapi won't work on ACRN as on Xen anyway. Yeah, ACRN doesn't have grant-table. Only Xen supports it. But that is why hyper_dmabuf has been architectured with the concept of backend. If you look at the structure of backend, you will find that backend is just a set of standard function calls as shown here: struct hyper_dmabuf_bknd_ops { /* backend initialization routine (optional) */ int (*init)(void); /* backend cleanup routine (optional) */ int (*cleanup)(void); /* retreiving id of current virtual machine */ int (*get_vm_id)(void); /* get pages shared via hypervisor-specific method */ int (*share_pages)(struct page **pages, int vm_id, int nents, void **refs_info); /* make shared pages unshared via hypervisor specific method */ int (*unshare_pages)(void **refs_info, int nents); /* map remotely shared pages on importer's side via * hypervisor-specific method */ struct page ** (*map_shared_pages)(unsigned long ref, int vm_id, int nents, void **refs_info); /* unmap and free shared pages on importer's side via * hypervisor-specific method */ int (*unmap_shared_pages)(void **refs_info, int nents); /* initialize communication environment */ int (*init_comm_env)(void); void (*destroy_comm)(void); /* upstream ch setup (receiving and responding) */ int (*init_rx_ch)(int vm_id); /* downstream ch setup (transmitting and parsing responses) */ int (*init_tx_ch)(int vm_id); int (*send_req)(int vm_id, struct hyper_dmabuf_req *req, int wait); }; All of these can be mapped with any hypervisor specific implementation. We designed backend implementation for Xen using grant-table, Xen event and ring buffer communication. For ACRN, we have another backend using Virt-IO for both memory sharing and communication. We tried to define this structure of backend to make it general enough (or it can be even modified or extended to support more cases.) so that it can fit to other hypervisor cases. Only requirements/expectation on the hypervisor are page-level memory sharing and inter-domain communication, which I think are standard features of modern hypervisor. And please review common UAPIs that hyper_dmabuf and xen-zcopy supports. They are very general. One is getting FD (dmabuf) and get those shared. The other is generating dmabuf from global handle (secure handle hiding gref behind it). On top of this, hyper_dmabuf has "unshare" and "query" which are also useful for any cases. So I don't know why we wouldn't want to try to make these standard in most of hypervisor cases instead of limiting it to certain hypervisor like Xen. Frontend-backend structre is optimal for this I think. > > > So I am wondering we can start with this hyper_dmabuf then modify it for > > your use-case if needed and polish and fix any glitches if we want to > > to use this for all general dma-buf usecases. > > Imo xen-zcopy is a much more reasonable start
[Xen-devel] [ovmf baseline-only test] 74631: all pass
This run is configured for baseline tests only. flight 74631 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74631/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 55f67014d7b4a1228754313917ccca5539764802 baseline version: ovmf 5e0e476a9542a1f769fd5325c0be2d16d3ad1d42 Last test of basis74629 2018-04-17 06:19:50 Z0 days Testing same since74631 2018-04-17 14:52:22 Z0 days1 attempts People who touched revisions under test: Pete Batard 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 55f67014d7b4a1228754313917ccca5539764802 Author: Pete Batard Date: Wed Mar 28 23:55:21 2018 +0800 MdePkg/Library/BaseCpuLib: Enable VS2017/ARM64 builds Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Pete Batard Reviewed-by: Liming Gao commit 37db86ae23021f345d583c7c9c3059e339083439 Author: Pete Batard Date: Wed Mar 28 23:55:20 2018 +0800 MdePkg/Library/BaseSynchronizationLib: Enable VS2017/ARM64 builds Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Pete Batard Reviewed-by: Liming Gao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] mktarball: For qemu upstream, use their scripts/archive-source.sh
George Dunlap writes ("Re: [PATCH] mktarball: For qemu upstream, use their scripts/archive-source.sh"): > On 04/17/2018 06:04 PM, Ian Jackson wrote: > > +tar > I'm not sure why we're piping from a file and then specifying `-`, but > now's not really the time for bike shedding: C and f interact in a way that I find odd, so I prefer to use <. > Acked-by: George Dunlap Thanks. Now in 4.11.0-rc1 and in staging. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] mktarball: For qemu upstream, use their scripts/archive-source.sh
On 04/17/2018 06:04 PM, Ian Jackson wrote: > qemu upstream uses git submodules. git archive does not work with git > submodules (and could not work properly with them, because this is one > of the many things it is inherently impossible to do correctly with > git submodules). > > qemu upstream have worked around this by providing a rather scary > shell script which attempts to do roughly the right thing. It's close > enough that we can use it with only minor precautions. > > Unfortunately this does mean that `mktarball' now executes the qemu > source code it was using, rather than merely shuffling it about, as it > did previously. I think this is a less bad ill than copying (and, > effectively, forking) the scary script. > > CC: Wei Liu > CC: George Dunlap > CC: Juergen Gross > Signed-off-by: Ian Jackson > --- > tools/misc/mktarball | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/tools/misc/mktarball b/tools/misc/mktarball > index 73282b5..42d5430 100755 > --- a/tools/misc/mktarball > +++ b/tools/misc/mktarball > @@ -29,7 +29,21 @@ mkdir -p $tdir > > git_archive_into $xen_root $tdir/xen-$desc > > -git_archive_into $xen_root/tools/qemu-xen-dir-remote > $tdir/xen-$desc/tools/qemu-xen > +# We can't use git_archive_into with qemu upstream because it uses > +# git-submodules. git-submodules are an inherently broken git feature > +# which should never be used in any circumstance. Unfortunately, qemu > +# upstream uses them. Relevantly for us, git archive does not work > +# properly when there are submodules. > +( > +cd $xen_root/tools/qemu-xen-dir-remote > +# if it's not clean, the qemu script will call `git stash' ! > +git --no-pager diff --stat HEAD > +scripts/archive-source.sh $tdir/xen-$desc/tools/qemu-xen.tar > +cd $tdir/xen-$desc/tools > +mkdir qemu-xen > +tar ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/p2m: fixed p2m_change_type_range() start / end check
p2m_change_type_range() handles end > max_mapped_pfn, but not start > max_mapped_pfn. Check the latter just after grabbing the lock and bail if true. Signed-off-by: Razvan Cojocaru Suggested-by: George Dunlap --- xen/arch/x86/mm/p2m.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index c53cab4..af46cd9 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -976,6 +976,13 @@ void p2m_change_type_range(struct domain *d, ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt)); p2m_lock(p2m); + +if ( start > p2m->max_mapped_pfn ) +{ +p2m_unlock(p2m); +return; +} + p2m->defer_nested_flush = 1; if ( unlikely(end > p2m->max_mapped_pfn) ) -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On Tue, Apr 17, 2018 at 9:13 AM, Razvan Cojocaru wrote: > On 04/17/2018 05:58 PM, George Dunlap wrote: It might be nice to have a more structured way of keeping all these changes in sync, rather than relying on this open-coding everywhere. >>> >>> Very true. It has also occured to me that some of these issues would be >>> at least partially mitigated if altp2m was always on, but of course I >>> can also see why that would be frowned upon at this time. >> >> How would having it enabled all the time have helped in this situation? > > Well, the default p2m would just be > d->arch.altp2m_p2m[0], all altp2m_active(d) checks would be gone, the > active p2m for a given VCPU would always be p2m_get_altp2m(v), and so > on. If I understand the design correctly, that is. :) I would also like this setup, it would simplify things a lot. Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] X
--- tools/misc/mktarball | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/tools/misc/mktarball b/tools/misc/mktarball index 73282b5..42d5430 100755 --- a/tools/misc/mktarball +++ b/tools/misc/mktarball @@ -29,7 +29,21 @@ mkdir -p $tdir git_archive_into $xen_root $tdir/xen-$desc -git_archive_into $xen_root/tools/qemu-xen-dir-remote $tdir/xen-$desc/tools/qemu-xen +# We can't use git_archive_into with qemu upstream because it uses +# git-submodules. git-submodules are an inherently broken git feature +# which should never be used in any circumstance. Unfortunately, qemu +# upstream uses them. Relevantly for us, git archive does not work +# properly when there are submodules. +( +cd $xen_root/tools/qemu-xen-dir-remote +# if it's not clean, the qemu script will call `git stash' ! +git --no-pager diff --stat HEAD +scripts/archive-source.sh $tdir/xen-$desc/tools/qemu-xen.tar +cd $tdir/xen-$desc/tools +mkdir qemu-xen +tar https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] mktarball: For qemu upstream, use their scripts/archive-source.sh
qemu upstream uses git submodules. git archive does not work with git submodules (and could not work properly with them, because this is one of the many things it is inherently impossible to do correctly with git submodules). qemu upstream have worked around this by providing a rather scary shell script which attempts to do roughly the right thing. It's close enough that we can use it with only minor precautions. Unfortunately this does mean that `mktarball' now executes the qemu source code it was using, rather than merely shuffling it about, as it did previously. I think this is a less bad ill than copying (and, effectively, forking) the scary script. CC: Wei Liu CC: George Dunlap CC: Juergen Gross Signed-off-by: Ian Jackson --- tools/misc/mktarball | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/tools/misc/mktarball b/tools/misc/mktarball index 73282b5..42d5430 100755 --- a/tools/misc/mktarball +++ b/tools/misc/mktarball @@ -29,7 +29,21 @@ mkdir -p $tdir git_archive_into $xen_root $tdir/xen-$desc -git_archive_into $xen_root/tools/qemu-xen-dir-remote $tdir/xen-$desc/tools/qemu-xen +# We can't use git_archive_into with qemu upstream because it uses +# git-submodules. git-submodules are an inherently broken git feature +# which should never be used in any circumstance. Unfortunately, qemu +# upstream uses them. Relevantly for us, git archive does not work +# properly when there are submodules. +( +cd $xen_root/tools/qemu-xen-dir-remote +# if it's not clean, the qemu script will call `git stash' ! +git --no-pager diff --stat HEAD +scripts/archive-source.sh $tdir/xen-$desc/tools/qemu-xen.tar +cd $tdir/xen-$desc/tools +mkdir qemu-xen +tar https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fwd: [tip:x86/urgent] x86, sched: Allow topologies where NUMA nodes share an LLC
On Tue, 2018-04-17 at 15:08 +0100, Andrew Cooper wrote: > On 17/04/18 15:02, Juergen Gross wrote: > > Is this something we should be aware of in Xen, too? > > If we had something close to a working topology representation, > probably. > True, as far as letting the guest know about these details (in appropriate circumnstaces) goes. About using it _within_ Xen, well: "Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one memory controller and each slice is enumerated to Linux as a NUMA node. This is similar to how the cores and LLC were arranged for the Cluster-On-Die (CoD) feature." This looks similar (but not identical) to, e.g., AMD EPYC. If Xen also sees each slice as a NUMA node as well, we already are doing something (although, of course, we can always improve). If not, I see ways of taking advantage of the information that not all the cores in the socket equally share the LLC, e.g., in Credit2, by providing a per-LLC runqueue option and/or by taking that into account in the 'migration resistance' mechanisms (there is already work in that direction). Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 122343: tolerable FAIL
flight 122343 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/122343/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail pass in 122332 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 122332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 122332 blocked in 122343 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122332 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122332 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122332 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122332 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122332 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122332 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122332 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122332 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122332 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: xen a6aa678fa380e9369cc44701a181142322b3a4b0 baseline version: xen a6aa678fa380e9369cc44701a181142322b3a4b0 Last test of basis 122343 2018-04-17 04:06:26 Z0 days Testing same since (not found) 0 attemp
[Xen-devel] [distros-debian-snapshot test] 74630: tolerable FAIL
flight 74630 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74630/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-i386-daily-netboot-pvgrub 10 debian-di-install fail like 74569 test-amd64-amd64-i386-daily-netboot-pygrub 10 debian-di-install fail like 74569 test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail like 74569 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 74569 test-amd64-amd64-amd64-daily-netboot-pvgrub 11 guest-start fail like 74569 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 74569 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 74569 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 74569 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail like 74569 test-amd64-i386-i386-current-netinst-pygrub 10 debian-di-install fail like 74569 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail like 74569 test-amd64-amd64-i386-current-netinst-pygrub 10 debian-di-install fail like 74569 baseline version: flight 74569 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-daily-netboot-pvgrub fail test-amd64-i386-i386-daily-netboot-pvgrubfail test-amd64-i386-amd64-daily-netboot-pygrub pass test-armhf-armhf-armhf-daily-netboot-pygrub fail test-amd64-amd64-i386-daily-netboot-pygrub fail test-amd64-amd64-amd64-current-netinst-pygrubfail test-amd64-i386-amd64-current-netinst-pygrub fail test-amd64-amd64-i386-current-netinst-pygrub fail test-amd64-i386-i386-current-netinst-pygrub fail test-amd64-amd64-amd64-weekly-netinst-pygrub fail test-amd64-i386-amd64-weekly-netinst-pygrub fail test-amd64-amd64-i386-weekly-netinst-pygrub fail test-amd64-i386-i386-weekly-netinst-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/5] SUPPORT.md: Move descriptions up before Status info
On 17/04/2018, 14:22, "Ian Jackson" wrote: Lars Kurth writes ("Re: [PATCH 4/5] SUPPORT.md: Move descriptions up before Status info"): > There were a couple of minor text changes for grammar reasons, which I noticed and highlighted. Thanks. > I also checked the code motions. There are some things which need to be pointed out, but they should not prevent this series from being checked in. > > However, a couple were missed > * ### PV Console (frontend) => missed moving the note (which is a definition) That's one, not a couple. I have fixed it. > I also spotted a few other inconsistencies, which we probably should fix, but these need backporting > * ARM: 16K and 64K page granularity in guests > * ARM: Guest Device Tree support > * ARM: Guest ACPI support > In all the other section headers we use x86/ or ARM/ I think "x86:" and "ARM:" are more natural so I would prefer that bikeshed purple rather than blue. I think the "/" came from the example of the guest types, which are indeed in some sense "x86/HVM" rather than "x86: HVM". I think we should treat that as a separate issue from this series. Agreed > -### x86/PVH > - > Status, domU: Supported > -Status, dom0: Experimental > + > +### x86/PVH > > PVH is a next-generation paravirtualized mode > designed to take advantage of hardware virtualization support when possible. > > Looks correct from a mere refactoring perspective, but generates some odd behaviour in https://xenbits.xen.org/people/iwj/2018/support-matrix-example-B-v1/t.html > > The underlying reason is that we had some headline re-names between 4.10 and 4.11. e.g. > ARM guest => ARM > > And some support statement changes, e.g. in x86/HVM guest > Status: Supported => Status, domU: Supported The rendering is indeed not ideal. Our options are: (a) Live with it and document it. (b) Make it our practice to go always back and backport a name change for a feature to all versions. I'm not sure this is worth the effort. (c) Invent some new equivalency metadata to put into SUPPORT.md or even into some other file in-tree. Urgh, I don't want to do that. I chose (a). You will see a paragraph about this at the top of the html page: Sometimes the same feature, or a similar feature, is named differently in the documentation for different releases. In such cases the table will show it as two separate features, with a discontinuity in support, even though support may have been continuous. I can live with this approach > We probably need to go through some of these in 4.10 and fix them > But for 4.11 this is correct I think the 4.10 documentation is not wrong, just differently expressed. > The implication is that we need to minimize unnecessary changes to > a) headings > b) clarifications to status before the colon > or backport them to older versions of SUPPORT.md. Otherwise the generated table will become confusing See above. If you want to backport the heading changes, I'll ack your patches :-). Happy to pick this up > ### Direct-boot kernel image format > > +Format which the toolstack accepts for direct-boot kernels > + > Supported, x86: bzImage, ELF > Supported, ARM32: zImage > Supported, ARM64: Image > > -Format which the toolstack accepts for direct-boot kernels > - > > Note: the format here is wrong in both 4.10 and 4.11, this should be something like > > Status, zImage (ARM32): Supported > > Lars will submit a separate patch This is not a blocker because I added parsing code for this format. If you fix it, we can drop that, too, once the change is backported. > ## Scalability > > ### Super page support > > -Status, x86 HVM/PVH, HAP: Supported > -Status, x86 HVM/PVH, Shadow, 2MiB: Supported > -Status, ARM: Supported > - > NB that this refers to the ability of guests > > The beginning of this sentence should probably be changed to > "This feature refers to the ability of guests ..." Or even just "The ability of guests ..." since we don't normally lead each thing with "this is". I think this is not very important. If you want to improve it I will ack your patch. Sure, I can roll this up with the other changes on my list > ## Virtual Hardware, QEMU > > -These are devices available in HVM mode using a qemu devicemodel (the default). > +This section describes supported de
Re: [Xen-devel] [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario
Hi Julien, On Tue, Apr 17, 2018 at 4:11 PM, Julien Grall wrote: > > > On 17/04/18 13:54, Mirela Simonovic wrote: >> >> Hi Julien, > > > Hi, > >> >> On Wed, Apr 11, 2018 at 5:11 PM, Julien Grall >> wrote: >>> >>> Hi, >>> >>> On 11/04/18 14:19, Mirela Simonovic wrote: In existing code the paging for secondary CPUs is setup only in boot flow. The setup is triggered from start_xen function after all CPUs are brought online. In other words, the initialization of VTCR_EL2 register is done out of the cpu_up/start_secondary control flow. However, the cpu_up flow should be self-contained - it should fully initialize a secondary CPU, because the cpu_up is used not only to bring a secondary CPU online on boot, but also to hotplug a CPU during the system resume. With this patch the setting of paging is triggered from start_secondary function if the current system state is not boot. This way, the paging will be setup in non-boot scenarios, while the setup in boot scenario remains unchanged. >>> >>> >>> >>> I am afraid that this is not correct. You can't assume that value chosen >>> for >>> VTCR by Xen at boot will fit this new CPU. So you have to check it is >>> fine >>> or park the CPU if there are any issue. >>> >> >> This is not a new CPU. This CPU already went through its boot sequence >> and it reached the resume point because it does fit the value chosen >> for VTCR by Xen. >> If it wouldn't fit the chosen value for VTCR it would be parked so it >> wouldn't participate in suspend/resume. Please let me know if I >> misunderstood your comment. > > > This is not a new CPU for your use case. However your commit message > speak about "non-boot" CPU bring-up. So for me this is more than > suspend/resume, it is about bringing-up CPU at any time. > Use case you're trying to cover is hotplugging a CPU after the boot is done in bit.LITTLE system, and that CPU wasn't initially brought online (on boot). Right? > As those CPUs can't participate to the decision (it is too late), you > need to make sure the VTCR will fit on that CPU. > Could you please point me to the location in sources where this is done on boot? I mean checking compliance with chosen VTCR value and parking CPU if it doesn't fit. Thanks, Mirela >> >> AFAIU the value chosen by Xen for VTCR config has to be common for all >> online CPUs. Since this value is also used in the resume path I >> suggest to make global (static in the p2m.c) the 'val' variable which >> is currently local in setup_virt_paging() and passed as argument to >> setup_virt_paging_one(). Then setup_virt_paging_one() would not >> receive an argument. >> I need to access this value on resume, so I would call >> setup_virt_paging_one() without argument from start_secondary() if the >> system state is not boot. >> This seems to me a bit cleaner compared to what I submitted in this >> patch, but fundamentally the functionality is the same. > > > You don't need to introduce a static variable it. I believe you can > re-create it based on the information we already have in global > variables. So what I would do is moving the creation of vtcr value in > that function. > > Cheers, > > -- > Julien Grall > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On 04/17/2018 05:58 PM, George Dunlap wrote: >>> It might be nice to have a more structured way of keeping all these >>> changes in sync, rather than relying on this open-coding everywhere. >> >> Very true. It has also occured to me that some of these issues would be >> at least partially mitigated if altp2m was always on, but of course I >> can also see why that would be frowned upon at this time. > > How would having it enabled all the time have helped in this situation? Well, the default p2m would just be d->arch.altp2m_p2m[0], all altp2m_active(d) checks would be gone, the active p2m for a given VCPU would always be p2m_get_altp2m(v), and so on. If I understand the design correctly, that is. :) Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: xenbus_dev_frontend: Really return response string
On 04/17/2018 03:33 AM, Juergen Gross wrote: > On 15/03/18 04:08, Simon Gaiser wrote: >> xenbus_command_reply() did not actually copy the response string and >> leaked stack content instead. >> >> Fixes: 9a6161fe73bd ("xen: return xenstore command failures via response >> instead of rc") >> Signed-off-by: Simon Gaiser > Reviewed-by: Juergen Gross > Applied to for-linus-4.17. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 122344: tolerable all pass - PUSHED
flight 122344 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/122344/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122300 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122300 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122300 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt 4ac43975d514fca900896ddb3e54ef9f145920fe baseline version: libvirt 327ae930a4f833c038cd83ff06e216e697a83111 Last test of basis 122300 2018-04-15 04:21:42 Z2 days Testing same since 122344 2018-04-17 04:20:20 Z0 days1 attempts People who touched revisions under test: Daniel P. Berrangé John Ferlan Ján Tomko Michal Privoznik Radostin Stoyanov jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git
Re: [Xen-devel] [PATCH RESEND] xen/sndif: Sync up with the canonical definition in Xen
On 04/12/2018 01:26 PM, Oleksandr Andrushchenko wrote: > This is the sync up with the canonical definition of the sound > protocol in Xen: > > 1. Protocol version was referenced in the protocol description, >but missed its definition. Fixed by adding a constant >for current protocol version. > > 2. Some of the request descriptions have "reserved" fields >missed: fixed by adding corresponding entries. > > 3. Extend the size of the requests and responses to 64 octets. >Bump protocol version to 2. > > 4. Add explicit back and front synchronization >In order to provide explicit synchronization between backend and >frontend the following changes are introduced in the protocol: > - add new ring buffer for sending asynchronous events from > backend to frontend to report number of bytes played by the > frontend (XENSND_EVT_CUR_POS) > - introduce trigger events for playback control: start/stop/pause/resume > - add "req-" prefix to event-channel and ring-ref to unify naming > of the Xen event channels for requests and events > > 5. Add explicit back and front parameter negotiation >In order to provide explicit stream parameter negotiation between >backend and frontend the following changes are introduced in the protocol: >add XENSND_OP_HW_PARAM_QUERY request to read/update >configuration space for the parameters given: request passes >desired parameter's intervals/masks and the response to this request >returns allowed min/max intervals/masks to be used. > > Signed-off-by: Oleksandr Andrushchenko > Signed-off-by: Oleksandr Grytsov > Cc: Konrad Rzeszutek Wilk > Cc: Takashi Iwai > Applied to for-linus-4.17 -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe
On 04/09/2018 11:03 AM, Jia-Ju Bai wrote: > pcistub_probe() is never called in atomic context. > This function is only set as ".probe" in struct pci_driver. > > Despite never getting called from atomic context, > pcistub_probe() calls kmalloc() with GFP_ATOMIC, > which does not sleep for allocation. > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, > which can sleep and improve the possibility of sucessful allocation. > > This is found by a static analysis tool named DCNS written by myself. > And I also manually check it. > > Signed-off-by: Jia-Ju Bai > Applied the series and the extra patch to for-linus-4.17 -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On 04/17/2018 03:21 PM, Razvan Cojocaru wrote: > On 04/17/2018 04:53 PM, George Dunlap wrote: >> On 04/17/2018 11:50 AM, Razvan Cojocaru wrote: >>> void p2m_init_altp2m_ept(struct domain *d, unsigned int i) >>> { >>> struct p2m_domain *p2m = d->arch.altp2m_p2m[i]; >>> +struct p2m_domain *hostp2m = p2m_get_hostp2m(d); >>> struct ept_data *ept; >>> >>> +p2m->max_mapped_pfn = hostp2m->max_mapped_pfn; >>> +p2m->default_access = hostp2m->default_access; >>> +p2m->domain = hostp2m->domain; >>> +p2m->logdirty_ranges = hostp2m->logdirty_ranges; >>> +p2m->global_logdirty = hostp2m->global_logdirty; >> >> This would certainly be one approach. But then we'd need to keep a lot >> more of these things in sync -- for instance, we'd have to have similar >> code to enable and disable global_logdirty on all active altp2m entries. >> >> I also don't think the max_mapped_pfn should be copied here; the fact >> that updates got filtered out before was a red herring I think. > > I initially thought so too, and now I've commented out just that one > line to remember why I couldn't remove, and the reason is this: > > (XEN) Assertion 's <= e' failed at rangeset.c:121 > (XEN) [ Xen-4.11-unstable x86_64 debug=y Not tainted ] > (XEN) CPU:0 > (XEN) RIP:e008:[] rangeset_add_range+0x5/0x1e6 > (XEN) RFLAGS: 00010206 CONTEXT: hypervisor (d0v0) > (XEN) rax: rbx: 830b577f92e0 rcx: 000f > (XEN) rdx: rsi: 000f rdi: 830ad6a1ce50 > (XEN) rbp: 83007ce87c78 rsp: 83007ce87c20 r8: > (XEN) r9: r10: 006f r11: 0028 > (XEN) r12: 0002 r13: r14: 0001 > (XEN) r15: 830ad6ddd000 cr0: 80050033 cr4: 003526e0 > (XEN) cr3: 000ad714f000 cr2: 00c12000 > (XEN) fsb: 7f794c7b2700 gsb: 880276c0 gss: > (XEN) ds: es: fs: gs: ss: e010 cs: e008 > (XEN) Xen code around (rangeset_add_range+0x5/0x1e6): > (XEN) 00 5d c3 48 39 d6 76 02 <0f> 0b 55 48 89 e5 41 56 41 55 41 54 53 > 49 89 d5 > (XEN) Xen stack trace from rsp=83007ce87c20: > (XEN)82d08032c644 0206 0010 0028 > (XEN)000f 82c000217000 830ad6ddd000 > (XEN)000f0240 0002 83007ce87cc8 > (XEN)82d08032c7ac 0240 000f 82c000217000 > (XEN)830ad6ddd000 000f0240 0048 82c000217000 > (XEN)000f 83007ce87d38 82d080362ade 830c5bb2 > (XEN)830ad6ddd650 7f794c7bd004 > (XEN)0048 830c5bb2 83007ce87e00 > (XEN)ffea 82d0802e9c64 deadbeefdeadf00d 83007ce87de8 > (XEN)82d0802e92c1 830c5bb2 83007d616000 > (XEN)83007ce87dd8 83007ce87df8 83007ce87df4 > (XEN)82e016a5de40 83007d616000 0007 0240 > (XEN)000f 83007ce87dc8 830ad6ddd000 83007ce87dc8 > (XEN)0002 0001 7f794c7bf004 82d0802e9c64 > (XEN)deadbeefdeadf00d 83007ce87e48 82d0802e9ce1 82d080374434 > (XEN)000280370001 7f794c7be004 0020 7f794c7bd004 > (XEN)0048 82d080374434 83007ce87ef8 83007d616000 > (XEN)0029 83007ce87ee8 82d08036d8a6 03ff82d080374434 > (XEN)0001 0002 7f794c7bf004 deadbeefdeadf00d > (XEN)deadbeefdeadf00d 82d080374434 82d080374428 82d080374434 > (XEN) Xen call trace: > (XEN)[] rangeset_add_range+0x5/0x1e6 > (XEN)[] p2m_change_type_range+0x66/0x7f > (XEN)[] hap_track_dirty_vram+0x240/0x491 > (XEN)[] dm.c#dm_op+0x45c/0xd06 > (XEN)[] do_dm_op+0x7d/0xb3 > (XEN)[] pv_hypercall+0x1f4/0x440 > (XEN)[] lstar_enter+0x115/0x120 > (XEN) > (XEN) > (XEN) > (XEN) Panic on CPU 0: > (XEN) Assertion 's <= e' failed at rangeset.c:121 > (XEN) Right, but this is basically a bug in p2m_change_type_range(), where it handles end > max_mapped_pfn, but not start > max_mapped_pfn. It should check the latter just after grabbing the lock and bail if true. (This should probably be in a separate patch, as it's really a generic bug in p2m_change_type_range().) >> Another approach would be to maintain the logdirty_ranges and >> global_logdirty only for the host p2m, but to misconfigure entries for >> all the p2ms; and then on a misconfiguration, handle the >> misconfiguration for the hostp2m and then do a lazy propagate for the >> altp2m. On the whole that's probably more error-prone than ju
Re: [Xen-devel] [PATCH 7/7] docs/parse-support-md: Correctly handle footnotes for non-leaf sections
On 17/04/18 16:47, Ian Jackson wrote: > Non-leaf sections with footnotes must have a row of their own, for > just that section, because footnotes only appear if there is status > information. > > In that case, the footnote applies to only the rows for that section > in the markdown document, ie that RealSect. > > And of course for a leaf section that is true too. > > So for footnoes we always want to use a rowspan of the number of > Status elements in the section. So (i) calculate this in > count_rows_sectlist and (ii) use it, instead of the total number of > rows including all the subsections', when writing out the footnote > ref. > > This bug has been present in this script since the beginning. > > Also, while we're here, suppress the rowspan if it would be 1. > > Reported-by: Lars Kurth > Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/msr: further correct the emulation behaviour of MSR_PRED_CMD
On 17/04/18 13:45, Jan Beulich wrote: On 17.04.18 at 14:30, wrote: >> On 17/04/18 12:41, Jan Beulich wrote: >>> Following commit a6aa678fa3 ("x86/msr: Correct the emulation behaviour >>> of MSR_PRED_CMD") we may end up writing the low bit with the wrong >>> value. While it's unlikely for a guest to want to write zero there, we >>> should still permit (this without incurring the overhead of an actual >>> barrier). Correcting this right away will also help whenever further >>> bits in the MSR might become defined. >>> >>> Signed-off-by: Jan Beulich >>> >>> --- a/xen/arch/x86/msr.c >>> +++ b/xen/arch/x86/msr.c >>> @@ -247,7 +247,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t >>> goto gp_fault; /* Rsvd bit set? */ >>> >>> if ( v == curr ) >>> -wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB); >>> +wrmsrl(MSR_PRED_CMD, val); >> I was on the fence about making this change, because if the reserved bit >> testing happens to be wrong, we might suffer a fatal #GP here. >> >> Then again, the same could be said of the the CPUID check and explicit >> use of PRED_CMD_IBPB. >> >> I also wondered if we would be better using wrmsr_safe() to cope better >> in release situations, where at least bad logic here would result in >> host crash. > Any of this likely would equally be an issue for some other MSRs, > and I think that's orthogonal to the change (with the given description) > here: It is clearly wrong to write bit 0 with 1 when the original guest > value has the bit clear. If anything I could agree to writing > val & PRED_CMD_IBPB, but that's then obviously redundant with the > check immediately ahead of the write. The only time we will see 0 here is in my XTF test cases, but I accept your point. Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/7] docs/parse-support.md: Add some newlines to the table output
On 17/04/18 16:47, Ian Jackson wrote: > This makes the result easier for humans to read. > > Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] xen/pt: use address_space_memory object for memory region hooks
Commit 99605175c (xen-pt: Fix PCI devices re-attach failed) introduced a subtle bug. As soon as the guest switches off Bus Mastering on the device it immediately causes all the BARs be unmapped due to the DMA address space of the device being changed. This is undesired behavior because the guest may try to communicate with the device after that which triggers the following errors in the logs: [00:05.0] xen_pt_bar_read: Error: Should not read BAR through QEMU. @0x0200 [00:05.0] xen_pt_bar_write: Error: Should not write BAR through QEMU. @0x0200 The issue that the original patch tried to workaround (uneven number of region_add/del calls on device attach/detach) was fixed in d25836cafd (memory: do explicit cleanup when remove listeners). Signed-off-by: Igor Druzhinin Reported-by: Ross Lagerwall Acked-by: Anthony PERARD --- Changes in v2: * specify the exact fixing commit in the commit message --- hw/xen/xen_pt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index 9b7a960..e5a6eff 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -907,7 +907,7 @@ out: } } -memory_listener_register(&s->memory_listener, &s->dev.bus_master_as); +memory_listener_register(&s->memory_listener, &address_space_memory); memory_listener_register(&s->io_listener, &address_space_io); s->listener_set = true; XEN_PT_LOG(d, -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 7/7] docs/parse-support-md: Correctly handle footnotes for non-leaf sections
Non-leaf sections with footnotes must have a row of their own, for just that section, because footnotes only appear if there is status information. In that case, the footnote applies to only the rows for that section in the markdown document, ie that RealSect. And of course for a leaf section that is true too. So for footnoes we always want to use a rowspan of the number of Status elements in the section. So (i) calculate this in count_rows_sectlist and (ii) use it, instead of the total number of rows including all the subsections', when writing out the footnote ref. This bug has been present in this script since the beginning. Also, while we're here, suppress the rowspan if it would be 1. Reported-by: Lars Kurth Signed-off-by: Ian Jackson --- v2: New patch Signed-off-by: Ian Jackson --- docs/parse-support-md | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/docs/parse-support-md b/docs/parse-support-md index 615..218e12b 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -296,7 +296,11 @@ sub count_rows_sectlist ($); sub count_rows_sectnode ($) { my ($sectnode) = @_; my $rows = 0; -$rows++ if $sectnode->{Status}; +$sectnode->{RealSect}{OwnRows} //= 0; +if ($sectnode->{Status}) { +$rows++; +$sectnode->{RealSect}{OwnRows}++; +} $rows += count_rows_sectlist $sectnode->{Children}; $sectnode->{Rows} = $rows; $sectnode->{RealSect}{Rows} = $rows; @@ -306,6 +310,7 @@ sub count_rows_sectnode ($) { # Now we have # $sectnode->{Rows} # $sectnode->{RealSect}{Rows} +# $sectnode->{RealSect}{OwnRows} sub count_rows_sectlist ($) { my ($sectlist) = @_; @@ -388,8 +393,10 @@ sub write_output_row ($) { $colspan= ' colspan="2"'; if ($sectnode->{RealSect}{HasCaveat}[$i] && $st && $sectnode->{RealSect}{Anchor}) { -my $rows = $sectnode->{RealSect}{Rows}; -$nextcell = sprintf '', $rows; +my $rows = $sectnode->{RealSect}{OwnRows}; +$nextcell = '1; +$nextcell .= '>'; $nextcell .= docref_a $i, $sectnode->{RealSect}; $nextcell .= '[*]'; $nextcell .= ''; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 6/7] docs/parse-support.md: Add some newlines to the table output
This makes the result easier for humans to read. Signed-off-by: Ian Jackson --- v2: New patch --- docs/parse-support-md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/parse-support-md b/docs/parse-support-md index 653d216..615 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -399,7 +399,7 @@ sub write_output_row ($) { } $st //= '-'; -o(""); +o("\n"); my $end_a = ''; if ($sectnode->{Key} eq 'release-support--xen-version') { o(sprintf '', $version_urls[$i]); -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/7] docs/parse-support-md: internals: Introduce docref_a
No functional change. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross --- docs/parse-support-md | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/parse-support-md b/docs/parse-support-md index decda33..5bf8405 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -318,6 +318,12 @@ sub o { print @_ or die $!; } our @pending_headings; +sub docref_a ($$) { +my ($i, $realsect) = @_; +return sprintf '', +$version_urls[$i], $realsect->{Anchor}; +} + sub write_output_row ($) { my ($sectnode) = @_; #print STDERR 'WOR ', Dumper($d, $sectnode); @@ -364,8 +370,8 @@ sub write_output_row ($) { && $sectnode->{RealSect}{Anchor}) { my $rows = $sectnode->{RealSect}{Rows}; $nextcell = sprintf '', $rows; -$nextcell .= sprintf '[*]', -$version_urls[$i], $sectnode->{RealSect}{Anchor}; +$nextcell .= docref_a $i, $sectnode->{RealSect}; +$nextcell .= '[*]'; $nextcell .= ''; $colspan = ''; } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/7] SUPPORT.md: Distinguish descriptions from caveats
The new support matrix output puts a [*] after each entry in the support matrix in many cases where the linked-to text is simply a longer description of the feature. Remedy this by distinguishing text which expands on a feature description from text which qualifies its support status. There are 3 patches to processing machinery, followed by two patches to SUPPORT.md (one to make the distinction, throughout, and one to document it); followed by two patches to fix a bug (logically these should come first, but rebasing them is annoying). The patches to SUPPORT.md would ideally go to 4.10 too. Example output: https://xenbits.xen.org/people/iwj/2018/support-matrix-example-B-v2/t.html r 1/7 docs/parse-support-md: internals: Introduce docref_a r 2/7 docs/parse-support-md: internals: Rename HasText to r 3/7 SUPPORT.md, support matrix: Treat commentary before *r 4/7 SUPPORT.md: Move descriptions up before Status info a r 5/7 SUPPORT.md: Document the new text ordering rule + 6/7 docs/parse-support.md: Add some newlines to the table + 7/7 docs/parse-support-md: Correctly handle footnotes for + = New patch in v2 * = Amended patch in v2 r = Release-acked a = Acked by appropriate maintainer and/or community manager ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/7] docs/parse-support-md: internals: Rename HasText to HasCaveat
No functional change. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross --- docs/parse-support-md | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/parse-support-md b/docs/parse-support-md index 5bf8405..6953930 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -34,7 +34,7 @@ our $toplevel_sectlist = new_sectlist(); # $sectlist->{KEY}{Children} = a further $sectlist # $sectlist->{KEY}{Key} = KEY # $sectlist->{KEY}{RealSect} = containing real section in @insections, so -# $sectlist->{KEY}{RealSect}{HasText}[VI] = trueish iff there was a Para +# $sectlist->{KEY}{RealSect}{HasCaveat}[VI] = trueish iff other in a Para # $sectlist->{KEY}{RealSect}{Anchor} = value for < id="" > in the pandoc html # A $sectnode represents a single section from the original markdown # document. Its subsections are in Children. @@ -57,7 +57,7 @@ our @insections; # $insections[]{Headline} = markdown content # these next are only defined for real sections, not Status elements # $insections[]{Anchor} = string -# $insections[]{HasText} = array, $sectlist->{HasText} will refer to this +# $insections[]{HasCaveat} = array, $sectlist->{HasCaveat} will refer to this our $had_unknown; # adding new variable ? it must be reset in r_toplevel @@ -77,14 +77,14 @@ sub ri_Header { Key => $id, Anchor => $id, Headline => $hl, - HasText => [], + HasCaveat => [], }; #print STDERR Dumper(\@insections); } sub ri_Para { if (@insections) { -$insections[$#insections]{HasText}[$version_index] = 1; +$insections[$#insections]{HasCaveat}[$version_index] = 1; } }; @@ -366,7 +366,7 @@ sub write_output_row ($) { my $nextcell = ''; if (!defined $colspan) { # first row of this RealSect $colspan= ' colspan="2"'; -if ($sectnode->{RealSect}{HasText}[$i] && $st +if ($sectnode->{RealSect}{HasCaveat}[$i] && $st && $sectnode->{RealSect}{Anchor}) { my $rows = $sectnode->{RealSect}{Rows}; $nextcell = sprintf '', $rows; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5/7] SUPPORT.md: Document the new text ordering rule
Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross --- SUPPORT.md | 5 + 1 file changed, 5 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index 3e3890b..9eb6958 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -725,6 +725,11 @@ The file is in markdown format. The machine-readable fragments are markdown literals containing RFC-822-like (deb822-like) data. +In each case, descriptions which expand on the name of a feature as +provided in the section heading, precede the Status indications. +Any paragraphs which follow the Status indication are caveats or +qualifications of the information provided in Status fields. + ## Keys found in the Feature Support subsections ### Status -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/7] SUPPORT.md, support matrix: Treat commentary before status as description
Running text in feature sections in the markdown document currently might be (i) a caveat, qualifying or clarifying the support statement (ii) a plain description of the feature. Caveats can be version-specific and deserve the [*] annotation in the relevant feature matrix cell. They must link to SUPPORT.html for the specific version. Descriptions are not version specific. In that case the [*] annotation is visusal noise. Rather, it is better to make a hyperlink out of the text which is being expanded on. The hyperlink can point to any appropriate version. There is a question about how to notate this distinction in SUPPORT.md. After IRL discussion with George and Lars I propose that we should put text which helps describe a feature (ie, which expands on a section heading) after the heading but before the Status indications; whereas, caveats and supplementary information about the actual status, should follow the Status block. This patch implements this distinction in the support matrix generator. Only paragraphs containing _only_ italic content count as descriptive; anything else is treated as a caveat. In the code: * Add a new entry to RealSect, HasDescription * When parsing, track whether we are before or after the first Status block in a new variable $has_feature. * In ri_Para, set HasDescription set to the input document index when we encounter text before the first feature. * When writing a `heading' (ie, the table cell for a feature name) look for HasDescription and make an appropriate hyperlink. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross --- docs/parse-support-md | 24 ++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/docs/parse-support-md b/docs/parse-support-md index 6953930..653d216 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -35,6 +35,7 @@ our $toplevel_sectlist = new_sectlist(); # $sectlist->{KEY}{Key} = KEY # $sectlist->{KEY}{RealSect} = containing real section in @insections, so # $sectlist->{KEY}{RealSect}{HasCaveat}[VI] = trueish iff other in a Para +# $sectlist->{KEY}{RealSect}{HasDescription} = VI for some Emph in Para # $sectlist->{KEY}{RealSect}{Anchor} = value for < id="" > in the pandoc html # A $sectnode represents a single section from the original markdown # document. Its subsections are in Children. @@ -58,8 +59,10 @@ our @insections; # these next are only defined for real sections, not Status elements # $insections[]{Anchor} = string # $insections[]{HasCaveat} = array, $sectlist->{HasCaveat} will refer to this +# $insections[]{HasDescription} VI, likewise our $had_unknown; +our $had_feature; # adding new variable ? it must be reset in r_toplevel #-- parsing -- @@ -78,13 +81,20 @@ sub ri_Header { Anchor => $id, Headline => $hl, HasCaveat => [], + HasDescription => undef, }; #print STDERR Dumper(\@insections); +$had_feature = 0; } sub ri_Para { -if (@insections) { -$insections[$#insections]{HasCaveat}[$version_index] = 1; +return unless @insections; +my $insection = $insections[$#insections]; + +if ($had_feature) { +$insection->{HasCaveat}[$version_index] = 1; +} else { +$insection->{HasDescription} //= $version_index; } }; @@ -92,6 +102,8 @@ sub parse_feature_entry ($) { my ($value) = @_; die unless @insections; +$had_feature = 1; + my $sectnode; my $realsect; foreach my $s (@insections) { @@ -183,6 +195,7 @@ sub r_toplevel ($) { @insections = (); $had_unknown = undef; +$had_feature = undef; foreach my $e (@$i) { next unless ref $e eq 'ARRAY'; @@ -346,7 +359,14 @@ sub write_output_row ($) { $span->('col', $maxdepth - $heading->{Depth} + 1) if !%{ $heading->{Children} }; o(' align="left">'); +my $end_a = ''; +my $desc_i = $heading->{RealSect}{HasDescription}; +if (defined $desc_i) { +o(docref_a $desc_i, $heading->{RealSect}); +$end_a= ''; +} o($heading->{Headline}); +o($end_a); o(''); } if (%{ $sectnode->{Children} }) { -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/7] SUPPORT.md: Move descriptions up before Status info
This turns all the things which were treated as caveats, but which don't need to be footnoted in the matrix, into descriptions. For the benefit of the support matrix generator, this patch (or a version of it) should be backported to 4.10. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross --- v2: Move definition of "PV Console (frontend) too" --- SUPPORT.md | 217 - 1 file changed, 113 insertions(+), 104 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index 264b23f..3e3890b 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -58,32 +58,29 @@ for the definitions of the support status levels etc. ### ARM/GICv3 ITS -Status: Experimental - Extension to the GICv3 interrupt controller to support MSI. +Status: Experimental + ## Guest Type ### x86/PV -Status: Supported - Traditional Xen PV guest No hardware requirements -### x86/HVM +Status: Supported -Status, domU: Supported +### x86/HVM Fully virtualised guest using hardware virtualisation extensions Requires hardware virtualisation support (Intel VMX / AMD SVM) -### x86/PVH - Status, domU: Supported -Status, dom0: Experimental + +### x86/PVH PVH is a next-generation paravirtualized mode designed to take advantage of hardware virtualization support when possible. @@ -93,12 +90,15 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM). Dom0 support requires an IOMMU (Intel VT-d / AMD IOMMU). -### ARM +Status, domU: Supported +Status, dom0: Experimental -Status: Supported +### ARM ARM only has one guest type at the moment +Status: Supported + ## Toolstack ### xl @@ -107,12 +107,12 @@ ARM only has one guest type at the moment ### Direct-boot kernel image format +Format which the toolstack accepts for direct-boot kernels + Supported, x86: bzImage, ELF Supported, ARM32: zImage Supported, ARM64: Image -Format which the toolstack accepts for direct-boot kernels - ### Dom0 init support for xl Status, SysV: Supported @@ -121,10 +121,10 @@ Format which the toolstack accepts for direct-boot kernels ### JSON output support for xl -Status: Experimental - Output of information in machine-parseable JSON format +Status: Experimental + ### Open vSwitch integration for xl Status, Linux: Supported @@ -157,17 +157,18 @@ Output of information in machine-parseable JSON format ### Hypervisor 'debug keys' -Status: Supported, not security supported - These are functions triggered either from the host serial console, or via the xl 'debug-keys' command, which cause Xen to dump various hypervisor state to the console. +Status: Supported, not security supported + ### Hypervisor synchronous console output (sync_console) +Xen command-line flag to force synchronous console output. + Status: Supported, not security supported -Xen command-line flag to force synchronous console output. Useful for debugging, but not suitable for production environments due to incurred overhead. @@ -179,56 +180,54 @@ Debugger to debug ELF guests ### Soft-reset for PV guests -Status: Supported - Soft-reset allows a new kernel to start 'from scratch' with a fresh VM state, but with all the memory from the previous state of the VM intact. This is primarily designed to allow "crash kernels", which can do core dumps of memory to help with debugging in the event of a crash. -### xentrace +Status: Supported -Status, x86: Supported +### xentrace Tool to capture Xen trace buffer data -### gcov +Status, x86: Supported -Status: Supported, Not security supported +### gcov Export hypervisor coverage data suitable for analysis by gcov or lcov. +Status: Supported, Not security supported + ## Memory Management ### Dynamic memory control -Status: Supported - Allows a guest to add or remove memory after boot-time. This is typically done by a guest kernel agent known as a "balloon driver". -### Populate-on-demand memory +Status: Supported -Status, x86 HVM: Supported +### Populate-on-demand memory This is a mechanism that allows normal operating systems with only a balloon driver to boot with memory < maxmem. -### Memory Sharing +Status, x86 HVM: Supported -Status, x86 HVM: Expermental +### Memory Sharing Allow sharing of identical pages between guests -### Memory Paging +Status, x86 HVM: Expermental -Status, x86 HVM: Experimenal +### Memory Paging Allow pages belonging to guests to be paged to disk -### Transcendent Memory +Status, x86 HVM: Experimenal -Status: Experimental +### Transcendent Memory Transcendent Memory (tmem) allows the creation of hypervisor memory pools which guests can use to store memory @@ -236,96 +235,100 @@ rather than caching in its own memory or swapping to disk. Having these in the hypervisor can allow more efficient aggregate
Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks
On Tue, Apr 17, 2018 at 03:18:55PM +0100, Igor Druzhinin wrote: > On 17/04/18 15:15, Anthony PERARD wrote: > > On Fri, Apr 06, 2018 at 10:21:23PM +0100, Igor Druzhinin wrote: > >> The issue that the original patch tried to workaround (uneven number of > >> region_add/del calls on device attach/detach) was fixed in later QEMU > >> versions. > > > > Do you know when the issue was fixed? > > > > I haven't tracked down a particular version but the previous behavior of > memory_listener_unregister() was to remove the listener from the list > without calling the callback. It has changed since then and now the > callback is called in listener_del_address_space(). On Tue, Apr 17, 2018 at 03:29:42PM +0100, Igor Druzhinin wrote: > I think it's this commit: > > commit d25836cafd7508090d211e97acfc0abc5ae88daa > Author: Peter Xu > Date: Mon Jan 22 14:02:44 2018 +0800 > > memory: do explicit cleanup when remove listeners I think these information ought to be in the commit message, in particular the fact that the callback wasn't call on detach. And with the commit message updated, you can add my: Acked-by: Anthony PERARD Thanks, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 74629: all pass
This run is configured for baseline tests only. flight 74629 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74629/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 5e0e476a9542a1f769fd5325c0be2d16d3ad1d42 baseline version: ovmf d4ee449d1dabee20fc36650545143a5430fa718f Last test of basis74627 2018-04-16 22:48:23 Z0 days Testing same since74629 2018-04-17 06:19:50 Z0 days1 attempts People who touched revisions under test: Laszlo Ersek 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 5e0e476a9542a1f769fd5325c0be2d16d3ad1d42 Author: Laszlo Ersek Date: Sun Apr 15 22:34:47 2018 +0200 OvmfPkg/PlatformBootManagerLib: add USB keyboard to ConIn PlatformInitializeConsole() (called by PlatformBootManagerBeforeConsole()) adds elements of "gPlatformConsole" to ConIn / ConOut / ErrOut (as requested per element) if at boot at least one of ConIn and ConOut doesn't exist. This typically applies to new VMs, and VMs with freshly recreated varstores. Add a USB keyboard wildcard to ConIn via "gPlatformConsole", so that we not only bind the PS/2 keyboard. (The PS/2 keyboard is added in PrepareLpcBridgeDevicePath()). Explicitly connecting the USB keyboard is necessary after commit 245c643cc8b7. Cc: Ard Biesheuvel Cc: Jordan Justen Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks
On 17/04/18 15:15, Anthony PERARD wrote: > On Fri, Apr 06, 2018 at 10:21:23PM +0100, Igor Druzhinin wrote: >> Commit 99605175c (xen-pt: Fix PCI devices re-attach failed) introduced >> a subtle bug. As soon as the guest switches off Bus Mastering on the >> device it immediately causes all the BARs be unmapped due to the DMA >> address space of the device being changed. This is undesired behavior >> because the guest may try to communicate with the device after that >> which triggers the following errors in the logs: >> >> [00:05.0] xen_pt_bar_read: Error: Should not read BAR through QEMU. >> @0x0200 >> [00:05.0] xen_pt_bar_write: Error: Should not write BAR through QEMU. >> @0x0200 >> >> The issue that the original patch tried to workaround (uneven number of >> region_add/del calls on device attach/detach) was fixed in later QEMU >> versions. > > Do you know when the issue was fixed? > I think it's this commit: commit d25836cafd7508090d211e97acfc0abc5ae88daa Author: Peter Xu Date: Mon Jan 22 14:02:44 2018 +0800 memory: do explicit cleanup when remove listeners Igor ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/msr: further correct the emulation behaviour of MSR_PRED_CMD
On 17/04/18 13:41, Jan Beulich wrote: > Following commit a6aa678fa3 ("x86/msr: Correct the emulation behaviour > of MSR_PRED_CMD") we may end up writing the low bit with the wrong > value. While it's unlikely for a guest to want to write zero there, we > should still permit (this without incurring the overhead of an actual > barrier). Correcting this right away will also help whenever further > bits in the MSR might become defined. > > Signed-off-by: Jan Beulich Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] libs/gnttab: fix FreeBSD gntdev interface
On 17/04/18 15:03, Roger Pau Monne wrote: > Current interface to the gntdev in FreeBSD is wrong, and mostly worked > out of luck before the PTI FreeBSD fixes, when kernel and user-space > where sharing the same page tables. > > On FreeBSD ioctls have the size of the passed struct encoded in the ioctl > number, because the generic ioctl handler in the OS takes care of > copying the data from user-space to kernel space, and then calls the > device specific ioctl handler. Thus using ioctl structs with variable > sizes is not possible. > > The fix is to turn the array of structs at the end of > ioctl_gntdev_alloc_gref and ioctl_gntdev_map_grant_ref into pointers, > that can be properly accessed from the kernel gntdev driver using the > copyin/copyout functions. Note that this is exactly how it's done for > the privcmd driver. > > Signed-off-by: Roger Pau Monné Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On 04/17/2018 04:53 PM, George Dunlap wrote: > On 04/17/2018 11:50 AM, Razvan Cojocaru wrote: >> void p2m_init_altp2m_ept(struct domain *d, unsigned int i) >> { >> struct p2m_domain *p2m = d->arch.altp2m_p2m[i]; >> +struct p2m_domain *hostp2m = p2m_get_hostp2m(d); >> struct ept_data *ept; >> >> +p2m->max_mapped_pfn = hostp2m->max_mapped_pfn; >> +p2m->default_access = hostp2m->default_access; >> +p2m->domain = hostp2m->domain; >> +p2m->logdirty_ranges = hostp2m->logdirty_ranges; >> +p2m->global_logdirty = hostp2m->global_logdirty; > > This would certainly be one approach. But then we'd need to keep a lot > more of these things in sync -- for instance, we'd have to have similar > code to enable and disable global_logdirty on all active altp2m entries. > > I also don't think the max_mapped_pfn should be copied here; the fact > that updates got filtered out before was a red herring I think. I initially thought so too, and now I've commented out just that one line to remember why I couldn't remove, and the reason is this: (XEN) Assertion 's <= e' failed at rangeset.c:121 (XEN) [ Xen-4.11-unstable x86_64 debug=y Not tainted ] (XEN) CPU:0 (XEN) RIP:e008:[] rangeset_add_range+0x5/0x1e6 (XEN) RFLAGS: 00010206 CONTEXT: hypervisor (d0v0) (XEN) rax: rbx: 830b577f92e0 rcx: 000f (XEN) rdx: rsi: 000f rdi: 830ad6a1ce50 (XEN) rbp: 83007ce87c78 rsp: 83007ce87c20 r8: (XEN) r9: r10: 006f r11: 0028 (XEN) r12: 0002 r13: r14: 0001 (XEN) r15: 830ad6ddd000 cr0: 80050033 cr4: 003526e0 (XEN) cr3: 000ad714f000 cr2: 00c12000 (XEN) fsb: 7f794c7b2700 gsb: 880276c0 gss: (XEN) ds: es: fs: gs: ss: e010 cs: e008 (XEN) Xen code around (rangeset_add_range+0x5/0x1e6): (XEN) 00 5d c3 48 39 d6 76 02 <0f> 0b 55 48 89 e5 41 56 41 55 41 54 53 49 89 d5 (XEN) Xen stack trace from rsp=83007ce87c20: (XEN)82d08032c644 0206 0010 0028 (XEN)000f 82c000217000 830ad6ddd000 (XEN)000f0240 0002 83007ce87cc8 (XEN)82d08032c7ac 0240 000f 82c000217000 (XEN)830ad6ddd000 000f0240 0048 82c000217000 (XEN)000f 83007ce87d38 82d080362ade 830c5bb2 (XEN)830ad6ddd650 7f794c7bd004 (XEN)0048 830c5bb2 83007ce87e00 (XEN)ffea 82d0802e9c64 deadbeefdeadf00d 83007ce87de8 (XEN)82d0802e92c1 830c5bb2 83007d616000 (XEN)83007ce87dd8 83007ce87df8 83007ce87df4 (XEN)82e016a5de40 83007d616000 0007 0240 (XEN)000f 83007ce87dc8 830ad6ddd000 83007ce87dc8 (XEN)0002 0001 7f794c7bf004 82d0802e9c64 (XEN)deadbeefdeadf00d 83007ce87e48 82d0802e9ce1 82d080374434 (XEN)000280370001 7f794c7be004 0020 7f794c7bd004 (XEN)0048 82d080374434 83007ce87ef8 83007d616000 (XEN)0029 83007ce87ee8 82d08036d8a6 03ff82d080374434 (XEN)0001 0002 7f794c7bf004 deadbeefdeadf00d (XEN)deadbeefdeadf00d 82d080374434 82d080374428 82d080374434 (XEN) Xen call trace: (XEN)[] rangeset_add_range+0x5/0x1e6 (XEN)[] p2m_change_type_range+0x66/0x7f (XEN)[] hap_track_dirty_vram+0x240/0x491 (XEN)[] dm.c#dm_op+0x45c/0xd06 (XEN)[] do_dm_op+0x7d/0xb3 (XEN)[] pv_hypercall+0x1f4/0x440 (XEN)[] lstar_enter+0x115/0x120 (XEN) (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) Assertion 's <= e' failed at rangeset.c:121 (XEN) > Another approach would be to maintain the logdirty_ranges and > global_logdirty only for the host p2m, but to misconfigure entries for > all the p2ms; and then on a misconfiguration, handle the > misconfiguration for the hostp2m and then do a lazy propagate for the > altp2m. On the whole that's probably more error-prone than just doing a > for() loop, though, and not that much faster. :-) We can try that too. > The other thing that seems to be missing from synchronization is that in > p2m-ept.c:ept_enable_pml() sets the p2m->ept.ad bit (which ends up being > part of the eptp). The code seems to indicate that this is required for > PML (hardware-assisted logdirty), but I don't see anywhere this is set > or copied from the host p2m. > > It might be nice to have a more structured way of keeping all these > changes i
Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks
On 17/04/18 15:15, Anthony PERARD wrote: > On Fri, Apr 06, 2018 at 10:21:23PM +0100, Igor Druzhinin wrote: >> Commit 99605175c (xen-pt: Fix PCI devices re-attach failed) introduced >> a subtle bug. As soon as the guest switches off Bus Mastering on the >> device it immediately causes all the BARs be unmapped due to the DMA >> address space of the device being changed. This is undesired behavior >> because the guest may try to communicate with the device after that >> which triggers the following errors in the logs: >> >> [00:05.0] xen_pt_bar_read: Error: Should not read BAR through QEMU. >> @0x0200 >> [00:05.0] xen_pt_bar_write: Error: Should not write BAR through QEMU. >> @0x0200 >> >> The issue that the original patch tried to workaround (uneven number of >> region_add/del calls on device attach/detach) was fixed in later QEMU >> versions. > > Do you know when the issue was fixed? > I haven't tracked down a particular version but the previous behavior of memory_listener_unregister() was to remove the listener from the list without calling the callback. It has changed since then and now the callback is called in listener_del_address_space(). Igor ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks
On Fri, Apr 06, 2018 at 10:21:23PM +0100, Igor Druzhinin wrote: > Commit 99605175c (xen-pt: Fix PCI devices re-attach failed) introduced > a subtle bug. As soon as the guest switches off Bus Mastering on the > device it immediately causes all the BARs be unmapped due to the DMA > address space of the device being changed. This is undesired behavior > because the guest may try to communicate with the device after that > which triggers the following errors in the logs: > > [00:05.0] xen_pt_bar_read: Error: Should not read BAR through QEMU. > @0x0200 > [00:05.0] xen_pt_bar_write: Error: Should not write BAR through QEMU. > @0x0200 > > The issue that the original patch tried to workaround (uneven number of > region_add/del calls on device attach/detach) was fixed in later QEMU > versions. Do you know when the issue was fixed? -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario
On 17/04/18 13:54, Mirela Simonovic wrote: Hi Julien, Hi, On Wed, Apr 11, 2018 at 5:11 PM, Julien Grall wrote: Hi, On 11/04/18 14:19, Mirela Simonovic wrote: In existing code the paging for secondary CPUs is setup only in boot flow. The setup is triggered from start_xen function after all CPUs are brought online. In other words, the initialization of VTCR_EL2 register is done out of the cpu_up/start_secondary control flow. However, the cpu_up flow should be self-contained - it should fully initialize a secondary CPU, because the cpu_up is used not only to bring a secondary CPU online on boot, but also to hotplug a CPU during the system resume. With this patch the setting of paging is triggered from start_secondary function if the current system state is not boot. This way, the paging will be setup in non-boot scenarios, while the setup in boot scenario remains unchanged. I am afraid that this is not correct. You can't assume that value chosen for VTCR by Xen at boot will fit this new CPU. So you have to check it is fine or park the CPU if there are any issue. This is not a new CPU. This CPU already went through its boot sequence and it reached the resume point because it does fit the value chosen for VTCR by Xen. If it wouldn't fit the chosen value for VTCR it would be parked so it wouldn't participate in suspend/resume. Please let me know if I misunderstood your comment. This is not a new CPU for your use case. However your commit message speak about "non-boot" CPU bring-up. So for me this is more than suspend/resume, it is about bringing-up CPU at any time. As those CPUs can't participate to the decision (it is too late), you need to make sure the VTCR will fit on that CPU. AFAIU the value chosen by Xen for VTCR config has to be common for all online CPUs. Since this value is also used in the resume path I suggest to make global (static in the p2m.c) the 'val' variable which is currently local in setup_virt_paging() and passed as argument to setup_virt_paging_one(). Then setup_virt_paging_one() would not receive an argument. I need to access this value on resume, so I would call setup_virt_paging_one() without argument from start_secondary() if the system state is not boot. This seems to me a bit cleaner compared to what I submitted in this patch, but fundamentally the functionality is the same. You don't need to introduce a static variable it. I believe you can re-create it based on the information we already have in global variables. So what I would do is moving the creation of vtcr value in that function. Cheers, -- Julien Grall IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fwd: [tip:x86/urgent] x86, sched: Allow topologies where NUMA nodes share an LLC
On 17/04/18 15:02, Juergen Gross wrote: > Is this something we should be aware of in Xen, too? If we had something close to a working topology representation, probably. As things stand, I don't really know, but I doubt it will cause problems in the default case, due to us being fairly NUMA-inefficient to begin with. I haven't had the time to turn SNC on see what happens. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Fwd: [tip:x86/urgent] x86, sched: Allow topologies where NUMA nodes share an LLC
Is this something we should be aware of in Xen, too? Juergen Forwarded Message Subject: [tip:x86/urgent] x86,sched: Allow topologies where NUMA nodes share an LLC Date: Tue, 17 Apr 2018 06:46:12 -0700 From: tip-bot for Alison Schofield Reply-To: h...@zytor.com, b...@suse.de, tony.l...@intel.com, tim.c.c...@linux.intel.com, b...@alien8.de, h...@linux.intel.com, dave.han...@linux.intel.com, imamm...@redhat.com, pra...@redhat.com, linux-ker...@vger.kernel.org, pet...@infradead.org, alison.schofi...@intel.com, t...@linutronix.de, mi...@kernel.org, rient...@google.com To: linux-tip-comm...@vger.kernel.org CC: pet...@infradead.org, linux-ker...@vger.kernel.org, pra...@redhat.com, imamm...@redhat.com, rient...@google.com, mi...@kernel.org, alison.schofi...@intel.com, t...@linutronix.de, tim.c.c...@linux.intel.com, tony.l...@intel.com, b...@suse.de, h...@zytor.com, dave.han...@linux.intel.com, h...@linux.intel.com, b...@alien8.de Commit-ID: 1340ccfa9a9afefdbab90d7935d4ed19817e37c2 Gitweb: https://git.kernel.org/tip/1340ccfa9a9afefdbab90d7935d4ed19817e37c2 Author: Alison Schofield AuthorDate: Fri, 6 Apr 2018 17:21:30 -0700 Committer: Thomas Gleixner CommitDate: Tue, 17 Apr 2018 15:39:55 +0200 x86,sched: Allow topologies where NUMA nodes share an LLC Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one memory controller and each slice is enumerated to Linux as a NUMA node. This is similar to how the cores and LLC were arranged for the Cluster-On-Die (CoD) feature. CoD allowed the same cache line to be present in each half of the LLC. But, with SNC, each line is only ever present in *one* slice. This means that the portion of the LLC *available* to a CPU depends on the data being accessed: Remote socket: entire package LLC is shared Local socket->local slice: data goes into local slice LLC Local socket->remote slice: data goes into remote-slice LLC. Slightly higher latency than local slice LLC. The biggest implication from this is that a process accessing all NUMA-local memory only sees half the LLC capacity. The CPU describes its cache hierarchy with the CPUID instruction. One of the CPUID leaves enumerates the "logical processors sharing this cache". This information is used for scheduling decisions so that tasks move more freely between CPUs sharing the cache. But, the CPUID for the SNC configuration discussed above enumerates the LLC as being shared by the entire package. This is not 100% precise because the entire cache is not usable by all accesses. But, it *is* the way the hardware enumerates itself, and this is not likely to change. The userspace visible impact of all the above is that the sysfs info reports the entire LLC as being available to the entire package. As noted above, this is not true for local socket accesses. This patch does not correct the sysfs info. It is the same, pre and post patch. The current code emits the following warning: sched: CPU #3's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency. The warning is coming from the topology_sane() check in smpboot.c because the topology is not matching the expectations of the model for obvious reasons. To fix this, add a vendor and model specific check to never call topology_sane() for these systems. Also, just like "Cluster-on-Die" disable the "coregroup" sched_domain_topology_level and use NUMA information from the SRAT alone. This is OK at least on the hardware we are immediately concerned about because the LLC sharing happens at both the slice and at the package level, which are also NUMA boundaries. Signed-off-by: Alison Schofield Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Cc: Prarit Bhargava Cc: Tony Luck Cc: Peter Zijlstra (Intel) Cc: brice.gog...@gmail.com Cc: Dave Hansen Cc: Borislav Petkov Cc: David Rientjes Cc: Igor Mammedov Cc: "H. Peter Anvin" Cc: Tim Chen Link: https://lkml.kernel.org/r/20180407002130.ga18...@alison-desk.jf.intel.com --- arch/x86/kernel/smpboot.c | 45 - 1 file changed, 40 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index ff99e2b6fc54..45175b81dd5b 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -77,6 +77,8 @@ #include #include #include +#include +#include /* Number of siblings per CPU package */ int smp_num_siblings = 1; @@ -390,15 +392,47 @@ static bool match_smt(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) return false; } +/* + * Define snc_cpu[] for SNC (Sub-NUMA Cluster) CPUs. + * + * These are Intel CPUs that enumerate an LLC that is shared by + * multiple NUMA nodes. The LLC on these systems is shared for + * off-package data access but private to the NU
Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks
ping? ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable baseline-only test] 74628: tolerable FAIL
This run is configured for baseline tests only. flight 74628 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74628/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail like 74622 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 74622 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 74622 test-armhf-armhf-libvirt 12 guest-start fail like 74622 test-armhf-armhf-xl-rtds 12 guest-start fail like 74622 test-armhf-armhf-xl 12 guest-start fail like 74622 test-armhf-armhf-xl-xsm 12 guest-start fail like 74622 test-armhf-armhf-xl-multivcpu 12 guest-start fail like 74622 test-armhf-armhf-xl-midway 12 guest-start fail like 74622 test-armhf-armhf-xl-credit2 12 guest-start fail like 74622 test-armhf-armhf-libvirt-xsm 12 guest-start fail like 74622 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74622 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 74622 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 74622 test-armhf-armhf-xl-vhd 10 debian-di-installfail like 74622 test-armhf-armhf-libvirt-raw 10 debian-di-installfail like 74622 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 74622 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 74622 test-amd64-amd64-examine 4 memdisk-try-append fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win10-i386 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen a6aa678fa380e9369cc44701a181142322b3a4b0 baseline version: xen 16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5 Last test of basis74622 2018-04-15 16:28:22 Z1 days Testing same since74628 2018-04-17 04:19:08 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Oleksandr Tyshchenko jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On 04/17/2018 11:50 AM, Razvan Cojocaru wrote: > void p2m_init_altp2m_ept(struct domain *d, unsigned int i) > { > struct p2m_domain *p2m = d->arch.altp2m_p2m[i]; > +struct p2m_domain *hostp2m = p2m_get_hostp2m(d); > struct ept_data *ept; > > +p2m->max_mapped_pfn = hostp2m->max_mapped_pfn; > +p2m->default_access = hostp2m->default_access; > +p2m->domain = hostp2m->domain; > +p2m->logdirty_ranges = hostp2m->logdirty_ranges; > +p2m->global_logdirty = hostp2m->global_logdirty; This would certainly be one approach. But then we'd need to keep a lot more of these things in sync -- for instance, we'd have to have similar code to enable and disable global_logdirty on all active altp2m entries. I also don't think the max_mapped_pfn should be copied here; the fact that updates got filtered out before was a red herring I think. Another approach would be to maintain the logdirty_ranges and global_logdirty only for the host p2m, but to misconfigure entries for all the p2ms; and then on a misconfiguration, handle the misconfiguration for the hostp2m and then do a lazy propagate for the altp2m. On the whole that's probably more error-prone than just doing a for() loop, though, and not that much faster. :-) The other thing that seems to be missing from synchronization is that in p2m-ept.c:ept_enable_pml() sets the p2m->ept.ad bit (which ends up being part of the eptp). The code seems to indicate that this is required for PML (hardware-assisted logdirty), but I don't see anywhere this is set or copied from the host p2m. It might be nice to have a more structured way of keeping all these changes in sync, rather than relying on this open-coding everywhere. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 8/8] x86/SVM: Add AMD AVIC key handler
>>> On 04.04.18 at 01:01, wrote: > Adding new key-handler "j" for dumping AVIC-related information. Considering how few keys we have left, I have significant reservations against adding such a narrow purpose key. If you really want to expose such information, add it to a suitable existing key or introduce a sysctl. > --- a/xen/arch/x86/hvm/svm/avic.c > +++ b/xen/arch/x86/hvm/svm/avic.c > @@ -28,6 +28,7 @@ > #include > #include > #include > +#include > #include > #include Please insert new includes in a more logical manner (where possible we ask for them to be sorted alphabetically, but that may not make sense here, but at least group it with other xen/ ones). > @@ -49,6 +50,11 @@ > */ > bool svm_avic = 0; > > +static inline bool svm_is_avic_domain(struct domain *d) const > +{ > +return ( d->arch.hvm_domain.svm.avic_physical_id_table != 0 ); Stray blanks (and unnecessary parentheses anyway). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 122346: all pass - PUSHED
flight 122346 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/122346/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 55f67014d7b4a1228754313917ccca5539764802 baseline version: ovmf 5e0e476a9542a1f769fd5325c0be2d16d3ad1d42 Last test of basis 122337 2018-04-16 22:52:53 Z0 days Testing same since 122346 2018-04-17 07:16:34 Z0 days1 attempts People who touched revisions under test: Pete Batard jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 5e0e476a95..55f67014d7 55f67014d7b4a1228754313917ccca5539764802 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/5] SUPPORT.md: Move descriptions up before Status info
Lars Kurth writes ("Re: [PATCH 4/5] SUPPORT.md: Move descriptions up before Status info"): > There were a couple of minor text changes for grammar reasons, which I > noticed and highlighted. Thanks. > I also checked the code motions. There are some things which need to be > pointed out, but they should not prevent this series from being checked in. > > However, a couple were missed > * ### PV Console (frontend) => missed moving the note (which is a definition) That's one, not a couple. I have fixed it. > I also spotted a few other inconsistencies, which we probably should fix, but > these need backporting > * ARM: 16K and 64K page granularity in guests > * ARM: Guest Device Tree support > * ARM: Guest ACPI support > In all the other section headers we use x86/ or ARM/ I think "x86:" and "ARM:" are more natural so I would prefer that bikeshed purple rather than blue. I think the "/" came from the example of the guest types, which are indeed in some sense "x86/HVM" rather than "x86: HVM". I think we should treat that as a separate issue from this series. > -### x86/PVH > - > Status, domU: Supported > -Status, dom0: Experimental > + > +### x86/PVH > > PVH is a next-generation paravirtualized mode > designed to take advantage of hardware virtualization support when > possible. > > Looks correct from a mere refactoring perspective, but generates some odd > behaviour in > https://xenbits.xen.org/people/iwj/2018/support-matrix-example-B-v1/t.html > > The underlying reason is that we had some headline re-names between 4.10 and > 4.11. e.g. > ARM guest => ARM > > And some support statement changes, e.g. in x86/HVM guest > Status: Supported => Status, domU: Supported The rendering is indeed not ideal. Our options are: (a) Live with it and document it. (b) Make it our practice to go always back and backport a name change for a feature to all versions. I'm not sure this is worth the effort. (c) Invent some new equivalency metadata to put into SUPPORT.md or even into some other file in-tree. Urgh, I don't want to do that. I chose (a). You will see a paragraph about this at the top of the html page: Sometimes the same feature, or a similar feature, is named differently in the documentation for different releases. In such cases the table will show it as two separate features, with a discontinuity in support, even though support may have been continuous. > We probably need to go through some of these in 4.10 and fix them > But for 4.11 this is correct I think the 4.10 documentation is not wrong, just differently expressed. > The implication is that we need to minimize unnecessary changes to > a) headings > b) clarifications to status before the colon > or backport them to older versions of SUPPORT.md. Otherwise the generated > table will become confusing See above. If you want to backport the heading changes, I'll ack your patches :-). > ### Direct-boot kernel image format > > +Format which the toolstack accepts for direct-boot kernels > + > Supported, x86: bzImage, ELF > Supported, ARM32: zImage > Supported, ARM64: Image > > -Format which the toolstack accepts for direct-boot kernels > - > > Note: the format here is wrong in both 4.10 and 4.11, this should be > something like > > Status, zImage (ARM32): Supported > > Lars will submit a separate patch This is not a blocker because I added parsing code for this format. If you fix it, we can drop that, too, once the change is backported. > ## Scalability > > ### Super page support > > -Status, x86 HVM/PVH, HAP: Supported > -Status, x86 HVM/PVH, Shadow, 2MiB: Supported > -Status, ARM: Supported > - > NB that this refers to the ability of guests > > The beginning of this sentence should probably be changed to > "This feature refers to the ability of guests ..." Or even just "The ability of guests ..." since we don't normally lead each thing with "this is". I think this is not very important. If you want to improve it I will ack your patch. > ## Virtual Hardware, QEMU > > -These are devices available in HVM mode using a qemu devicemodel (the > default). > +This section describes supported devices available in HVM mode using a > +qemu devicemodel (the default). > + > +Status: Support scope restricted > + > Note that other devices are available but not security supported. > > This is causing a rendering issue: the footnote is not generated in the right > place. It is added to " stgvga". Presumably a corner case in the table > generation tool Yes. It is generating semantically invalid html which renders very oddly, too. I will fix it. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org
Re: [Xen-devel] [PATCH 6/8] x86/HVM: Hook up miscellaneous AVIC functions
>>> On 04.04.18 at 01:01, wrote: > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -1711,7 +1711,10 @@ const struct hvm_function_table * __init > start_svm(void) > svm_avic = 0; > > if ( svm_avic ) > +{ > svm_function_table.deliver_posted_intr = > svm_avic_deliver_posted_intr; > +svm_function_table.virtual_intr_delivery_enabled = svm_avic; Considering the controlling expression of the if() we're in, why not simply "true"? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/8] x86/SVM: Add interrupt management code via AVIC
>>> On 04.04.18 at 01:01, wrote: > +void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vec) > +{ > +struct vlapic *vlapic = vcpu_vlapic(v); > + > +/* Fallback to use non-AVIC if vcpu is not enabled with AVIC. */ > +if ( !svm_avic_vcpu_enabled(v) ) > +{ > +if ( !vlapic_test_and_set_vector(vec, &vlapic->regs->data[APIC_IRR]) > ) > +vcpu_kick(v); > +return; > +} > + > +/* If interrupt is disabled, do not ignore the interrupt */ > +if ( !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) ) > +return; I'm confused by the comment: How is returning here without any indication to the caller different from ignoring the interrupt? How come EFLAGS.IF matters here in the first place? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11] libs/gnttab: fix FreeBSD gntdev interface
Current interface to the gntdev in FreeBSD is wrong, and mostly worked out of luck before the PTI FreeBSD fixes, when kernel and user-space where sharing the same page tables. On FreeBSD ioctls have the size of the passed struct encoded in the ioctl number, because the generic ioctl handler in the OS takes care of copying the data from user-space to kernel space, and then calls the device specific ioctl handler. Thus using ioctl structs with variable sizes is not possible. The fix is to turn the array of structs at the end of ioctl_gntdev_alloc_gref and ioctl_gntdev_map_grant_ref into pointers, that can be properly accessed from the kernel gntdev driver using the copyin/copyout functions. Note that this is exactly how it's done for the privcmd driver. Signed-off-by: Roger Pau Monné --- Rationale for acceptance into 4.11: - Without this fix the grant table device is not usable on FreeBSD. - It affects FreeBSD code exclusively, there's no risk for Linux or other OSes. --- Cc: Ian Jackson Cc: Wei Liu Cc: Juergen Gross --- tools/include/xen-sys/FreeBSD/gntdev.h | 4 +- tools/libs/gnttab/freebsd.c| 63 +- 2 files changed, 33 insertions(+), 34 deletions(-) diff --git a/tools/include/xen-sys/FreeBSD/gntdev.h b/tools/include/xen-sys/FreeBSD/gntdev.h index f3af9a46de..1e39e2f51a 100644 --- a/tools/include/xen-sys/FreeBSD/gntdev.h +++ b/tools/include/xen-sys/FreeBSD/gntdev.h @@ -138,7 +138,7 @@ struct ioctl_gntdev_alloc_gref { /* OUT parameters */ uint64_t index; /* Variable OUT parameter */ -uint32_t gref_ids[1]; +uint32_t *gref_ids; }; #define GNTDEV_ALLOC_FLAG_WRITABLE 1 @@ -167,7 +167,7 @@ struct ioctl_gntdev_map_grant_ref { /* OUT parameters */ uint64_t index; /* Variable IN parameter */ -struct ioctl_gntdev_grant_ref refs[1]; +struct ioctl_gntdev_grant_ref *refs; }; #define IOCTL_GNTDEV_UNMAP_GRANT_REF \ diff --git a/tools/libs/gnttab/freebsd.c b/tools/libs/gnttab/freebsd.c index 3eaa77235f..5c12fe9b0b 100644 --- a/tools/libs/gnttab/freebsd.c +++ b/tools/libs/gnttab/freebsd.c @@ -70,22 +70,21 @@ void *osdep_gnttab_grant_map(xengnttab_handle *xgt, { uint32_t i; int fd = xgt->fd; -struct ioctl_gntdev_map_grant_ref *map; +struct ioctl_gntdev_map_grant_ref map; void *addr = NULL; int domids_stride; -unsigned int map_size = ROUNDUP((sizeof(*map) + (count - 1) * -sizeof(struct ioctl_gntdev_map_grant_ref)), -PAGE_SHIFT); +unsigned int refs_size = ROUNDUP(count * + sizeof(struct ioctl_gntdev_map_grant_ref), + PAGE_SHIFT); domids_stride = (flags & XENGNTTAB_GRANT_MAP_SINGLE_DOMAIN) ? 0 : 1; -if ( map_size <= PAGE_SIZE ) -map = malloc(sizeof(*map) + - (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref)); +if ( refs_size <= PAGE_SIZE ) +map.refs = malloc(refs_size); else { -map = mmap(NULL, map_size, PROT_READ | PROT_WRITE, - MAP_PRIVATE | MAP_ANON, -1, 0); -if ( map == MAP_FAILED ) +map.refs = mmap(NULL, refs_size, PROT_READ | PROT_WRITE, +MAP_PRIVATE | MAP_ANON, -1, 0); +if ( map.refs == MAP_FAILED ) { GTERROR(xgt->logger, "anon mmap of map failed"); return NULL; @@ -94,26 +93,26 @@ void *osdep_gnttab_grant_map(xengnttab_handle *xgt, for ( i = 0; i < count; i++ ) { -map->refs[i].domid = domids[i * domids_stride]; -map->refs[i].ref = refs[i]; +map.refs[i].domid = domids[i * domids_stride]; +map.refs[i].ref = refs[i]; } -map->count = count; +map.count = count; -if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, map) ) +if ( ioctl(fd, IOCTL_GNTDEV_MAP_GRANT_REF, &map) ) { GTERROR(xgt->logger, "ioctl MAP_GRANT_REF failed"); goto out; } addr = mmap(NULL, PAGE_SIZE * count, prot, MAP_SHARED, fd, -map->index); +map.index); if ( addr != MAP_FAILED ) { int rv = 0; struct ioctl_gntdev_unmap_notify notify; -notify.index = map->index; +notify.index = map.index; notify.action = 0; if ( notify_offset < PAGE_SIZE * count ) { @@ -141,7 +140,7 @@ void *osdep_gnttab_grant_map(xengnttab_handle *xgt, /* Unmap the driver slots used to store the grant information. */ GTERROR(xgt->logger, "mmap failed"); -unmap_grant.index = map->index; +unmap_grant.index = map.index; unmap_grant.count = count; ioctl(fd, IOCTL_GNTDEV_UNMAP_GRANT_REF, &unmap_grant); errno = saved_errno; @@ -149,10 +148,10 @@ void *osdep_gnttab_grant_map(xengnttab_handle *xgt, } out: -if ( map_size > PAGE_SIZE ) -
Re: [Xen-devel] [PATCH 3/8] x86/SVM: Add AVIC vmexit handlers
>>> On 04.04.18 at 01:01, wrote: > --- a/xen/include/asm-x86/hvm/vlapic.h > +++ b/xen/include/asm-x86/hvm/vlapic.h > @@ -137,6 +137,10 @@ void vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low, > uint32_t icr_high); > > int vlapic_apicv_write(struct vcpu *v, unsigned int offset); > > +void vlapic_reg_write(struct vcpu *v, unsigned int offset, uint32_t val); > + > +uint32_t vlapic_read_aligned(const struct vlapic *vlapic, unsigned int > offset); If making these non-static is really necessary, they should (name-wise) become proper pairs of one another, e.g. renamed the former to vlapic_reg_read(). Also while here you properly use uint32_t, almost everywhere you use u32. Please switch this throughout the series, and of course for all other fixed width integer types. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario
Hi Julien, On Wed, Apr 11, 2018 at 5:11 PM, Julien Grall wrote: > Hi, > > On 11/04/18 14:19, Mirela Simonovic wrote: >> >> In existing code the paging for secondary CPUs is setup only in boot flow. >> The setup is triggered from start_xen function after all CPUs are brought >> online. In other words, the initialization of VTCR_EL2 register is done >> out of the cpu_up/start_secondary control flow. However, the cpu_up flow >> should be self-contained - it should fully initialize a secondary CPU, >> because the cpu_up is used not only to bring a secondary CPU online on >> boot, but also to hotplug a CPU during the system resume. >> With this patch the setting of paging is triggered from start_secondary >> function if the current system state is not boot. This way, the paging >> will be setup in non-boot scenarios, while the setup in boot scenario >> remains unchanged. > > > I am afraid that this is not correct. You can't assume that value chosen for > VTCR by Xen at boot will fit this new CPU. So you have to check it is fine > or park the CPU if there are any issue. > This is not a new CPU. This CPU already went through its boot sequence and it reached the resume point because it does fit the value chosen for VTCR by Xen. If it wouldn't fit the chosen value for VTCR it would be parked so it wouldn't participate in suspend/resume. Please let me know if I misunderstood your comment. AFAIU the value chosen by Xen for VTCR config has to be common for all online CPUs. Since this value is also used in the resume path I suggest to make global (static in the p2m.c) the 'val' variable which is currently local in setup_virt_paging() and passed as argument to setup_virt_paging_one(). Then setup_virt_paging_one() would not receive an argument. I need to access this value on resume, so I would call setup_virt_paging_one() without argument from start_secondary() if the system state is not boot. This seems to me a bit cleaner compared to what I submitted in this patch, but fundamentally the functionality is the same. Thanks, Mirela > For more details have a look at [1]. > > [1] > https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg02482.html > > Cheers, > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/msr: further correct the emulation behaviour of MSR_PRED_CMD
>>> On 17.04.18 at 14:30, wrote: > On 17/04/18 12:41, Jan Beulich wrote: >> Following commit a6aa678fa3 ("x86/msr: Correct the emulation behaviour >> of MSR_PRED_CMD") we may end up writing the low bit with the wrong >> value. While it's unlikely for a guest to want to write zero there, we >> should still permit (this without incurring the overhead of an actual >> barrier). Correcting this right away will also help whenever further >> bits in the MSR might become defined. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/msr.c >> +++ b/xen/arch/x86/msr.c >> @@ -247,7 +247,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t >> goto gp_fault; /* Rsvd bit set? */ >> >> if ( v == curr ) >> -wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB); >> +wrmsrl(MSR_PRED_CMD, val); > > I was on the fence about making this change, because if the reserved bit > testing happens to be wrong, we might suffer a fatal #GP here. > > Then again, the same could be said of the the CPUID check and explicit > use of PRED_CMD_IBPB. > > I also wondered if we would be better using wrmsr_safe() to cope better > in release situations, where at least bad logic here would result in > host crash. Any of this likely would equally be an issue for some other MSRs, and I think that's orthogonal to the change (with the given description) here: It is clearly wrong to write bit 0 with 1 when the original guest value has the bit clear. If anything I could agree to writing val & PRED_CMD_IBPB, but that's then obviously redundant with the check immediately ahead of the write. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 0/5] ALSA: xen-front: Add Xen para-virtualized frontend driver
Hello, Juergen! Thank you very much for reviewing the driver and providing valuable comments! I will send v3 of the driver once I have more reviews, especially I hope ALSA community can also take a look Also, as you suggested on IRC, I will add a patch for adding myself as sound/xen maintainer. Thank you, Oleksandr On 04/16/2018 09:24 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Please note: this patch series depends on [3]. This patch series adds support for Xen [1] para-virtualized sound frontend driver. It implements the protocol from include/xen/interface/io/sndif.h with the following limitations: - mute/unmute is not supported - get/set volume is not supported Volume control is not supported for the reason that most of the use-cases (at the moment) are based on scenarious where unprivileged OS (e.g. Android, AGL etc) use software mixers. Both capture and playback are supported. Corresponding backend, implemented as a user-space application, can be found at [2]. Thank you, Oleksandr Changes since v1: * 1. Moved driver from sound/drivers to sound/xen 2. Coding style changes to better meet Linux Kernel 3. Added explicit back and front synchronization In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events 4. Added explicit back and front parameter negotiation In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameters given: request passes desired parameter's intervals/masks and the response to this request returns allowed min/max intervals/masks to be used. [1] https://xenproject.org/ [2] https://github.com/xen-troops/snd_be [3] https://lkml.org/lkml/2018/4/12/522 Oleksandr Andrushchenko (5): ALSA: xen-front: Introduce Xen para-virtualized sound frontend driver ALSA: xen-front: Read sound driver configuration from Xen store ALSA: xen-front: Implement Xen event channel handling ALSA: xen-front: Implement handling of shared buffers ALSA: xen-front: Implement ALSA virtual sound driver sound/Kconfig | 2 + sound/Makefile| 2 +- sound/xen/Kconfig | 10 + sound/xen/Makefile| 9 + sound/xen/xen_snd_front.c | 410 +++ sound/xen/xen_snd_front.h | 57 +++ sound/xen/xen_snd_front_alsa.c| 830 ++ sound/xen/xen_snd_front_alsa.h| 23 ++ sound/xen/xen_snd_front_cfg.c | 517 sound/xen/xen_snd_front_cfg.h | 46 +++ sound/xen/xen_snd_front_evtchnl.c | 478 ++ sound/xen/xen_snd_front_evtchnl.h | 92 + sound/xen/xen_snd_front_shbuf.c | 193 + sound/xen/xen_snd_front_shbuf.h | 36 ++ 14 files changed, 2704 insertions(+), 1 deletion(-) create mode 100644 sound/xen/Kconfig create mode 100644 sound/xen/Makefile create mode 100644 sound/xen/xen_snd_front.c create mode 100644 sound/xen/xen_snd_front.h create mode 100644 sound/xen/xen_snd_front_alsa.c create mode 100644 sound/xen/xen_snd_front_alsa.h create mode 100644 sound/xen/xen_snd_front_cfg.c create mode 100644 sound/xen/xen_snd_front_cfg.h create mode 100644 sound/xen/xen_snd_front_evtchnl.c create mode 100644 sound/xen/xen_snd_front_evtchnl.h create mode 100644 sound/xen/xen_snd_front_shbuf.c create mode 100644 sound/xen/xen_snd_front_shbuf.h ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin
On Wed, 2018-04-11 at 14:45 +0200, Olaf Hering wrote: > On Wed, Apr 11, Dario Faggioli wrote: > > > If you're interested in figuring out, I'd like to see: > > - full output of `xl info -n' > > - output of `xl debug-key u' > > - xl vcpu-list > > - xl list -n > > Logs for this .cfg attached: > > name='fv_sles12sp1.0' > vif=[ 'mac=00:18:3e:58:00:c1,bridge=br0' ] > memory= > vcpus=36 > serial="pty" > builder="hvm" > kernel="/xen100.migration/olh/bug1088498/nfsroot_sles12sp2.bug1088498 > /boot/vmlinuz" > ramdisk="/xen100.migration/olh/bug1088498/nfsroot_sles12sp2.bug108849 > 8/boot/initrd" > cmdline="quiet panic=9 > root=nfs:xen100:/share/migration/olh/bug1088498/nfsroot_sles12sp2.bug > 1088498,vers=3,tcp,actimeo=1,nolock readonlyroot ro Xignore_loglevel > Xdebug Xsystemd.log_target=kmsgXsystemd.log_level=debug Xrd.debug > Xrd.shell Xrd.udev.debug Xudev.log-priority=debug Xrd.udev.log- > priority=debug console=ttyS0" > cpus="node:2" > #pus="nodes:2" > #pus="nodes:2,^node:0" > #pus_soft="nodes:2,^node:0" > So, I do not really know what the problem could be here. In fact, vcpu_hard_affinity is being defined, and numa_placement is being set to false, which are both correct. However, vcpu_hard_affinity seems to be empty: "vcpu_hard_affinity": [ [ ], [ ], [ ], [ ], [ ], [ ], [ ], [ ], [ ], ... ... ... ], "numa_placement": "False", Judging on the output of other xl commands, though, retrieving the cpus from node 2 seems to work, and the fact that "node:2" behaves differently than "node:1" is quite weird. If we still have access to this system, it would be interesting to instrument, e.g., update_cpumap_range() in xl_parse.c, and see what actually libxl_node_to_cpumap() does in this case... Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] ALSA: xen-front: Implement ALSA virtual sound driver
On 04/17/2018 03:32 PM, Juergen Gross wrote: On 17/04/18 14:26, Oleksandr Andrushchenko wrote: On 04/17/2018 02:32 PM, Oleksandr Andrushchenko wrote: On 04/16/2018 05:09 PM, Juergen Gross wrote: On 16/04/18 08:24, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Implement essential initialization of the sound driver: - introduce required data structures - handle driver registration - handle sound card registration - register sound driver on backend connection - remove sound driver on backend disconnect Initialize virtual sound card with streams according to the Xen store configuration. Implement ALSA driver operations including: - manage frontend/backend shared buffers - manage Xen bus event channel states Implement requests from front to back for ALSA PCM operations. - report ALSA period elapsed event: handle XENSND_EVT_CUR_POS notifications from the backend when stream position advances during playback/capture. The event carries a value of how many octets were played/captured at the time of the event. - implement explicit stream parameter negotiation between backend and frontend: handle XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval and the response to this request returns min/max interval for the parameter to be used. Signed-off-by: Oleksandr Andrushchenko --- sound/xen/Makefile | 3 +- sound/xen/xen_snd_front.c | 193 - sound/xen/xen_snd_front.h | 28 ++ sound/xen/xen_snd_front_alsa.c | 830 ++ sound/xen/xen_snd_front_alsa.h | 23 ++ sound/xen/xen_snd_front_evtchnl.c | 6 +- 6 files changed, 1080 insertions(+), 3 deletions(-) create mode 100644 sound/xen/xen_snd_front_alsa.c create mode 100644 sound/xen/xen_snd_front_alsa.h diff --git a/sound/xen/Makefile b/sound/xen/Makefile index f028bc30af5d..1e6470ecc2f2 100644 --- a/sound/xen/Makefile +++ b/sound/xen/Makefile @@ -3,6 +3,7 @@ snd_xen_front-objs := xen_snd_front.o \ xen_snd_front_cfg.o \ xen_snd_front_evtchnl.o \ - xen_snd_front_shbuf.o + xen_snd_front_shbuf.o \ + xen_snd_front_alsa.o obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c index 0569c6c596a3..1fef253ea21a 100644 --- a/sound/xen/xen_snd_front.c +++ b/sound/xen/xen_snd_front.c @@ -19,10 +19,201 @@ #include #include "xen_snd_front.h" +#include "xen_snd_front_alsa.h" #include "xen_snd_front_evtchnl.h" +#include "xen_snd_front_shbuf.h" + +static struct xensnd_req * +be_stream_prepare_req(struct xen_snd_front_evtchnl *evtchnl, u8 operation) +{ + struct xensnd_req *req; + + req = RING_GET_REQUEST(&evtchnl->u.req.ring, + evtchnl->u.req.ring.req_prod_pvt); + req->operation = operation; + req->id = evtchnl->evt_next_id++; + evtchnl->evt_id = req->id; + return req; +} + +static int be_stream_do_io(struct xen_snd_front_evtchnl *evtchnl) +{ + if (unlikely(evtchnl->state != EVTCHNL_STATE_CONNECTED)) + return -EIO; + + reinit_completion(&evtchnl->u.req.completion); + xen_snd_front_evtchnl_flush(evtchnl); + return 0; +} + +static int be_stream_wait_io(struct xen_snd_front_evtchnl *evtchnl) +{ + if (wait_for_completion_timeout(&evtchnl->u.req.completion, + msecs_to_jiffies(VSND_WAIT_BACK_MS)) <= 0) + return -ETIMEDOUT; + + return evtchnl->u.req.resp_status; +} + +int xen_snd_front_stream_query_hw_param(struct xen_snd_front_evtchnl *evtchnl, + struct xensnd_query_hw_param *hw_param_req, + struct xensnd_query_hw_param *hw_param_resp) +{ + struct xen_snd_front_info *front_info = evtchnl->front_info; + struct xensnd_req *req; + unsigned long flags; + int ret; + + mutex_lock(&evtchnl->u.req.req_io_lock); + + spin_lock_irqsave(&front_info->io_lock, flags); + req = be_stream_prepare_req(evtchnl, XENSND_OP_HW_PARAM_QUERY); + req->op.hw_param = *hw_param_req; + + ret = be_stream_do_io(evtchnl); + spin_unlock_irqrestore(&front_info->io_lock, flags); + + if (ret == 0) + ret = be_stream_wait_io(evtchnl); + + if (ret == 0) + *hw_param_resp = evtchnl->u.req.resp.hw_param; + + mutex_unlock(&evtchnl->u.req.req_io_lock); + return ret; +} + +int xen_snd_front_stream_prepare(struct xen_snd_front_evtchnl *evtchnl, + struct xen_snd_front_shbuf *sh_buf, + u8 format, unsigned int channels, + unsigned int rate, u32 buffer_sz, + u32 period_sz) +{ + struct xen_snd_front_info *front_info = evtchnl->front_info; + struct xensnd_req *req; + unsigned long flags; + int ret; + + mutex_lock(&evtchnl->u.req.req_io_lock); + + spin_lock_irqsave(&front_info-
Re: [Xen-devel] [PATCH v2 5/5] ALSA: xen-front: Implement ALSA virtual sound driver
On 17/04/18 14:26, Oleksandr Andrushchenko wrote: > On 04/17/2018 02:32 PM, Oleksandr Andrushchenko wrote: >> On 04/16/2018 05:09 PM, Juergen Gross wrote: >>> On 16/04/18 08:24, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Implement essential initialization of the sound driver: - introduce required data structures - handle driver registration - handle sound card registration - register sound driver on backend connection - remove sound driver on backend disconnect Initialize virtual sound card with streams according to the Xen store configuration. Implement ALSA driver operations including: - manage frontend/backend shared buffers - manage Xen bus event channel states Implement requests from front to back for ALSA PCM operations. - report ALSA period elapsed event: handle XENSND_EVT_CUR_POS notifications from the backend when stream position advances during playback/capture. The event carries a value of how many octets were played/captured at the time of the event. - implement explicit stream parameter negotiation between backend and frontend: handle XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval and the response to this request returns min/max interval for the parameter to be used. Signed-off-by: Oleksandr Andrushchenko --- sound/xen/Makefile | 3 +- sound/xen/xen_snd_front.c | 193 - sound/xen/xen_snd_front.h | 28 ++ sound/xen/xen_snd_front_alsa.c | 830 ++ sound/xen/xen_snd_front_alsa.h | 23 ++ sound/xen/xen_snd_front_evtchnl.c | 6 +- 6 files changed, 1080 insertions(+), 3 deletions(-) create mode 100644 sound/xen/xen_snd_front_alsa.c create mode 100644 sound/xen/xen_snd_front_alsa.h diff --git a/sound/xen/Makefile b/sound/xen/Makefile index f028bc30af5d..1e6470ecc2f2 100644 --- a/sound/xen/Makefile +++ b/sound/xen/Makefile @@ -3,6 +3,7 @@ snd_xen_front-objs := xen_snd_front.o \ xen_snd_front_cfg.o \ xen_snd_front_evtchnl.o \ - xen_snd_front_shbuf.o + xen_snd_front_shbuf.o \ + xen_snd_front_alsa.o obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c index 0569c6c596a3..1fef253ea21a 100644 --- a/sound/xen/xen_snd_front.c +++ b/sound/xen/xen_snd_front.c @@ -19,10 +19,201 @@ #include #include "xen_snd_front.h" +#include "xen_snd_front_alsa.h" #include "xen_snd_front_evtchnl.h" +#include "xen_snd_front_shbuf.h" + +static struct xensnd_req * +be_stream_prepare_req(struct xen_snd_front_evtchnl *evtchnl, u8 operation) +{ + struct xensnd_req *req; + + req = RING_GET_REQUEST(&evtchnl->u.req.ring, + evtchnl->u.req.ring.req_prod_pvt); + req->operation = operation; + req->id = evtchnl->evt_next_id++; + evtchnl->evt_id = req->id; + return req; +} + +static int be_stream_do_io(struct xen_snd_front_evtchnl *evtchnl) +{ + if (unlikely(evtchnl->state != EVTCHNL_STATE_CONNECTED)) + return -EIO; + + reinit_completion(&evtchnl->u.req.completion); + xen_snd_front_evtchnl_flush(evtchnl); + return 0; +} + +static int be_stream_wait_io(struct xen_snd_front_evtchnl *evtchnl) +{ + if (wait_for_completion_timeout(&evtchnl->u.req.completion, + msecs_to_jiffies(VSND_WAIT_BACK_MS)) <= 0) + return -ETIMEDOUT; + + return evtchnl->u.req.resp_status; +} + +int xen_snd_front_stream_query_hw_param(struct xen_snd_front_evtchnl *evtchnl, + struct xensnd_query_hw_param *hw_param_req, + struct xensnd_query_hw_param *hw_param_resp) +{ + struct xen_snd_front_info *front_info = evtchnl->front_info; + struct xensnd_req *req; + unsigned long flags; + int ret; + + mutex_lock(&evtchnl->u.req.req_io_lock); + + spin_lock_irqsave(&front_info->io_lock, flags); + req = be_stream_prepare_req(evtchnl, XENSND_OP_HW_PARAM_QUERY); + req->op.hw_param = *hw_param_req; + + ret = be_stream_do_io(evtchnl); + spin_unlock_irqrestore(&front_info->io_lock, flags); + + if (ret == 0) + ret = be_stream_wait_io(evtchnl); + + if (ret == 0) + *hw_param_resp = evtchnl->u.req.resp.hw_param; + + mutex_unlo
Re: [Xen-devel] [PATCH] x86/msr: further correct the emulation behaviour of MSR_PRED_CMD
On 17/04/18 12:41, Jan Beulich wrote: > Following commit a6aa678fa3 ("x86/msr: Correct the emulation behaviour > of MSR_PRED_CMD") we may end up writing the low bit with the wrong > value. While it's unlikely for a guest to want to write zero there, we > should still permit (this without incurring the overhead of an actual > barrier). Correcting this right away will also help whenever further > bits in the MSR might become defined. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/msr.c > +++ b/xen/arch/x86/msr.c > @@ -247,7 +247,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t > goto gp_fault; /* Rsvd bit set? */ > > if ( v == curr ) > -wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB); > +wrmsrl(MSR_PRED_CMD, val); I was on the fence about making this change, because if the reserved bit testing happens to be wrong, we might suffer a fatal #GP here. Then again, the same could be said of the the CPUID check and explicit use of PRED_CMD_IBPB. I also wondered if we would be better using wrmsr_safe() to cope better in release situations, where at least bad logic here would result in host crash. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] ALSA: xen-front: Implement ALSA virtual sound driver
On 04/17/2018 02:32 PM, Oleksandr Andrushchenko wrote: On 04/16/2018 05:09 PM, Juergen Gross wrote: On 16/04/18 08:24, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Implement essential initialization of the sound driver: - introduce required data structures - handle driver registration - handle sound card registration - register sound driver on backend connection - remove sound driver on backend disconnect Initialize virtual sound card with streams according to the Xen store configuration. Implement ALSA driver operations including: - manage frontend/backend shared buffers - manage Xen bus event channel states Implement requests from front to back for ALSA PCM operations. - report ALSA period elapsed event: handle XENSND_EVT_CUR_POS notifications from the backend when stream position advances during playback/capture. The event carries a value of how many octets were played/captured at the time of the event. - implement explicit stream parameter negotiation between backend and frontend: handle XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval and the response to this request returns min/max interval for the parameter to be used. Signed-off-by: Oleksandr Andrushchenko --- sound/xen/Makefile | 3 +- sound/xen/xen_snd_front.c | 193 - sound/xen/xen_snd_front.h | 28 ++ sound/xen/xen_snd_front_alsa.c | 830 ++ sound/xen/xen_snd_front_alsa.h | 23 ++ sound/xen/xen_snd_front_evtchnl.c | 6 +- 6 files changed, 1080 insertions(+), 3 deletions(-) create mode 100644 sound/xen/xen_snd_front_alsa.c create mode 100644 sound/xen/xen_snd_front_alsa.h diff --git a/sound/xen/Makefile b/sound/xen/Makefile index f028bc30af5d..1e6470ecc2f2 100644 --- a/sound/xen/Makefile +++ b/sound/xen/Makefile @@ -3,6 +3,7 @@ snd_xen_front-objs := xen_snd_front.o \ xen_snd_front_cfg.o \ xen_snd_front_evtchnl.o \ - xen_snd_front_shbuf.o + xen_snd_front_shbuf.o \ + xen_snd_front_alsa.o obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c index 0569c6c596a3..1fef253ea21a 100644 --- a/sound/xen/xen_snd_front.c +++ b/sound/xen/xen_snd_front.c @@ -19,10 +19,201 @@ #include #include "xen_snd_front.h" +#include "xen_snd_front_alsa.h" #include "xen_snd_front_evtchnl.h" +#include "xen_snd_front_shbuf.h" + +static struct xensnd_req * +be_stream_prepare_req(struct xen_snd_front_evtchnl *evtchnl, u8 operation) +{ + struct xensnd_req *req; + + req = RING_GET_REQUEST(&evtchnl->u.req.ring, + evtchnl->u.req.ring.req_prod_pvt); + req->operation = operation; + req->id = evtchnl->evt_next_id++; + evtchnl->evt_id = req->id; + return req; +} + +static int be_stream_do_io(struct xen_snd_front_evtchnl *evtchnl) +{ + if (unlikely(evtchnl->state != EVTCHNL_STATE_CONNECTED)) + return -EIO; + + reinit_completion(&evtchnl->u.req.completion); + xen_snd_front_evtchnl_flush(evtchnl); + return 0; +} + +static int be_stream_wait_io(struct xen_snd_front_evtchnl *evtchnl) +{ + if (wait_for_completion_timeout(&evtchnl->u.req.completion, + msecs_to_jiffies(VSND_WAIT_BACK_MS)) <= 0) + return -ETIMEDOUT; + + return evtchnl->u.req.resp_status; +} + +int xen_snd_front_stream_query_hw_param(struct xen_snd_front_evtchnl *evtchnl, + struct xensnd_query_hw_param *hw_param_req, + struct xensnd_query_hw_param *hw_param_resp) +{ + struct xen_snd_front_info *front_info = evtchnl->front_info; + struct xensnd_req *req; + unsigned long flags; + int ret; + + mutex_lock(&evtchnl->u.req.req_io_lock); + + spin_lock_irqsave(&front_info->io_lock, flags); + req = be_stream_prepare_req(evtchnl, XENSND_OP_HW_PARAM_QUERY); + req->op.hw_param = *hw_param_req; + + ret = be_stream_do_io(evtchnl); + spin_unlock_irqrestore(&front_info->io_lock, flags); + + if (ret == 0) + ret = be_stream_wait_io(evtchnl); + + if (ret == 0) + *hw_param_resp = evtchnl->u.req.resp.hw_param; + + mutex_unlock(&evtchnl->u.req.req_io_lock); + return ret; +} + +int xen_snd_front_stream_prepare(struct xen_snd_front_evtchnl *evtchnl, + struct xen_snd_front_shbuf *sh_buf, + u8 format, unsigned int channels, + unsigned int rate, u32 buffer_sz, + u32 period_sz) +{ + struct xen_snd_front_info *front_info = evtchnl->front_info; + struct xensnd_req *req; + unsigned long flags; + int ret; + + mutex_lock(&evtchnl->u.req.req_io_lock); + + spin_lock_irqsave(&front_info->io_lock, flags); + req = be_stream_prepare_req(evtchnl, XENSND_OP_OPEN); + req->op.open.pcm_format = format; +
Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM
Hi Julien, On Fri, Jan 26, 2018 at 5:08 PM, Julien Grall wrote: > > > On 24/01/18 17:55, Mirela Simonovic wrote: >> >> Hi Julien, Stefano, > > > Hi Mirela, > >> >> Thank you very much for the feedback! >> >> >> On 01/11/2018 03:00 PM, Julien Grall wrote: >>> >>> Hi Mirela, >>> >>> Thank you for the sending the design document. The general design looks >>> good to me. I have some comments below, but they are more related to the >>> implementation of CPU on/off in Xen. >>> >>> On 22/12/17 17:41, Mirela Simonovic wrote: >>> >>> [...] >>> +--- +Resuming Guests +--- + +Resume of the privileged guest (Dom0) is always following the Xen resume. + +An unprivileged guest shall resume once a device it owns triggers a wake-up +interrupt, regardless of whether Xen was suspended when the wake-up interrupt +was triggered. If Xen was suspended, it is assumed that Dom0 will be running +before the DomU guest starts to resume. The synchronization mechanism to +enforce the assumed condition is TBD. >>> >>> >>> Given that all but the non-boot CPU will be offlined. Does the wake-up >>> interrupt always need to target the non-boot CPU? >> >> >> Wake-up interrupt needs to be targeted to the boot pCPU, and the resume >> sequence has to start from the boot pCPU. > > > I assume that wake-up interrupts could belong to a guest. > In that case, the wake-up interrupts will need to be moved to the boot pCPU > on suspend. > > [...] > >>> >>> For instance, you likely need to migrate interrupts that was assigned to >>> the physical CPU (either guest one or Xen one). Though Xen ones might be >>> less a concern because I think they are always assigned to CPU0 at the >>> moment. >> >> >> I would very appreciate more information on this. These kind of scenarios >> can be easily overlooked and I'm not that much experienced with pinning and >> its side effects. >> Lets assume a vCPU is pinned to the non-boot CPU#1. When the guest enables >> an interrupt (interrupt is targeted to the vCPU), would Xen target physical >> interrupt to the GIC CPU interface of pCPU#1 or pCPU#0 or all pCPUs? > > > In your example, the interrupts will target pCPU#1 only. > >> >>> >>> Furthermore, PPI handlers are not removed. Same for any memory allocated >>> (you may loose reference to it because percpu area for that CPU will get >>> freed). I believe get into trouble when the CPU is back online? >> >> >> Yes, I needed to add few fixes into existing code to enable pCPU to come >> back online. I'll submit RFC soon. > > > Thank you! > > [...] > >>> >>> I may have miss other bits, so I would highly recommend to go through the >>> boot code and see what could go wrong. >>> >>> [..] >>> +Resume Flow + +The resume entry point shall be implemented in +* hyp_resume() in arch/arm/arm64/entry.S +The very beginning of the resume procedure has to be implemented in assembly. +It shall contain the following: +* Enable the MMU so that the structure containing CPU context which was saved on +suspend can be accessed +* Restore CPU context (to match the values saved on suspend) and return into C +* Set the system_state variable to SYS_STATE_resume +* Restore GIC context +* Resume timer +* Enable interrupts +* Enable non-boot CPUs by calling enable_nonboot_cpus() >>> >>> >>> You would have to be careful on re-enabling the non-CPU. start_secondary >>> is implemented based on the assumption that it will only be called during >>> Xen boot. Some of the code may be part of __init (see cpu_up_send_sgi) or >>> should not be called as it is after boot (e.g check_local_cpu_errata). >>> >>> Another I have in mind is the way VTCR_EL2 is set today (see >>> setup_virt_paging). It is done at boot time, so if you online a CPU >>> afterwards, VTCR_EL2 will not be set correctly. >> >> >> Was there any reason to configure VTCR_EL2 after all CPUs become online? >> >> I fixed this as follows: in start_xen(), the boot CPU calls >> setup_virt_paging() prior to enabling non-boot CPUs. setup_virt_paging() >> configures VTCR_EL2 only for the boot CPU. >> Non-boot CPUs call setup_virt_paging_one() later, from start_secondary(). >> Also, only the boot CPU performs the calculation for how to configure >> VTCR_EL2, non-boot CPUs rely on the calculated value. > > This would not be correct. Imagine a platform with heterogeneous processors > (such as big.LITTLE), each processors may have different set of "features" > (e.g max IPA size supported). You want Xen to use a common set of "features" > that would work on all CPUs. > > To give an example, your boot CPU may support maximum 48-bit IPA while all > the other CPUs would support maximum 40-bit IPA. If Xen decides to use > maximum 48-bit IPA, then page-tables would not work on other CPUs. > > In order to take the decision, you need to wait all CPUs to come up and look
[Xen-devel] [PATCH] x86/msr: further correct the emulation behaviour of MSR_PRED_CMD
Following commit a6aa678fa3 ("x86/msr: Correct the emulation behaviour of MSR_PRED_CMD") we may end up writing the low bit with the wrong value. While it's unlikely for a guest to want to write zero there, we should still permit (this without incurring the overhead of an actual barrier). Correcting this right away will also help whenever further bits in the MSR might become defined. Signed-off-by: Jan Beulich --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -247,7 +247,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t goto gp_fault; /* Rsvd bit set? */ if ( v == curr ) -wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB); +wrmsrl(MSR_PRED_CMD, val); break; case MSR_INTEL_MISC_FEATURES_ENABLES: ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] ALSA: xen-front: Implement ALSA virtual sound driver
On 04/16/2018 05:09 PM, Juergen Gross wrote: On 16/04/18 08:24, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Implement essential initialization of the sound driver: - introduce required data structures - handle driver registration - handle sound card registration - register sound driver on backend connection - remove sound driver on backend disconnect Initialize virtual sound card with streams according to the Xen store configuration. Implement ALSA driver operations including: - manage frontend/backend shared buffers - manage Xen bus event channel states Implement requests from front to back for ALSA PCM operations. - report ALSA period elapsed event: handle XENSND_EVT_CUR_POS notifications from the backend when stream position advances during playback/capture. The event carries a value of how many octets were played/captured at the time of the event. - implement explicit stream parameter negotiation between backend and frontend: handle XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval and the response to this request returns min/max interval for the parameter to be used. Signed-off-by: Oleksandr Andrushchenko --- sound/xen/Makefile| 3 +- sound/xen/xen_snd_front.c | 193 - sound/xen/xen_snd_front.h | 28 ++ sound/xen/xen_snd_front_alsa.c| 830 ++ sound/xen/xen_snd_front_alsa.h| 23 ++ sound/xen/xen_snd_front_evtchnl.c | 6 +- 6 files changed, 1080 insertions(+), 3 deletions(-) create mode 100644 sound/xen/xen_snd_front_alsa.c create mode 100644 sound/xen/xen_snd_front_alsa.h diff --git a/sound/xen/Makefile b/sound/xen/Makefile index f028bc30af5d..1e6470ecc2f2 100644 --- a/sound/xen/Makefile +++ b/sound/xen/Makefile @@ -3,6 +3,7 @@ snd_xen_front-objs := xen_snd_front.o \ xen_snd_front_cfg.o \ xen_snd_front_evtchnl.o \ - xen_snd_front_shbuf.o + xen_snd_front_shbuf.o \ + xen_snd_front_alsa.o obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c index 0569c6c596a3..1fef253ea21a 100644 --- a/sound/xen/xen_snd_front.c +++ b/sound/xen/xen_snd_front.c @@ -19,10 +19,201 @@ #include #include "xen_snd_front.h" +#include "xen_snd_front_alsa.h" #include "xen_snd_front_evtchnl.h" +#include "xen_snd_front_shbuf.h" + +static struct xensnd_req * +be_stream_prepare_req(struct xen_snd_front_evtchnl *evtchnl, u8 operation) +{ + struct xensnd_req *req; + + req = RING_GET_REQUEST(&evtchnl->u.req.ring, + evtchnl->u.req.ring.req_prod_pvt); + req->operation = operation; + req->id = evtchnl->evt_next_id++; + evtchnl->evt_id = req->id; + return req; +} + +static int be_stream_do_io(struct xen_snd_front_evtchnl *evtchnl) +{ + if (unlikely(evtchnl->state != EVTCHNL_STATE_CONNECTED)) + return -EIO; + + reinit_completion(&evtchnl->u.req.completion); + xen_snd_front_evtchnl_flush(evtchnl); + return 0; +} + +static int be_stream_wait_io(struct xen_snd_front_evtchnl *evtchnl) +{ + if (wait_for_completion_timeout(&evtchnl->u.req.completion, + msecs_to_jiffies(VSND_WAIT_BACK_MS)) <= 0) + return -ETIMEDOUT; + + return evtchnl->u.req.resp_status; +} + +int xen_snd_front_stream_query_hw_param(struct xen_snd_front_evtchnl *evtchnl, + struct xensnd_query_hw_param *hw_param_req, + struct xensnd_query_hw_param *hw_param_resp) +{ + struct xen_snd_front_info *front_info = evtchnl->front_info; + struct xensnd_req *req; + unsigned long flags; + int ret; + + mutex_lock(&evtchnl->u.req.req_io_lock); + + spin_lock_irqsave(&front_info->io_lock, flags); + req = be_stream_prepare_req(evtchnl, XENSND_OP_HW_PARAM_QUERY); + req->op.hw_param = *hw_param_req; + + ret = be_stream_do_io(evtchnl); + spin_unlock_irqrestore(&front_info->io_lock, flags); + + if (ret == 0) + ret = be_stream_wait_io(evtchnl); + + if (ret == 0) + *hw_param_resp = evtchnl->u.req.resp.hw_param; + + mutex_unlock(&evtchnl->u.req.req_io_lock); + return ret; +} + +int xen_snd_front_stream_prepare(struct xen_snd_front_evtchnl *evtchnl, +struct xen_snd_front_shbuf *sh_buf, +u8 format, unsigned int channels, +unsigned int rate, u32 buffer_sz, +u32 period_sz) +{ + struct xen_snd_front_info *front_info = evtchnl->front_info; + struct xensnd_req *req; + unsigned long flags; +
Re: [Xen-devel] [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling
On 04/17/2018 02:14 PM, Juergen Gross wrote: On 17/04/18 10:58, Oleksandr Andrushchenko wrote: On 04/16/2018 04:12 PM, Juergen Gross wrote: On 16/04/18 08:24, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Handle Xen event channels: - create for all configured streams and publish corresponding ring references and event channels in Xen store, so backend can connect - implement event channels interrupt handlers - create and destroy event channels with respect to Xen bus state Signed-off-by: Oleksandr Andrushchenko --- sound/xen/Makefile | 3 +- sound/xen/xen_snd_front.c | 10 +- sound/xen/xen_snd_front.h | 7 + sound/xen/xen_snd_front_evtchnl.c | 474 ++ sound/xen/xen_snd_front_evtchnl.h | 92 5 files changed, 584 insertions(+), 2 deletions(-) create mode 100644 sound/xen/xen_snd_front_evtchnl.c create mode 100644 sound/xen/xen_snd_front_evtchnl.h diff --git a/sound/xen/Makefile b/sound/xen/Makefile index 06705bef61fa..03c669984000 100644 --- a/sound/xen/Makefile +++ b/sound/xen/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 OR MIT snd_xen_front-objs := xen_snd_front.o \ - xen_snd_front_cfg.o + xen_snd_front_cfg.o \ + xen_snd_front_evtchnl.o obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c index 65d2494a9d14..eb46bf4070f9 100644 --- a/sound/xen/xen_snd_front.c +++ b/sound/xen/xen_snd_front.c @@ -18,9 +18,11 @@ #include #include "xen_snd_front.h" +#include "xen_snd_front_evtchnl.h" Does it really make sense to have multiple driver-private headers? I think those can be merged. I would really like to keep it separate as it clearly shows which stuff belongs to which modules. At least for me it is easier to maintain it this way. static void xen_snd_drv_fini(struct xen_snd_front_info *front_info) { + xen_snd_front_evtchnl_free_all(front_info); } static int sndback_initwait(struct xen_snd_front_info *front_info) @@ -32,7 +34,12 @@ static int sndback_initwait(struct xen_snd_front_info *front_info) if (ret < 0) return ret; - return 0; + /* create event channels for all streams and publish */ + ret = xen_snd_front_evtchnl_create_all(front_info, num_streams); + if (ret < 0) + return ret; + + return xen_snd_front_evtchnl_publish_all(front_info); } static int sndback_connect(struct xen_snd_front_info *front_info) @@ -122,6 +129,7 @@ static int xen_drv_probe(struct xenbus_device *xb_dev, return -ENOMEM; front_info->xb_dev = xb_dev; + spin_lock_init(&front_info->io_lock); dev_set_drvdata(&xb_dev->dev, front_info); return xenbus_switch_state(xb_dev, XenbusStateInitialising); diff --git a/sound/xen/xen_snd_front.h b/sound/xen/xen_snd_front.h index b52226cb30bc..9c2ffbb4e4b8 100644 --- a/sound/xen/xen_snd_front.h +++ b/sound/xen/xen_snd_front.h @@ -13,9 +13,16 @@ #include "xen_snd_front_cfg.h" +struct xen_snd_front_evtchnl_pair; + struct xen_snd_front_info { struct xenbus_device *xb_dev; + /* serializer for backend IO: request/response */ + spinlock_t io_lock; + int num_evt_pairs; + struct xen_snd_front_evtchnl_pair *evt_pairs; + struct xen_front_cfg_card cfg; }; diff --git a/sound/xen/xen_snd_front_evtchnl.c b/sound/xen/xen_snd_front_evtchnl.c new file mode 100644 index ..9ece39f938f8 --- /dev/null +++ b/sound/xen/xen_snd_front_evtchnl.c @@ -0,0 +1,474 @@ +// SPDX-License-Identifier: GPL-2.0 OR MIT + +/* + * Xen para-virtual sound device + * + * Copyright (C) 2016-2018 EPAM Systems Inc. + * + * Author: Oleksandr Andrushchenko + */ + +#include +#include +#include +#include + +#include "xen_snd_front.h" +#include "xen_snd_front_cfg.h" +#include "xen_snd_front_evtchnl.h" + +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) +{ + struct xen_snd_front_evtchnl *channel = dev_id; + struct xen_snd_front_info *front_info = channel->front_info; + struct xensnd_resp *resp; + RING_IDX i, rp; + unsigned long flags; + + if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED)) + return IRQ_HANDLED; + + spin_lock_irqsave(&front_info->io_lock, flags); + +again: + rp = channel->u.req.ring.sring->rsp_prod; + /* ensure we see queued responses up to rp */ + rmb(); + + for (i = channel->u.req.ring.rsp_cons; i != rp; i++) { + resp = RING_GET_RESPONSE(&channel->u.req.ring, i); + if (resp->id != channel->evt_id) + continue; + switch (resp->operation) { + case XENSND_OP_OPEN: + /* fall through */ + case XENSND_OP_CLOSE: + /* fall through */ + case XENSND_OP_READ: + /* fall through */ + case XENSND_OP_WRITE: + /* fall through */ + c
Re: [Xen-devel] [PATCH v2 4/5] ALSA: xen-front: Implement handling of shared buffers
On 17/04/18 11:22, Oleksandr Andrushchenko wrote: > On 04/16/2018 04:39 PM, Juergen Gross wrote: >> On 16/04/18 08:24, Oleksandr Andrushchenko wrote: >>> +static int alloc_int_buffers(struct xen_snd_front_shbuf *buf, >>> + int num_pages_dir, int num_pages_buffer, >>> + int num_grefs) >>> +{ >>> + buf->grefs = kcalloc(num_grefs, sizeof(*buf->grefs), GFP_KERNEL); >>> + if (!buf->grefs) >>> + return -ENOMEM; >>> + >>> + buf->directory = kcalloc(num_pages_dir, XEN_PAGE_SIZE, GFP_KERNEL); >>> + if (!buf->directory) >>> + goto fail; >>> + >>> + buf->buffer_sz = num_pages_buffer * XEN_PAGE_SIZE; >>> + buf->buffer = alloc_pages_exact(buf->buffer_sz, GFP_KERNEL); >>> + if (!buf->buffer) >>> + goto fail; >>> + >>> + return 0; >>> + >>> +fail: >>> + kfree(buf->grefs); >>> + buf->grefs = NULL; >>> + kfree(buf->directory); >> Why do you need to free those here? Shouldn't that be done via >> xen_snd_front_shbuf_free() in case of an error? > At this place we only allocate memory, but xen_snd_front_shbuf_free > will also try to gnttab_end_foreign_access if buf->grefs != NULL. Okay. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling
On 17/04/18 10:58, Oleksandr Andrushchenko wrote: > On 04/16/2018 04:12 PM, Juergen Gross wrote: >> On 16/04/18 08:24, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> Handle Xen event channels: >>> - create for all configured streams and publish >>> corresponding ring references and event channels in Xen store, >>> so backend can connect >>> - implement event channels interrupt handlers >>> - create and destroy event channels with respect to Xen bus state >>> >>> Signed-off-by: Oleksandr Andrushchenko >>> >>> --- >>> sound/xen/Makefile | 3 +- >>> sound/xen/xen_snd_front.c | 10 +- >>> sound/xen/xen_snd_front.h | 7 + >>> sound/xen/xen_snd_front_evtchnl.c | 474 >>> ++ >>> sound/xen/xen_snd_front_evtchnl.h | 92 >>> 5 files changed, 584 insertions(+), 2 deletions(-) >>> create mode 100644 sound/xen/xen_snd_front_evtchnl.c >>> create mode 100644 sound/xen/xen_snd_front_evtchnl.h >>> >>> diff --git a/sound/xen/Makefile b/sound/xen/Makefile >>> index 06705bef61fa..03c669984000 100644 >>> --- a/sound/xen/Makefile >>> +++ b/sound/xen/Makefile >>> @@ -1,6 +1,7 @@ >>> # SPDX-License-Identifier: GPL-2.0 OR MIT >>> snd_xen_front-objs := xen_snd_front.o \ >>> - xen_snd_front_cfg.o >>> + xen_snd_front_cfg.o \ >>> + xen_snd_front_evtchnl.o >>> obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o >>> diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c >>> index 65d2494a9d14..eb46bf4070f9 100644 >>> --- a/sound/xen/xen_snd_front.c >>> +++ b/sound/xen/xen_snd_front.c >>> @@ -18,9 +18,11 @@ >>> #include >>> #include "xen_snd_front.h" >>> +#include "xen_snd_front_evtchnl.h" >> Does it really make sense to have multiple driver-private headers? >> >> I think those can be merged. > I would really like to keep it separate as it clearly > shows which stuff belongs to which modules. > At least for me it is easier to maintain it this way. >> >>> static void xen_snd_drv_fini(struct xen_snd_front_info *front_info) >>> { >>> + xen_snd_front_evtchnl_free_all(front_info); >>> } >>> static int sndback_initwait(struct xen_snd_front_info *front_info) >>> @@ -32,7 +34,12 @@ static int sndback_initwait(struct >>> xen_snd_front_info *front_info) >>> if (ret < 0) >>> return ret; >>> - return 0; >>> + /* create event channels for all streams and publish */ >>> + ret = xen_snd_front_evtchnl_create_all(front_info, num_streams); >>> + if (ret < 0) >>> + return ret; >>> + >>> + return xen_snd_front_evtchnl_publish_all(front_info); >>> } >>> static int sndback_connect(struct xen_snd_front_info *front_info) >>> @@ -122,6 +129,7 @@ static int xen_drv_probe(struct xenbus_device >>> *xb_dev, >>> return -ENOMEM; >>> front_info->xb_dev = xb_dev; >>> + spin_lock_init(&front_info->io_lock); >>> dev_set_drvdata(&xb_dev->dev, front_info); >>> return xenbus_switch_state(xb_dev, XenbusStateInitialising); >>> diff --git a/sound/xen/xen_snd_front.h b/sound/xen/xen_snd_front.h >>> index b52226cb30bc..9c2ffbb4e4b8 100644 >>> --- a/sound/xen/xen_snd_front.h >>> +++ b/sound/xen/xen_snd_front.h >>> @@ -13,9 +13,16 @@ >>> #include "xen_snd_front_cfg.h" >>> +struct xen_snd_front_evtchnl_pair; >>> + >>> struct xen_snd_front_info { >>> struct xenbus_device *xb_dev; >>> + /* serializer for backend IO: request/response */ >>> + spinlock_t io_lock; >>> + int num_evt_pairs; >>> + struct xen_snd_front_evtchnl_pair *evt_pairs; >>> + >>> struct xen_front_cfg_card cfg; >>> }; >>> diff --git a/sound/xen/xen_snd_front_evtchnl.c >>> b/sound/xen/xen_snd_front_evtchnl.c >>> new file mode 100644 >>> index ..9ece39f938f8 >>> --- /dev/null >>> +++ b/sound/xen/xen_snd_front_evtchnl.c >>> @@ -0,0 +1,474 @@ >>> +// SPDX-License-Identifier: GPL-2.0 OR MIT >>> + >>> +/* >>> + * Xen para-virtual sound device >>> + * >>> + * Copyright (C) 2016-2018 EPAM Systems Inc. >>> + * >>> + * Author: Oleksandr Andrushchenko >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include "xen_snd_front.h" >>> +#include "xen_snd_front_cfg.h" >>> +#include "xen_snd_front_evtchnl.h" >>> + >>> +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) >>> +{ >>> + struct xen_snd_front_evtchnl *channel = dev_id; >>> + struct xen_snd_front_info *front_info = channel->front_info; >>> + struct xensnd_resp *resp; >>> + RING_IDX i, rp; >>> + unsigned long flags; >>> + >>> + if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED)) >>> + return IRQ_HANDLED; >>> + >>> + spin_lock_irqsave(&front_info->io_lock, flags); >>> + >>> +again: >>> + rp = channel->u.req.ring.sring->rsp_prod; >>> + /* ensure we see queued responses up to rp */ >>> + rmb(); >>> + >>> + for (i = channel->u.req.ring.rsp_cons
Re: [Xen-devel] [PATCH v2 2/5] ALSA: xen-front: Read sound driver configuration from Xen store
On 17/04/18 10:42, Oleksandr Andrushchenko wrote: > On 04/16/2018 03:55 PM, Juergen Gross wrote: >> On 16/04/18 08:24, Oleksandr Andrushchenko wrote: >>> + goto fail; >>> + } >>> + >>> + if (!strncasecmp(str, XENSND_STREAM_TYPE_PLAYBACK, >>> + sizeof(XENSND_STREAM_TYPE_PLAYBACK))) { >>> + stream = &pcm_instance->streams_pb[(*cur_pb)++]; >>> + } else if (!strncasecmp(str, XENSND_STREAM_TYPE_CAPTURE, >>> + sizeof(XENSND_STREAM_TYPE_CAPTURE))) { >>> + stream = &pcm_instance->streams_cap[(*cur_cap)++]; >>> + } else { >>> + ret = -EINVAL; >>> + goto fail; >>> + } >> Until here this function looks very much like cfg_get_stream_type(). >> Can't they use a common sub-function? > Not really, because cfg_get_stream_type uses kasprintf > for strings and this one devm_kasprintf. Trying to make > a common sub-func doesn't make sense to me Aah, okay. Didn't spot that. >>> + /* start from default PCM HW configuration for the card */ >>> + cfg_read_pcm_hw(xb_dev->nodename, NULL, &cfg->pcm_hw); >>> + >>> + cfg->pcm_instances = >>> + devm_kcalloc(&front_info->xb_dev->dev, num_devices, >>> + sizeof(struct xen_front_cfg_pcm_instance), >>> + GFP_KERNEL); >>> + if (!cfg->pcm_instances) >>> + return -ENOMEM; >>> + >>> + for (i = 0; i < num_devices; i++) { >>> + ret = cfg_device(front_info, &cfg->pcm_instances[i], >>> + &cfg->pcm_hw, xb_dev->nodename, i, stream_cnt); >>> + if (ret < 0) >>> + return ret; >> Who will free all the memory allocated until now in case of an error? > The memory is allocated with devm_xxx functions, so it will > be freed on device destructions automatically >> >> And I think when removing the device freeing the memory is missing, too. > Same as above, the kernel will take care of it while destroying the device Okay, thanks. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly
On 17/04/18 11:52, Mirela Simonovic wrote: Hi Julien, Hi Mirela, On Mon, Apr 16, 2018 at 5:21 PM, Julien Grall wrote: On 16/04/18 14:41, Mirela Simonovic wrote: On Mon, Apr 16, 2018 at 3:14 PM, Julien Grall wrote: On 12/04/18 22:31, Stefano Stabellini wrote: On Thu, 12 Apr 2018, Julien Grall wrote: On 12/04/18 00:46, Stefano Stabellini wrote: On Wed, 11 Apr 2018, Julien Grall wrote: On 11/04/18 14:19, Mirela Simonovic wrote: I guess the rcu_barrier() in the function handling suspend/resume works. But that doesn't cover the hotplug case. Looking at x86, suspend/resume case. For the hotplug case, there are an rcu_barrier in cpu_{up,down}_helper but they are only present in the case of cpu_{up,down} failed. I am not entirely sure how this is handled in x86 Andrew, Jan, do you know when the percpu will be free on hotplug? It is call to call_rcu(...) but I am not sure when this is going to be executed. AFAIK disable/enable_nonboot_cpus() is the only way to do the hotplug and rcu_barrier() is not included in the flow. That's not the only way. I clearly specified one in my previous answer (see cpu_{up,down}_helper) and there are other place (look for cpu_up). I've looked at cpu_{up,down}_helper and cpu_up and I'm convinced now that adding rcu_barrier() prior to calling enable_nonboot_cpus() is the right approch. cpu_{up,down}_helper functions exist only for x86. They have nothing very x86 specific AFAICT so they could potentially be used for Arm when XEN_SYSCTL_hotplug will be implemented. cpu_up_helper() does call rcu_barrier() prior to calling cpu_up(). That's not true. Below the code for cpu_up_helper(): int ret = cpu_up(cpu); <- First call if ( ret == -EBUSY ) { rcu_barrier(); <- RCU barrier ret = cpu_up(cpu); <- Second call } return ret; So the rcu_barrier is called after cpu_up() in case it returns -EBUSY. So calling rcu_barrier() is expected to be done prior to calling cpu_up() (or enable_nonboot_cpus(), which is just a wrapper for cpu_up()). I believe this is right way to do because cpu_up() is used for enabling non-boot CPUs in both boot and suspend/hotplug scenarios, while rcu_barrier() is not required in boot scenario. Therefore, I'll add rcu_barrier() prior to calling enable_nonboot_cpus(). If I missed something please let me know. See above, this is exactly why I asked Andrew & Jan input on how rcu work is flushed when using cpu_up_helper/cpu_down_helper. Because I don't understand if it is meant to work. So I would like to see whether it would make sense to put the rcu_barrier() somewhere else to cover every call of cpu_up(). Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 122339: trouble: broken/fail/pass
flight 122339 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/122339/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale broken test-armhf-armhf-xl-arndale 4 host-install(4)broken REGR. vs. 122212 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 122212 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122212 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122212 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122212 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122212 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122212 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122212 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: qemuu2a6b5372d7bad038fe27f9c60e85ef5c8a15e311 baseline version: qemuu38e83a71d02e026d4a6d0ab1ef9855c4924c2c68 Last test of basis 122212 2018-04-12 22:53:39 Z4 days Failing since122328 2018-04-16 09:43:42 Z1 days2 attempts Testing same since 122339 2018-04-16 23:14:53 Z0 days1 attempts People who touched revisions under test: Alex Bennée Bastian Koppelmann Emilio G. Cota Laurent Vivier Max Reitz Michael S. Tsirkin Michael Tokarev Pavel Dovgalyuk Peter Maydell Philippe Mathieu-Daudé Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm
Re: [Xen-devel] [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly
Hi Julien, On Mon, Apr 16, 2018 at 5:21 PM, Julien Grall wrote: > > > On 16/04/18 14:41, Mirela Simonovic wrote: >> >> On Mon, Apr 16, 2018 at 3:14 PM, Julien Grall >> wrote: >>> >>> On 12/04/18 22:31, Stefano Stabellini wrote: On Thu, 12 Apr 2018, Julien Grall wrote: > > On 12/04/18 00:46, Stefano Stabellini wrote: >> >> On Wed, 11 Apr 2018, Julien Grall wrote: >>> >>> On 11/04/18 14:19, Mirela Simonovic wrote: >>> >>> I guess the rcu_barrier() in the function handling suspend/resume works. >>> But >>> that doesn't cover the hotplug case. Looking at x86, suspend/resume case. >>> For the hotplug case, there are an rcu_barrier in cpu_{up,down}_helper >>> but >>> they are only present in the case of cpu_{up,down} failed. I am not >>> entirely >>> sure how this is handled in x86 >>> >>> Andrew, Jan, do you know when the percpu will be free on hotplug? It is >>> call >>> to call_rcu(...) but I am not sure when this is going to be executed. >>> >> >> AFAIK disable/enable_nonboot_cpus() is the only way to do the hotplug >> and rcu_barrier() is not included in the flow. > > > That's not the only way. I clearly specified one in my previous answer (see > cpu_{up,down}_helper) and there are other place (look for cpu_up). > I've looked at cpu_{up,down}_helper and cpu_up and I'm convinced now that adding rcu_barrier() prior to calling enable_nonboot_cpus() is the right approch. cpu_{up,down}_helper functions exist only for x86. cpu_up_helper() does call rcu_barrier() prior to calling cpu_up(). So calling rcu_barrier() is expected to be done prior to calling cpu_up() (or enable_nonboot_cpus(), which is just a wrapper for cpu_up()). I believe this is right way to do because cpu_up() is used for enabling non-boot CPUs in both boot and suspend/hotplug scenarios, while rcu_barrier() is not required in boot scenario. Therefore, I'll add rcu_barrier() prior to calling enable_nonboot_cpus(). If I missed something please let me know. Thanks, Mirela > Cheers, > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On 04/17/2018 01:49 PM, Razvan Cojocaru wrote: > On 04/17/2018 11:24 AM, Razvan Cojocaru wrote: >> On 04/16/2018 11:21 PM, George Dunlap wrote: >>> On Mon, Apr 16, 2018 at 7:46 PM, Razvan Cojocaru >>> wrote: On 04/16/2018 08:47 PM, George Dunlap wrote: > On 04/13/2018 03:44 PM, Razvan Cojocaru wrote: >> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote: >>> Debugging continues. >> >> Finally, the attached patch seems to get the display unstuck in my >> scenario, although for one guest I get: >> >> (XEN) d2v0 Unexpected vmexit: reason 49 >> (XEN) domain_crash called from vmx.c:4120 >> (XEN) Domain 2 (vcpu#0) crashed on cpu#1: >> (XEN) [ Xen-4.11-unstable x86_64 debug=y Not tainted ] >> (XEN) CPU:1 >> (XEN) RIP:0010:[] >> (XEN) RFLAGS: 00010246 CONTEXT: hvm guest (d2v0) >> (XEN) rax: f8800300 rbx: f900c0083db0 rcx: >> aa55aa55 >> (XEN) rdx: fa80041bdc41 rsi: f900c00c69a0 rdi: >> 0001 >> (XEN) rbp: rsp: f88002ee9ef0 r8: >> fa80041bdc40 >> (XEN) r9: f80001810e80 r10: fa800342aa70 r11: >> f88002ee9e80 >> (XEN) r12: 0005 r13: 0001 r14: >> f900c00c08b0 >> (XEN) r15: 0001 cr0: 80050031 cr4: >> 000406f8 >> (XEN) cr3: ef771000 cr2: f900c00c8000 >> (XEN) fsb: fffde000 gsb: f80001810d00 gss: >> 07fdc000 >> (XEN) ds: 002b es: 002b fs: 0053 gs: 002b ss: 0018 cs: 0010 >> >> i.e. EXIT_REASON_EPT_MISCONFIG - so not of the woods yet. I am hoping >> somebody more familiar with the code can point to a more elegant >> solution if one exists. > > I think I have an idea what's going on, but it's complicated. :-) > > Basically, the logdirty functionality isn't simple, and needs careful > thought on how to integrate it. I'll write some more tomorrow, and see > if I can come up with a solution. I think I know why this happens for the one guest - the other guests start at a certain resolution display-wise and stay that way until shutdown. This particular guest starts with a larger screen, then goes to roughly 2/3rds of it, then tries to go back to the initial larger one - at which point the above happens. I assume this corresponds to some pages being removed and/or added. I'll test this theory more tomorrow - if it's correct I should be able to reproduce the crash (with the patch) by simply resetting the screen resolution (increasing it). >>> >>> The trick is that p2m_change_type doesn't actually iterate over the >>> entire p2m range, individually changing entries as it goes. Instead >>> it misconfigures the entries at the top-level, which causes the kinds >>> of faults shown above. As it gets faults for each entry, it checks >>> the current type, the logdirty ranges, and the global logdirty bit to >>> determine what the new types should be. >>> >>> Your patch makes it so that all the altp2ms now get the >>> misconfiguration when the logdirty range is changed; but clearly >>> handling the misconfiguration isn't integrated properly with the >>> altp2m system yet. Doing it right may take some thought. >> >> FWIW, the attached patch has solved the misconfig-related domain crash >> for me (though I'm very likely missing some subtleties). It all seems to >> work as expected when enabling altp2m and switching early to a new view. >> However, now I have domUs with a frozen display when I disconnect the >> introspection application (that is, after I switch back to the default >> view and disable altp2m on the domain). > > The for() loop in the previous patch is unnecessary, so here's a new > (cleaner) patch. I can't get the guest to freeze the display when > detaching anymore - unrelated to the for() - (so it might have been > something else in my setup), but I'll watch for it in the following days. > > Hopefully this is either a reasonable fix or a basis for one. Apologies, forgot to actually attach the patch. Here it is. diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c index 14b5939..8495039 100644 --- a/xen/arch/x86/mm/p2m-ept.c +++ b/xen/arch/x86/mm/p2m-ept.c @@ -17,6 +17,7 @@ #include #include +#include #include #include #include @@ -656,6 +657,9 @@ bool_t ept_handle_misconfig(uint64_t gpa) bool_t spurious; int rc; +if ( altp2m_active(curr->domain) ) +p2m = p2m_get_altp2m(curr); + p2m_lock(p2m); spurious = curr->arch.hvm_vmx.ept_spurious_misconfig; @@ -1375,8 +1379,15 @@ void setup_ept_dump(void) void p2m_init_altp2m_ept(struct domain *d, unsigned int i) { struct p2m_domain *p2m = d->arch.altp2m_p2m[i]; +struct p2m_domain *hostp2m = p2m_get_hostp2m(d); struct ept_data *ept; +p2m->max_mapp
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On 04/17/2018 11:24 AM, Razvan Cojocaru wrote: > On 04/16/2018 11:21 PM, George Dunlap wrote: >> On Mon, Apr 16, 2018 at 7:46 PM, Razvan Cojocaru >> wrote: >>> On 04/16/2018 08:47 PM, George Dunlap wrote: On 04/13/2018 03:44 PM, Razvan Cojocaru wrote: > On 04/11/2018 11:04 AM, Razvan Cojocaru wrote: >> Debugging continues. > > Finally, the attached patch seems to get the display unstuck in my > scenario, although for one guest I get: > > (XEN) d2v0 Unexpected vmexit: reason 49 > (XEN) domain_crash called from vmx.c:4120 > (XEN) Domain 2 (vcpu#0) crashed on cpu#1: > (XEN) [ Xen-4.11-unstable x86_64 debug=y Not tainted ] > (XEN) CPU:1 > (XEN) RIP:0010:[] > (XEN) RFLAGS: 00010246 CONTEXT: hvm guest (d2v0) > (XEN) rax: f8800300 rbx: f900c0083db0 rcx: > aa55aa55 > (XEN) rdx: fa80041bdc41 rsi: f900c00c69a0 rdi: > 0001 > (XEN) rbp: rsp: f88002ee9ef0 r8: > fa80041bdc40 > (XEN) r9: f80001810e80 r10: fa800342aa70 r11: > f88002ee9e80 > (XEN) r12: 0005 r13: 0001 r14: > f900c00c08b0 > (XEN) r15: 0001 cr0: 80050031 cr4: > 000406f8 > (XEN) cr3: ef771000 cr2: f900c00c8000 > (XEN) fsb: fffde000 gsb: f80001810d00 gss: > 07fdc000 > (XEN) ds: 002b es: 002b fs: 0053 gs: 002b ss: 0018 cs: 0010 > > i.e. EXIT_REASON_EPT_MISCONFIG - so not of the woods yet. I am hoping > somebody more familiar with the code can point to a more elegant > solution if one exists. I think I have an idea what's going on, but it's complicated. :-) Basically, the logdirty functionality isn't simple, and needs careful thought on how to integrate it. I'll write some more tomorrow, and see if I can come up with a solution. >>> >>> I think I know why this happens for the one guest - the other guests >>> start at a certain resolution display-wise and stay that way until shutdown. >>> >>> This particular guest starts with a larger screen, then goes to roughly >>> 2/3rds of it, then tries to go back to the initial larger one - at which >>> point the above happens. I assume this corresponds to some pages being >>> removed and/or added. I'll test this theory more tomorrow - if it's >>> correct I should be able to reproduce the crash (with the patch) by >>> simply resetting the screen resolution (increasing it). >> >> The trick is that p2m_change_type doesn't actually iterate over the >> entire p2m range, individually changing entries as it goes. Instead >> it misconfigures the entries at the top-level, which causes the kinds >> of faults shown above. As it gets faults for each entry, it checks >> the current type, the logdirty ranges, and the global logdirty bit to >> determine what the new types should be. >> >> Your patch makes it so that all the altp2ms now get the >> misconfiguration when the logdirty range is changed; but clearly >> handling the misconfiguration isn't integrated properly with the >> altp2m system yet. Doing it right may take some thought. > > FWIW, the attached patch has solved the misconfig-related domain crash > for me (though I'm very likely missing some subtleties). It all seems to > work as expected when enabling altp2m and switching early to a new view. > However, now I have domUs with a frozen display when I disconnect the > introspection application (that is, after I switch back to the default > view and disable altp2m on the domain). The for() loop in the previous patch is unnecessary, so here's a new (cleaner) patch. I can't get the guest to freeze the display when detaching anymore - unrelated to the for() - (so it might have been something else in my setup), but I'll watch for it in the following days. Hopefully this is either a reasonable fix or a basis for one. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 1/1] xen: credit2: rb-tree for runqueues
On Tue, 2018-04-03 at 22:25 +0530, Praveen Kumar wrote: > The patch optimized the sorted credit2 runq from simple linked list > to > rb-tree implementation. This way we will gain performance and > scalability when the number of vCPUs are huge. > > Signed-off-by: Praveen Kumar > --- a/xen/common/sched_credit2.c > +++ b/xen/common/sched_credit2.c > @@ -600,6 +601,29 @@ static inline bool has_cap(const struct > csched2_vcpu *svc) > return svc->budget != STIME_MAX; > } > > +static void runq_insert_rb(struct rb_root *root, > + struct csched2_vcpu *svc, > + int *pos) > I'd call this rb_insert() or rb_runq_insert(), but that's taste (and it's certainly a minor thing). > +{ > +struct csched2_vcpu *entry = NULL; > +struct rb_node **node = &root->rb_node; > +struct rb_node *parent = NULL; > + > +while (*node) { > +parent = *node; > +entry = rb_entry(parent, struct csched2_vcpu, runq_elem); > +// Check if we are maintaining the sorted > Pointless comment. I'd leave the line blank (but that's taste again). > +if ( svc->credit < entry->credit ) > +node = &parent->rb_left; > +else > +node = &parent->rb_right; > + > +(*pos)++; > +} > +rb_link_node(&svc->runq_elem, parent, node); > +rb_insert_color(&svc->runq_elem, root); > +} > Wait, where's the part where we cache which element is the one with the highest credits? (And the same applies to the tree-removal function, of course.) In fact, we need a field for storing such a cache in the runqueue data structure as well, and we need to keep it updated. Linux (recently) added an rb-tree variant that do this internally, see cd9e61ed1eebb "rbtree: cache leftmost node internally", and how such a variant is used, e.g. 2161573ecd693 "sched/deadline: replace earliest dl and rq leftmost caching". So, I'd say that we either import that from there, or do the caching of leftmost element explicitly where needed. Note that, however, that Linux's variant caches leftmost, because they always use rb-trees for structures where the head of the queue is the element with the _smallest_ key. In our case here, we want the queue ordered in descending credit order, so it must be thought carefully whether or not we could use the new variant (maybe "just" inverting the binary search tree relationship), or we'd need another one that caches righmost. I would suggest we do not try to use the rb_*_cached() functions, and cache rightmost explicitly in runqueue_data. > @@ -3201,17 +3225,21 @@ csched2_runtime(const struct scheduler *ops, > int cpu, > * 2) If there's someone waiting whose credit is positive, > *run until your credit ~= his. > */ > -if ( ! list_empty(runq) ) > +if ( ! RB_EMPTY_ROOT(runq) ) > { > -struct csched2_vcpu *swait = runq_elem(runq->next); > +// Find the left most element, which is the most probable > candidate > +struct rb_node *node = rb_first(runq); > Err... is it? Isn't the leftmost element the one with the _least_ credits? It looks to me that we want rb_last(). And IAC, we don't want to have to traverse the tree to get the runnable vcpu with the highest credit, we want it available in O(1) time. That's why we want to cache it. > +// TODO Can we take rb_next ? > +//struct rb_node *node = &rb_next(root->rb_node); > + What do you mean here? > +struct csched2_vcpu *swait = runq_elem(node); > if ( ! is_idle_vcpu(swait->vcpu) > && swait->credit > 0 ) > { > rt_credit = snext->credit - swait->credit; > } > } > @@ -3345,9 +3373,8 @@ runq_candidate(struct csched2_runqueue_data > *rqd, > snext = csched2_vcpu(idle_vcpu[cpu]); > > check_runq: > -list_for_each_safe( iter, temp, &rqd->runq ) > -{ > -struct csched2_vcpu * svc = list_entry(iter, struct > csched2_vcpu, runq_elem); > +for (iter = rb_first(&rqd->runq); iter != NULL; iter = > rb_next(iter)) { > +struct csched2_vcpu * svc = rb_entry(iter, struct > csched2_vcpu, runq_elem); > Same as above. I don't think this is from where we want to start. And no matter whether we want to start from rb_first() or rb_last(), we certainly don't want to have to traverse the tree to get to there. > @@ -3761,8 +3789,8 @@ csched2_dump(const struct scheduler *ops) > dump_pcpu(ops, j); > > printk("RUNQ:\n"); > -list_for_each( iter, runq ) > -{ > + > +for (iter = rb_first(runq); iter != NULL; iter = > rb_next(iter)) { > And the same applies here as well. I think that, if we want the runqueue printed in the proper order, we need to start from the righmost, and use rb_prev(). Oh, and about caching, I'd say it is okay if you want to turn this into a series, the first patch of which does not have it, and you introduce it in the second patch. Regards, Dario -- <
Re: [Xen-devel] 答复: [PATCH] x86/hpet: add a lock when cpu clear cpumask in hpet_broadcast_exit();
>>> On 17.04.18 at 07:44, wrote: > 发件人: Jan Beulich > 发送时间: 2018年4月16日 19:48 On 16.04.18 at 10:00, wrote: >> --- a/xen/arch/x86/hpet.c >> +++ b/xen/arch/x86/hpet.c >> @@ -740,7 +740,9 @@ void hpet_broadcast_exit(void) >> if ( !reprogram_timer(deadline) ) >> raise_softirq(TIMER_SOFTIRQ); >> >> +spin_lock_irq(&ch->lock); >> cpumask_clear_cpu(cpu, ch->cpumask); >> +spin_unlock_irq(&ch->lock); > > Rather than this, how about eliminating the cpumask_empty() call > in favor of just the cpumask_first() one in hpet_detach_channel() > (with a local variable storing the intermediate result)? Or if acquiring > the locking can't be avoided here, you would perhaps better not > drop it before calling hpet_detach_channel() (which has only this > single call site and hence would be straightforward to adjust). > > [DavidWang]: The experiment proved that a local variable storing the > intermediate result can slove the problem. On one hand a local variable is > more efficient than adding lock, On the other it is not very clear for > reading. In fact, In hpet_detach_channel(), a lock for ch->lock will be > added. > Can we move the lock( in hpet_detach_channel()) backward to calling > cpumask_clear_cpu() and drop it in function (hpet_detach_channel()) ? > Looking forward to your suggestion. I'd certainly prefer the local variable approach - I'm not sure why you think this introduces an issue with readability. Quite the inverse I would say, it eliminates the problematic interdependency between the cpumask_empty() and cpumask_first() calls. It is only if there's a _technical_ reason speaking against this approach when I'd view the revised locking as a viable alternative. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/5] ALSA: xen-front: Implement handling of shared buffers
On 04/16/2018 04:39 PM, Juergen Gross wrote: On 16/04/18 08:24, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Implement shared buffer handling according to the para-virtualized sound device protocol at xen/interface/io/sndif.h: - manage buffer memory - handle granted references - handle page directories Signed-off-by: Oleksandr Andrushchenko --- sound/xen/Makefile | 3 +- sound/xen/xen_snd_front.c | 8 ++ sound/xen/xen_snd_front_shbuf.c | 193 sound/xen/xen_snd_front_shbuf.h | 36 4 files changed, 239 insertions(+), 1 deletion(-) create mode 100644 sound/xen/xen_snd_front_shbuf.c create mode 100644 sound/xen/xen_snd_front_shbuf.h diff --git a/sound/xen/Makefile b/sound/xen/Makefile index 03c669984000..f028bc30af5d 100644 --- a/sound/xen/Makefile +++ b/sound/xen/Makefile @@ -2,6 +2,7 @@ snd_xen_front-objs := xen_snd_front.o \ xen_snd_front_cfg.o \ - xen_snd_front_evtchnl.o + xen_snd_front_evtchnl.o \ + xen_snd_front_shbuf.o obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c index eb46bf4070f9..0569c6c596a3 100644 --- a/sound/xen/xen_snd_front.c +++ b/sound/xen/xen_snd_front.c @@ -11,6 +11,7 @@ #include #include +#include #include #include #include @@ -186,6 +187,13 @@ static struct xenbus_driver xen_driver = { static int __init xen_drv_init(void) { + /* At the moment we only support case with XEN_PAGE_SIZE == PAGE_SIZE */ + if (XEN_PAGE_SIZE != PAGE_SIZE) { + pr_err(XENSND_DRIVER_NAME ": different kernel and Xen page sizes are not supported: XEN_PAGE_SIZE (%lu) != PAGE_SIZE (%lu)\n", + XEN_PAGE_SIZE, PAGE_SIZE); + return -ENODEV; + } Do you really want to print that error message on bare metal? will move it down after xen_domain/xen_has_pv_devices checks + if (!xen_domain()) return -ENODEV; diff --git a/sound/xen/xen_snd_front_shbuf.c b/sound/xen/xen_snd_front_shbuf.c new file mode 100644 index ..6845dbc7fdf5 --- /dev/null +++ b/sound/xen/xen_snd_front_shbuf.c @@ -0,0 +1,193 @@ +// SPDX-License-Identifier: GPL-2.0 OR MIT + +/* + * Xen para-virtual sound device + * + * Copyright (C) 2016-2018 EPAM Systems Inc. + * + * Author: Oleksandr Andrushchenko + */ + +#include +#include + +#include "xen_snd_front_shbuf.h" + +grant_ref_t xen_snd_front_shbuf_get_dir_start(struct xen_snd_front_shbuf *buf) +{ + if (!buf->grefs) + return GRANT_INVALID_REF; + + return buf->grefs[0]; +} + +void xen_snd_front_shbuf_clear(struct xen_snd_front_shbuf *buf) +{ + memset(buf, 0, sizeof(*buf)); +} + +void xen_snd_front_shbuf_free(struct xen_snd_front_shbuf *buf) +{ + int i; + + if (buf->grefs) { + for (i = 0; i < buf->num_grefs; i++) + if (buf->grefs[i] != GRANT_INVALID_REF) + gnttab_end_foreign_access(buf->grefs[i], + 0, 0UL); + kfree(buf->grefs); + } + kfree(buf->directory); + free_pages_exact(buf->buffer, buf->buffer_sz); + xen_snd_front_shbuf_clear(buf); +} + +/* + * number of grant references a page can hold with respect to the + * xensnd_page_directory header + */ +#define XENSND_NUM_GREFS_PER_PAGE ((XEN_PAGE_SIZE - \ + offsetof(struct xensnd_page_directory, gref)) / \ + sizeof(grant_ref_t)) + +static void fill_page_dir(struct xen_snd_front_shbuf *buf, + int num_pages_dir) +{ + struct xensnd_page_directory *page_dir; + unsigned char *ptr; + int i, cur_gref, grefs_left, to_copy; + + ptr = buf->directory; + grefs_left = buf->num_grefs - num_pages_dir; + /* +* skip grant references at the beginning, they are for pages granted +* for the page directory itself +*/ + cur_gref = num_pages_dir; + for (i = 0; i < num_pages_dir; i++) { + page_dir = (struct xensnd_page_directory *)ptr; + if (grefs_left <= XENSND_NUM_GREFS_PER_PAGE) { + to_copy = grefs_left; + page_dir->gref_dir_next_page = GRANT_INVALID_REF; + } else { + to_copy = XENSND_NUM_GREFS_PER_PAGE; + page_dir->gref_dir_next_page = buf->grefs[i + 1]; + } + + memcpy(&page_dir->gref, &buf->grefs[cur_gref], + to_copy * sizeof(grant_ref_t)); + + ptr += XEN_PAGE_SIZE; + grefs_left -= to_copy; + cur_gref += to_copy; + } +} + +static int grant_references(struct xenbus_device *xb_dev, + struct xen_snd_front_s
Re: [Xen-devel] [RFC v2 8/9] HACK libxl_exec: Check QEMU status via QMP instead of xenstore
On Mon, Apr 16, 2018 at 06:32:26PM +0100, Anthony PERARD wrote: > When QEMU is restricted, the qemu on the receiving side cann't write > anything to xenstore once the migration is started. So it cann't tell > libxl that it is ready to continue running the guest. > > In order to find out if QEMU is ready, we can issue QMP commands and > check if it respond. > > But there is no QMP socket to connect to before qemu is started. But we > can uses different facility from qemu in order to setup some kind of > callback before starting QEMU. For that, we open a file descriptor and > give it to qemu. > > This patch creates a pipe, give the write-end to qemu, and wait for > something to be written to it. (We could check if it is actually the QMP > greeting message.) > > QEMU is asked to setup a QMP server on this pipe, but even if it is a > one-way only, qemu will write the QMP greeting message to the pipe. > This is done with: > -add-fd, to create a fdset which is use later. > -chardev 'file,path=/dev/fdset/1,append=true', this open a char device > on the write-end of the pipe, tell qemu that the FD is write-only, and > not to run truncate on it. > -mon, just start the QMP server on this new chardev. > > With that, qemu will start the QMP server on the write-only fd, which is > enough to have the QMP greeting message. At this point, the QMP socket > is ready, and I think qemu is in the main-loop and ready to start the > emulation and respond to QMP commands. > > This patch calls 'query-status', any response to that without error > means that QEMU is ready. If the status is "running", QEMU would already > have written the xenstore node if it could and is doing emulation. > (Any subsequent QMP command 'cont', libxl__qmp_resume(), is not > changing anything. If one adds '-S' to the QEMU command line, QEMU will > have the status "prelaunch" as a response to 'query-status', then QEMU > can be asked to start emulation with 'cont' via QMP.) > > This patch copies most of "xswait" and call it "qmpwait". This is > probably not the best way forward due to duplication. > > Signed-off-by: Anthony PERARD > --- This email should have: Changes in RFC v2: - Have QEMU throw a event instead of polling on connect() to the QMP socket -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] drm/xen-front: Remove CMA support
On 04/17/2018 12:04 PM, Daniel Vetter wrote: On Tue, Apr 17, 2018 at 10:40:12AM +0300, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Even if xen-front allocates its buffers from contiguous memory those are still not contiguous in PA space, e.g. the buffer is only contiguous in IPA space. The only use-case for this mode was if xen-front is used to allocate dumb buffers which later be used by some other driver requiring contiguous memory, but there is no currently such a use-case or it can be worked around with xen-front. Please also mention the nents confusion here, and the patch that fixes it. Or just outright take the commit message from my patch with all the details: ok, if you don't mind then I'll use your commit message entirely drm/xen: Dissable CMA support It turns out this was only needed to paper over a bug in the CMA helpers, which was addressed in commit 998fb1a0f478b83492220ff79583bf9ad538bdd8 Author: Liviu Dudau Date: Fri Nov 10 13:33:10 2017 + drm: gem_cma_helper.c: Allow importing of contiguous scatterlists with nents > 1 Without this the following pipeline didn't work: domU: 1. xen-front allocates a non-contig buffer 2. creates grants out of it dom0: 3. converts the grants into a dma-buf. Since they're non-contig, the scatter-list is huge. 4. imports it into rcar-du, which requires dma-contig memory for scanout. -> On this given platform there's an IOMMU, so in theory this should work. But in practice this failed, because of the huge number of sg entries, even though the IOMMU driver mapped it all into a dma-contig range. With a guest-contig buffer allocated in step 1, this problem doesn't exist. But there's technically no reason to require guest-contig memory for xen buffer sharing using grants. With the commit message improved: Acked-by: Daniel Vetter Thank you, I'll wait for a day and apply to drm-misc-next if this is ok Signed-off-by: Oleksandr Andrushchenko Suggested-by: Daniel Vetter --- Documentation/gpu/xen-front.rst | 12 drivers/gpu/drm/xen/Kconfig | 13 drivers/gpu/drm/xen/Makefile| 9 +-- drivers/gpu/drm/xen/xen_drm_front.c | 62 +++- drivers/gpu/drm/xen/xen_drm_front.h | 42 ++- drivers/gpu/drm/xen/xen_drm_front_gem.c | 12 +--- drivers/gpu/drm/xen/xen_drm_front_gem.h | 3 - drivers/gpu/drm/xen/xen_drm_front_gem_cma.c | 79 - drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 22 -- drivers/gpu/drm/xen/xen_drm_front_shbuf.h | 8 --- 10 files changed, 21 insertions(+), 241 deletions(-) delete mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst index 009d942386c5..d988da7d1983 100644 --- a/Documentation/gpu/xen-front.rst +++ b/Documentation/gpu/xen-front.rst @@ -18,18 +18,6 @@ Buffers allocated by the frontend driver .. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h :doc: Buffers allocated by the frontend driver -With GEM CMA helpers - - -.. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h - :doc: With GEM CMA helpers - -Without GEM CMA helpers -~~~ - -.. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h - :doc: Without GEM CMA helpers - Buffers allocated by the backend diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig index 4f4abc91f3b6..4cca160782ab 100644 --- a/drivers/gpu/drm/xen/Kconfig +++ b/drivers/gpu/drm/xen/Kconfig @@ -15,16 +15,3 @@ config DRM_XEN_FRONTEND help Choose this option if you want to enable a para-virtualized frontend DRM/KMS driver for Xen guest OSes. - -config DRM_XEN_FRONTEND_CMA - bool "Use DRM CMA to allocate dumb buffers" - depends on DRM_XEN_FRONTEND - select DRM_KMS_CMA_HELPER - select DRM_GEM_CMA_HELPER - help - Use DRM CMA helpers to allocate display buffers. - This is useful for the use-cases when guest driver needs to - share or export buffers to other drivers which only expect - contiguous buffers. - Note: in this mode driver cannot use buffers allocated - by the backend. diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile index 352730dc6c13..712afff5ffc3 100644 --- a/drivers/gpu/drm/xen/Makefile +++ b/drivers/gpu/drm/xen/Makefile @@ -5,12 +5,7 @@ drm_xen_front-objs := xen_drm_front.o \ xen_drm_front_conn.o \ xen_drm_front_evtchnl.o \ xen_drm_front_shbuf.o \ - xen_drm_front_cfg.o - -ifeq ($(CONFIG_DRM_XEN_FRONTEND_CMA),y) - drm_xen_front-objs += xen_drm_front_gem_cma.o -else - drm_xen_f
Re: [Xen-devel] [PATCH 1/3] x86/pv: Introduce and use x86emul_read_dr()
>>> On 16.04.18 at 18:44, wrote: > On 16/04/18 13:32, Jan Beulich wrote: > On 16.04.18 at 14:18, wrote: >>> On 13/04/18 12:39, Jan Beulich wrote: >>> On 13.04.18 at 13:17, wrote: > On 13/04/18 09:31, Jan Beulich wrote: > On 12.04.18 at 18:55, wrote: >>> do_get_debugreg() has several bugs: >>> >>> * The %cr4.de condition is inverted. %dr4/5 should be accessible only >>> when >>>%cr4.de is disabled. >>> * When %cr4.de is disabled, emulation should yield #UD rather than >>> complete >>>with zero. >>> * Using -EINVAL for errors is a broken ABI, as it overlaps with valid > values >>>near the top of the address space. >>> >>> Introduce a common x86emul_read_dr() handler (as we will eventually >>> want to >>> add HVM support) which separates its success/failure indication from >>> the > data >>> value, and have do_get_debugreg() call into the handler. >> The HVM part here is sort of questionable because of your use of >> curr->arch.pv_vcpu.ctrlreg[4]. > That is what the "needs further plumbing" refers to, as well as needing > hooks to get/modify %dr6/7 from the VMCB/VMCS. > > However, we are gaining an increasing amount of common x86 code which > needs to read control register values, and I've got a plan to refactor > across the board to v->arch.cr4 (and similar). There is no point having > identical information in different parts of sub-unions. I agree. >> This is appropriate for the NULL ctxt case, >> but it's already a layering violation for the use of the function in >> priv_op_ops, where the read_cr() hook should be used instead. > Hmm - doing this, while probably the better long temr course of action, > would require passing the ops structures down into the callbacks. That doesn't sound like a problem, though - the hypercall path would pass NULL there as well. >> This ... >> >>> +int x86emul_read_dr(unsigned int reg, unsigned long *val, >>> +struct x86_emulate_ctxt *ctxt) >>> +{ >>> +struct vcpu *curr = current; >>> + >>> +/* HVM support requires a bit more plumbing before it will work. */ >>> +ASSERT(is_pv_vcpu(curr)); >>> + >>> +switch ( reg ) >>> +{ >>> +case 0 ... 3: >>> +case 6: >>> +*val = curr->arch.debugreg[reg]; >>> +break; >>> + >>> +case 7: >>> +*val = (curr->arch.debugreg[7] | >>> +curr->arch.debugreg[5]); >>> +break; >>> + >>> +case 4 ... 5: >>> +if ( !(curr->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE) ) >>> +{ >>> +*val = curr->arch.debugreg[reg + 2]; >>> +break; >> Once at it, wouldn't you better also fix the missing ORing of [5] into >> the > DR7 (really >> DR5) value here? > [5] is zero when %cr4.de is clear (subject to a bugfix in the subsequent > patch), as IO breakpoints are only valid to use when %cr4.de is enabled. Oh, right you are. >>> So, are your comments suitably addressed? It is unclear whether you >>> want any changes to be made. >> ... is what I'd prefer to be taken care of without delaying to the time when >> we make this work for HVM as well. Unless you feel really strongly about it >> being better the way you have it, in which case you may feel free to add >> my ack. > > In all PV cases (hypercall and emulation), the current code functions > correctly, because DE is active in context. > > In principle, the emulation case would be better if it used the > read_cr() hook, but that is invasive to arrange (which is why I chose > not to at this point), and still needs special casing for the hypercall > case anyway. Well, okay then: Acked-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] drm/xen-front: Remove CMA support
On Tue, Apr 17, 2018 at 10:40:12AM +0300, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Even if xen-front allocates its buffers from contiguous memory > those are still not contiguous in PA space, e.g. the buffer is only > contiguous in IPA space. > The only use-case for this mode was if xen-front is used to allocate > dumb buffers which later be used by some other driver requiring > contiguous memory, but there is no currently such a use-case or > it can be worked around with xen-front. Please also mention the nents confusion here, and the patch that fixes it. Or just outright take the commit message from my patch with all the details: drm/xen: Dissable CMA support It turns out this was only needed to paper over a bug in the CMA helpers, which was addressed in commit 998fb1a0f478b83492220ff79583bf9ad538bdd8 Author: Liviu Dudau Date: Fri Nov 10 13:33:10 2017 + drm: gem_cma_helper.c: Allow importing of contiguous scatterlists with nents > 1 Without this the following pipeline didn't work: domU: 1. xen-front allocates a non-contig buffer 2. creates grants out of it dom0: 3. converts the grants into a dma-buf. Since they're non-contig, the scatter-list is huge. 4. imports it into rcar-du, which requires dma-contig memory for scanout. -> On this given platform there's an IOMMU, so in theory this should work. But in practice this failed, because of the huge number of sg entries, even though the IOMMU driver mapped it all into a dma-contig range. With a guest-contig buffer allocated in step 1, this problem doesn't exist. But there's technically no reason to require guest-contig memory for xen buffer sharing using grants. With the commit message improved: Acked-by: Daniel Vetter > > Signed-off-by: Oleksandr Andrushchenko > Suggested-by: Daniel Vetter > --- > Documentation/gpu/xen-front.rst | 12 > drivers/gpu/drm/xen/Kconfig | 13 > drivers/gpu/drm/xen/Makefile| 9 +-- > drivers/gpu/drm/xen/xen_drm_front.c | 62 +++- > drivers/gpu/drm/xen/xen_drm_front.h | 42 ++- > drivers/gpu/drm/xen/xen_drm_front_gem.c | 12 +--- > drivers/gpu/drm/xen/xen_drm_front_gem.h | 3 - > drivers/gpu/drm/xen/xen_drm_front_gem_cma.c | 79 - > drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 22 -- > drivers/gpu/drm/xen/xen_drm_front_shbuf.h | 8 --- > 10 files changed, 21 insertions(+), 241 deletions(-) > delete mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c > > diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst > index 009d942386c5..d988da7d1983 100644 > --- a/Documentation/gpu/xen-front.rst > +++ b/Documentation/gpu/xen-front.rst > @@ -18,18 +18,6 @@ Buffers allocated by the frontend driver > .. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h > :doc: Buffers allocated by the frontend driver > > -With GEM CMA helpers > - > - > -.. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h > - :doc: With GEM CMA helpers > - > -Without GEM CMA helpers > -~~~ > - > -.. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h > - :doc: Without GEM CMA helpers > - > Buffers allocated by the backend > > > diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig > index 4f4abc91f3b6..4cca160782ab 100644 > --- a/drivers/gpu/drm/xen/Kconfig > +++ b/drivers/gpu/drm/xen/Kconfig > @@ -15,16 +15,3 @@ config DRM_XEN_FRONTEND > help > Choose this option if you want to enable a para-virtualized > frontend DRM/KMS driver for Xen guest OSes. > - > -config DRM_XEN_FRONTEND_CMA > - bool "Use DRM CMA to allocate dumb buffers" > - depends on DRM_XEN_FRONTEND > - select DRM_KMS_CMA_HELPER > - select DRM_GEM_CMA_HELPER > - help > - Use DRM CMA helpers to allocate display buffers. > - This is useful for the use-cases when guest driver needs to > - share or export buffers to other drivers which only expect > - contiguous buffers. > - Note: in this mode driver cannot use buffers allocated > - by the backend. > diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile > index 352730dc6c13..712afff5ffc3 100644 > --- a/drivers/gpu/drm/xen/Makefile > +++ b/drivers/gpu/drm/xen/Makefile > @@ -5,12 +5,7 @@ drm_xen_front-objs := xen_drm_front.o \ > xen_drm_front_conn.o \ > xen_drm_front_evtchnl.o \ > xen_drm_front_shbuf.o \ > - xen_drm_front_cfg.o > - > -ifeq ($(CONFIG_DRM_XEN_FRONTEND_CMA),y) > - drm_xen_front-objs += xen_drm_front_gem_cma.o > -else > - drm_xen_front-objs += xen_drm_front_gem.o > -endif > + xen_drm_front_cfg.o \ > + xen_drm
[Xen-devel] [linux-linus test] 122335: regressions - FAIL
flight 122335 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/122335/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-install fail REGR. vs. 118324 test-armhf-armhf-xl-xsm 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-libvirt-xsm 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324 test-armhf-armhf-xl-arndale 10 debian-install fail REGR. vs. 118324 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 118324 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118324 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118324 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxe6d9bfdeb4395fa5397996b2c3111b5909f41a1b baseline version: linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5 Last test of basis 118324 2018-01-25 07:31:24 Z 82 days Failing since118362 2018-01-26 16:56:17 Z 80 days 70 attempts Testing same since 122335 2018-04-16 19:50:16 Z0 days1 attempts 3304 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386
Re: [Xen-devel] [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling
On 04/16/2018 04:12 PM, Juergen Gross wrote: On 16/04/18 08:24, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Handle Xen event channels: - create for all configured streams and publish corresponding ring references and event channels in Xen store, so backend can connect - implement event channels interrupt handlers - create and destroy event channels with respect to Xen bus state Signed-off-by: Oleksandr Andrushchenko --- sound/xen/Makefile| 3 +- sound/xen/xen_snd_front.c | 10 +- sound/xen/xen_snd_front.h | 7 + sound/xen/xen_snd_front_evtchnl.c | 474 ++ sound/xen/xen_snd_front_evtchnl.h | 92 5 files changed, 584 insertions(+), 2 deletions(-) create mode 100644 sound/xen/xen_snd_front_evtchnl.c create mode 100644 sound/xen/xen_snd_front_evtchnl.h diff --git a/sound/xen/Makefile b/sound/xen/Makefile index 06705bef61fa..03c669984000 100644 --- a/sound/xen/Makefile +++ b/sound/xen/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 OR MIT snd_xen_front-objs := xen_snd_front.o \ - xen_snd_front_cfg.o + xen_snd_front_cfg.o \ + xen_snd_front_evtchnl.o obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c index 65d2494a9d14..eb46bf4070f9 100644 --- a/sound/xen/xen_snd_front.c +++ b/sound/xen/xen_snd_front.c @@ -18,9 +18,11 @@ #include #include "xen_snd_front.h" +#include "xen_snd_front_evtchnl.h" Does it really make sense to have multiple driver-private headers? I think those can be merged. I would really like to keep it separate as it clearly shows which stuff belongs to which modules. At least for me it is easier to maintain it this way. static void xen_snd_drv_fini(struct xen_snd_front_info *front_info) { + xen_snd_front_evtchnl_free_all(front_info); } static int sndback_initwait(struct xen_snd_front_info *front_info) @@ -32,7 +34,12 @@ static int sndback_initwait(struct xen_snd_front_info *front_info) if (ret < 0) return ret; - return 0; + /* create event channels for all streams and publish */ + ret = xen_snd_front_evtchnl_create_all(front_info, num_streams); + if (ret < 0) + return ret; + + return xen_snd_front_evtchnl_publish_all(front_info); } static int sndback_connect(struct xen_snd_front_info *front_info) @@ -122,6 +129,7 @@ static int xen_drv_probe(struct xenbus_device *xb_dev, return -ENOMEM; front_info->xb_dev = xb_dev; + spin_lock_init(&front_info->io_lock); dev_set_drvdata(&xb_dev->dev, front_info); return xenbus_switch_state(xb_dev, XenbusStateInitialising); diff --git a/sound/xen/xen_snd_front.h b/sound/xen/xen_snd_front.h index b52226cb30bc..9c2ffbb4e4b8 100644 --- a/sound/xen/xen_snd_front.h +++ b/sound/xen/xen_snd_front.h @@ -13,9 +13,16 @@ #include "xen_snd_front_cfg.h" +struct xen_snd_front_evtchnl_pair; + struct xen_snd_front_info { struct xenbus_device *xb_dev; + /* serializer for backend IO: request/response */ + spinlock_t io_lock; + int num_evt_pairs; + struct xen_snd_front_evtchnl_pair *evt_pairs; + struct xen_front_cfg_card cfg; }; diff --git a/sound/xen/xen_snd_front_evtchnl.c b/sound/xen/xen_snd_front_evtchnl.c new file mode 100644 index ..9ece39f938f8 --- /dev/null +++ b/sound/xen/xen_snd_front_evtchnl.c @@ -0,0 +1,474 @@ +// SPDX-License-Identifier: GPL-2.0 OR MIT + +/* + * Xen para-virtual sound device + * + * Copyright (C) 2016-2018 EPAM Systems Inc. + * + * Author: Oleksandr Andrushchenko + */ + +#include +#include +#include +#include + +#include "xen_snd_front.h" +#include "xen_snd_front_cfg.h" +#include "xen_snd_front_evtchnl.h" + +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) +{ + struct xen_snd_front_evtchnl *channel = dev_id; + struct xen_snd_front_info *front_info = channel->front_info; + struct xensnd_resp *resp; + RING_IDX i, rp; + unsigned long flags; + + if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED)) + return IRQ_HANDLED; + + spin_lock_irqsave(&front_info->io_lock, flags); + +again: + rp = channel->u.req.ring.sring->rsp_prod; + /* ensure we see queued responses up to rp */ + rmb(); + + for (i = channel->u.req.ring.rsp_cons; i != rp; i++) { + resp = RING_GET_RESPONSE(&channel->u.req.ring, i); + if (resp->id != channel->evt_id) + continue; + switch (resp->operation) { + case XENSND_OP_OPEN: + /* fall through */ + case XENSND_OP_CLOSE: + /* fall through */ + case XENSND_OP_READ: + /* fall thro
Re: [Xen-devel] [PATCH v2 2/5] ALSA: xen-front: Read sound driver configuration from Xen store
On 04/16/2018 03:55 PM, Juergen Gross wrote: On 16/04/18 08:24, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Read configuration values from Xen store according to xen/interface/io/sndif.h protocol: - introduce configuration structures for different components, e.g. sound card, device, stream - read PCM HW parameters, e.g rate, format etc. - detect stream type (capture/playback) - read device and card parameters Signed-off-by: Oleksandr Andrushchenko --- sound/xen/Makefile| 3 +- sound/xen/xen_snd_front.c | 7 + sound/xen/xen_snd_front.h | 4 + sound/xen/xen_snd_front_cfg.c | 517 ++ sound/xen/xen_snd_front_cfg.h | 46 5 files changed, 576 insertions(+), 1 deletion(-) create mode 100644 sound/xen/xen_snd_front_cfg.c create mode 100644 sound/xen/xen_snd_front_cfg.h diff --git a/sound/xen/Makefile b/sound/xen/Makefile index 4507ef3c27fd..06705bef61fa 100644 --- a/sound/xen/Makefile +++ b/sound/xen/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 OR MIT -snd_xen_front-objs := xen_snd_front.o +snd_xen_front-objs := xen_snd_front.o \ + xen_snd_front_cfg.o obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c index f406a8f52c51..65d2494a9d14 100644 --- a/sound/xen/xen_snd_front.c +++ b/sound/xen/xen_snd_front.c @@ -25,6 +25,13 @@ static void xen_snd_drv_fini(struct xen_snd_front_info *front_info) static int sndback_initwait(struct xen_snd_front_info *front_info) { + int num_streams; + int ret; + + ret = xen_snd_front_cfg_card(front_info, &num_streams); + if (ret < 0) + return ret; + return 0; } diff --git a/sound/xen/xen_snd_front.h b/sound/xen/xen_snd_front.h index 4ae204b23d32..b52226cb30bc 100644 --- a/sound/xen/xen_snd_front.h +++ b/sound/xen/xen_snd_front.h @@ -11,8 +11,12 @@ #ifndef __XEN_SND_FRONT_H #define __XEN_SND_FRONT_H +#include "xen_snd_front_cfg.h" + struct xen_snd_front_info { struct xenbus_device *xb_dev; + + struct xen_front_cfg_card cfg; }; #endif /* __XEN_SND_FRONT_H */ diff --git a/sound/xen/xen_snd_front_cfg.c b/sound/xen/xen_snd_front_cfg.c new file mode 100644 index ..d461985afffa --- /dev/null +++ b/sound/xen/xen_snd_front_cfg.c @@ -0,0 +1,517 @@ +// SPDX-License-Identifier: GPL-2.0 OR MIT + +/* + * Xen para-virtual sound device + * + * Copyright (C) 2016-2018 EPAM Systems Inc. + * + * Author: Oleksandr Andrushchenko + */ + +#include + +#include + +#include "xen_snd_front.h" +#include "xen_snd_front_cfg.h" + +/* maximum number of supported streams */ Comment style (multiple times below, too): Start with a capital letter and end sentences with a full stop. will fix +#define VSND_MAX_STREAM8 + +struct cfg_hw_sample_rate { + const char *name; + unsigned int mask; + unsigned int value; +}; + +static const struct cfg_hw_sample_rate CFG_HW_SUPPORTED_RATES[] = { + { .name = "5512", .mask = SNDRV_PCM_RATE_5512, .value = 5512 }, + { .name = "8000", .mask = SNDRV_PCM_RATE_8000, .value = 8000 }, + { .name = "11025", .mask = SNDRV_PCM_RATE_11025, .value = 11025 }, + { .name = "16000", .mask = SNDRV_PCM_RATE_16000, .value = 16000 }, + { .name = "22050", .mask = SNDRV_PCM_RATE_22050, .value = 22050 }, + { .name = "32000", .mask = SNDRV_PCM_RATE_32000, .value = 32000 }, + { .name = "44100", .mask = SNDRV_PCM_RATE_44100, .value = 44100 }, + { .name = "48000", .mask = SNDRV_PCM_RATE_48000, .value = 48000 }, + { .name = "64000", .mask = SNDRV_PCM_RATE_64000, .value = 64000 }, + { .name = "96000", .mask = SNDRV_PCM_RATE_96000, .value = 96000 }, + { .name = "176400", .mask = SNDRV_PCM_RATE_176400, .value = 176400 }, + { .name = "192000", .mask = SNDRV_PCM_RATE_192000, .value = 192000 }, +}; + +struct cfg_hw_sample_format { + const char *name; + u64 mask; +}; + +static const struct cfg_hw_sample_format CFG_HW_SUPPORTED_FORMATS[] = { + { + .name = XENSND_PCM_FORMAT_U8_STR, + .mask = SNDRV_PCM_FMTBIT_U8 + }, + { + .name = XENSND_PCM_FORMAT_S8_STR, + .mask = SNDRV_PCM_FMTBIT_S8 + }, + { + .name = XENSND_PCM_FORMAT_U16_LE_STR, + .mask = SNDRV_PCM_FMTBIT_U16_LE + }, + { + .name = XENSND_PCM_FORMAT_U16_BE_STR, + .mask = SNDRV_PCM_FMTBIT_U16_BE + }, + { + .name = XENSND_PCM_FORMAT_S16_LE_STR, + .mask = SNDRV_PCM_FMTBIT_S16_LE + }, + { + .name = XENSND_PCM_FORMAT_S16_BE_STR, + .mask = SNDRV_PCM_FMTBIT_S16_BE + }, + { + .name = XENSND_PCM_FORMAT_U24_LE_STR, + .mask = SNDRV_PC
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On 04/16/2018 11:21 PM, George Dunlap wrote: > On Mon, Apr 16, 2018 at 7:46 PM, Razvan Cojocaru > wrote: >> On 04/16/2018 08:47 PM, George Dunlap wrote: >>> On 04/13/2018 03:44 PM, Razvan Cojocaru wrote: On 04/11/2018 11:04 AM, Razvan Cojocaru wrote: > Debugging continues. Finally, the attached patch seems to get the display unstuck in my scenario, although for one guest I get: (XEN) d2v0 Unexpected vmexit: reason 49 (XEN) domain_crash called from vmx.c:4120 (XEN) Domain 2 (vcpu#0) crashed on cpu#1: (XEN) [ Xen-4.11-unstable x86_64 debug=y Not tainted ] (XEN) CPU:1 (XEN) RIP:0010:[] (XEN) RFLAGS: 00010246 CONTEXT: hvm guest (d2v0) (XEN) rax: f8800300 rbx: f900c0083db0 rcx: aa55aa55 (XEN) rdx: fa80041bdc41 rsi: f900c00c69a0 rdi: 0001 (XEN) rbp: rsp: f88002ee9ef0 r8: fa80041bdc40 (XEN) r9: f80001810e80 r10: fa800342aa70 r11: f88002ee9e80 (XEN) r12: 0005 r13: 0001 r14: f900c00c08b0 (XEN) r15: 0001 cr0: 80050031 cr4: 000406f8 (XEN) cr3: ef771000 cr2: f900c00c8000 (XEN) fsb: fffde000 gsb: f80001810d00 gss: 07fdc000 (XEN) ds: 002b es: 002b fs: 0053 gs: 002b ss: 0018 cs: 0010 i.e. EXIT_REASON_EPT_MISCONFIG - so not of the woods yet. I am hoping somebody more familiar with the code can point to a more elegant solution if one exists. >>> >>> I think I have an idea what's going on, but it's complicated. :-) >>> >>> Basically, the logdirty functionality isn't simple, and needs careful >>> thought on how to integrate it. I'll write some more tomorrow, and see >>> if I can come up with a solution. >> >> I think I know why this happens for the one guest - the other guests >> start at a certain resolution display-wise and stay that way until shutdown. >> >> This particular guest starts with a larger screen, then goes to roughly >> 2/3rds of it, then tries to go back to the initial larger one - at which >> point the above happens. I assume this corresponds to some pages being >> removed and/or added. I'll test this theory more tomorrow - if it's >> correct I should be able to reproduce the crash (with the patch) by >> simply resetting the screen resolution (increasing it). > > The trick is that p2m_change_type doesn't actually iterate over the > entire p2m range, individually changing entries as it goes. Instead > it misconfigures the entries at the top-level, which causes the kinds > of faults shown above. As it gets faults for each entry, it checks > the current type, the logdirty ranges, and the global logdirty bit to > determine what the new types should be. > > Your patch makes it so that all the altp2ms now get the > misconfiguration when the logdirty range is changed; but clearly > handling the misconfiguration isn't integrated properly with the > altp2m system yet. Doing it right may take some thought. FWIW, the attached patch has solved the misconfig-related domain crash for me (though I'm very likely missing some subtleties). It all seems to work as expected when enabling altp2m and switching early to a new view. However, now I have domUs with a frozen display when I disconnect the introspection application (that is, after I switch back to the default view and disable altp2m on the domain). Thanks, Razvan diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c index 14b5939..4530689 100644 --- a/xen/arch/x86/mm/p2m-ept.c +++ b/xen/arch/x86/mm/p2m-ept.c @@ -17,6 +17,7 @@ #include #include +#include #include #include #include @@ -652,17 +653,38 @@ static int resolve_misconfig(struct p2m_domain *p2m, unsigned long gfn) bool_t ept_handle_misconfig(uint64_t gpa) { struct vcpu *curr = current; -struct p2m_domain *p2m = p2m_get_hostp2m(curr->domain); +struct domain *d = curr->domain; +struct p2m_domain *p2m = p2m_get_hostp2m(d); bool_t spurious; -int rc; - -p2m_lock(p2m); +int rc = 0; +unsigned int i; spurious = curr->arch.hvm_vmx.ept_spurious_misconfig; -rc = resolve_misconfig(p2m, PFN_DOWN(gpa)); -curr->arch.hvm_vmx.ept_spurious_misconfig = 0; -p2m_unlock(p2m); +if ( altp2m_active(d) ) +{ + for ( i = 0; i < MAX_ALTP2M; i++ ) +if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) ) +{ +p2m = d->arch.altp2m_p2m[i]; + +p2m_lock(p2m); + +rc = resolve_misconfig(p2m, PFN_DOWN(gpa)); +curr->arch.hvm_vmx.ept_spurious_misconfig = 0; + +p2m_unlock(p2m); +} +} +else +{ +p2m_lock(p2m); + +rc = resolve_misconfig(p2m, PFN_DOWN(gpa)); +curr->arch.hvm_vmx.ept_spurious_misconfig = 0; + +p2m_unlock(p2m); +}
Re: [Xen-devel] [PATCH v2 1/5] ALSA: xen-front: Introduce Xen para-virtualized sound frontend driver
On 04/16/2018 03:25 PM, Juergen Gross wrote: On 16/04/18 08:24, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Introduce skeleton of the para-virtualized Xen sound frontend driver. Initial handling for Xen bus states: implement Xen bus state machine for the frontend driver according to the state diagram and recovery flow from sound para-virtualized protocol: xen/interface/io/sndif.h. Signed-off-by: Oleksandr Andrushchenko Only one minor nit (see below). With that addressed (or fixed when committing): will fix Reviewed-by: Juergen Gross Thank you Juergen --- sound/Kconfig | 2 + sound/Makefile| 2 +- sound/xen/Kconfig | 10 +++ sound/xen/Makefile| 5 ++ sound/xen/xen_snd_front.c | 196 ++ sound/xen/xen_snd_front.h | 18 + 6 files changed, 232 insertions(+), 1 deletion(-) create mode 100644 sound/xen/Kconfig create mode 100644 sound/xen/Makefile create mode 100644 sound/xen/xen_snd_front.c create mode 100644 sound/xen/xen_snd_front.h diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c new file mode 100644 index ..f406a8f52c51 --- /dev/null +++ b/sound/xen/xen_snd_front.c @@ -0,0 +1,196 @@ +static void sndback_changed(struct xenbus_device *xb_dev, + enum xenbus_state backend_state) +{ + struct xen_snd_front_info *front_info = dev_get_drvdata(&xb_dev->dev); + int ret; + + dev_dbg(&xb_dev->dev, "Backend state is %s, front is %s\n", + xenbus_strstate(backend_state), + xenbus_strstate(xb_dev->state)); + + switch (backend_state) { + case XenbusStateReconfiguring: + /* fall through */ + case XenbusStateReconfigured: + /* fall through */ + case XenbusStateInitialised: + /* fall through */ + break; + + case XenbusStateInitialising: + /* recovering after backend unexpected closure */ + sndback_disconnect(front_info); + break; + + case XenbusStateInitWait: + /* recovering after backend unexpected closure */ + sndback_disconnect(front_info); + + ret = sndback_initwait(front_info); + if (ret < 0) + xenbus_dev_fatal(xb_dev, ret, "initializing frontend"); + else + xenbus_switch_state(xb_dev, XenbusStateInitialised); + break; + + case XenbusStateConnected: + if (xb_dev->state != XenbusStateInitialised) + break; + + ret = sndback_connect(front_info); + if (ret < 0) + xenbus_dev_fatal(xb_dev, ret, "initializing frontend"); + else + xenbus_switch_state(xb_dev, XenbusStateConnected); + break; + + case XenbusStateClosing: + /* +* in this state backend starts freeing resources, +* so let it go into closed state first, so we can also +* remove ours +*/ Please start the sentence with a capital letter and end it with a full stop. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On 04/17/2018 10:59 AM, Daniel Vetter wrote: On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: Yeah, I definitely agree on the idea of expanding the use case to the general domain where dmabuf sharing is used. However, what you are targetting with proposed changes is identical to the core design of hyper_dmabuf. On top of this basic functionalities, hyper_dmabuf has driver level inter-domain communication, that is needed for dma-buf remote tracking (no fence forwarding though), event triggering and event handling, extra meta data exchange and hyper_dmabuf_id that represents grefs (grefs are shared implicitly on driver level) This really isn't a positive design aspect of hyperdmabuf imo. The core code in xen-zcopy (ignoring the ioctl side, which will be cleaned up) is very simple & clean. If there's a clear need later on we can extend that. But for now xen-zcopy seems to cover the basic use-case needs, so gets the job done. After we decided to remove DRM PRIME code from the zcopy driver I think we can extend the existing Xen drivers instead of introducing a new one: gntdev [1], [2] - to handle export/import of the dma-bufs to/from grefs balloon [3] - to allow allocating CMA buffers Also it is designed with frontend (common core framework) + backend (hyper visor specific comm and memory sharing) structure for portability. We just can't limit this feature to Xen because we want to use the same uapis not only for Xen but also other applicable hypervisor, like ACORN. See the discussion around udmabuf and the needs for kvm. I think trying to make an ioctl/uapi that works for multiple hypervisors is misguided - it likely won't work. On top of that the 2nd hypervisor you're aiming to support is ACRN. That's not even upstream yet, nor have I seen any patches proposing to land linux support for ACRN. Since it's not upstream, it doesn't really matter for upstream consideration. I'm doubting that ACRN will use the same grant references as xen, so the same uapi won't work on ACRN as on Xen anyway. So I am wondering we can start with this hyper_dmabuf then modify it for your use-case if needed and polish and fix any glitches if we want to to use this for all general dma-buf usecases. Imo xen-zcopy is a much more reasonable starting point for upstream, which can then be extended (if really proven to be necessary). Also, I still have one unresolved question regarding the export/import flow in both of hyper_dmabuf and xen-zcopy. @danvet: Would this flow (guest1->import existing dmabuf->share underlying pages->guest2->map shared pages->create/export dmabuf) be acceptable now? I think if you just look at the pages, and make sure you handle the sg_page == NULL case it's ok-ish. It's not great, but mostly it should work. The real trouble with hyperdmabuf was the forwarding of all these calls, instead of just passing around a list of grant references. -Daniel Regards, DW On Mon, Apr 16, 2018 at 05:33:46PM +0300, Oleksandr Andrushchenko wrote: Hello, all! After discussing xen-zcopy and hyper-dmabuf [1] approaches Even more context for the discussion [4], so Xen community can catch up it seems that xen-zcopy can be made not depend on DRM core any more and be dma-buf centric (which it in fact is). The DRM code was mostly there for dma-buf's FD import/export with DRM PRIME UAPI and with DRM use-cases in mind, but it comes out that if the proposed 2 IOCTLs (DRM_XEN_ZCOPY_DUMB_FROM_REFS and DRM_XEN_ZCOPY_DUMB_TO_REFS) are extended to also provide a file descriptor of the corresponding dma-buf, then PRIME stuff in the driver is not needed anymore. That being said, xen-zcopy can safely be detached from DRM and moved from drivers/gpu/drm/xen into drivers/xen/dma-buf-backend(?). This driver then becomes a universal way to turn any shared buffer between Dom0/DomD and DomU(s) into a dma-buf, e.g. one can create a dma-buf from any grant references or represent a dma-buf as grant-references for export. This way the driver can be used not only for DRM use-cases, but also for other use-cases which may require zero copying between domains. For example, the use-cases we are about to work in the nearest future will use V4L, e.g. we plan to support cameras, codecs etc. and all these will benefit from zero copying much. Potentially, even block/net devices may benefit, but this needs some evaluation. I would love to hear comments for authors of the hyper-dmabuf and Xen community, as well as DRI-Devel and other interested parties. Thank you, Oleksandr On 03/29/2018 04:19 PM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello! When using Xen PV DRM frontend driver then on backend side one will need to do copying of display buffers' contents (filled by the frontend's user-space) into buffers allocated at the backend side. Taking into account the size of display buffers and frames per seconds it may result in unneeded huge data bus occupation and performance loss. This he
Re: [Xen-devel] [RFC PATCH 2/3] xen: Refactor migration
Am Tue, 17 Apr 2018 09:20:33 +0200 schrieb Dario Faggioli : > And I guess we can add a 'Tested-by: Olaf Hering', as he actually did > that, what do you say Olaf? Yes, that is true. I have tested these three patches with staging. Tested-by: Olaf Hering Olaf pgp_9JRNwl7yn.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > Yeah, I definitely agree on the idea of expanding the use case to the > general domain where dmabuf sharing is used. However, what you are > targetting with proposed changes is identical to the core design of > hyper_dmabuf. > > On top of this basic functionalities, hyper_dmabuf has driver level > inter-domain communication, that is needed for dma-buf remote tracking > (no fence forwarding though), event triggering and event handling, extra > meta data exchange and hyper_dmabuf_id that represents grefs > (grefs are shared implicitly on driver level) This really isn't a positive design aspect of hyperdmabuf imo. The core code in xen-zcopy (ignoring the ioctl side, which will be cleaned up) is very simple & clean. If there's a clear need later on we can extend that. But for now xen-zcopy seems to cover the basic use-case needs, so gets the job done. > Also it is designed with frontend (common core framework) + backend > (hyper visor specific comm and memory sharing) structure for portability. > We just can't limit this feature to Xen because we want to use the same > uapis not only for Xen but also other applicable hypervisor, like ACORN. See the discussion around udmabuf and the needs for kvm. I think trying to make an ioctl/uapi that works for multiple hypervisors is misguided - it likely won't work. On top of that the 2nd hypervisor you're aiming to support is ACRN. That's not even upstream yet, nor have I seen any patches proposing to land linux support for ACRN. Since it's not upstream, it doesn't really matter for upstream consideration. I'm doubting that ACRN will use the same grant references as xen, so the same uapi won't work on ACRN as on Xen anyway. > So I am wondering we can start with this hyper_dmabuf then modify it for > your use-case if needed and polish and fix any glitches if we want to > to use this for all general dma-buf usecases. Imo xen-zcopy is a much more reasonable starting point for upstream, which can then be extended (if really proven to be necessary). > Also, I still have one unresolved question regarding the export/import flow > in both of hyper_dmabuf and xen-zcopy. > > @danvet: Would this flow (guest1->import existing dmabuf->share underlying > pages->guest2->map shared pages->create/export dmabuf) be acceptable now? I think if you just look at the pages, and make sure you handle the sg_page == NULL case it's ok-ish. It's not great, but mostly it should work. The real trouble with hyperdmabuf was the forwarding of all these calls, instead of just passing around a list of grant references. -Daniel > > Regards, > DW > > On Mon, Apr 16, 2018 at 05:33:46PM +0300, Oleksandr Andrushchenko wrote: > > Hello, all! > > > > After discussing xen-zcopy and hyper-dmabuf [1] approaches > > > > it seems that xen-zcopy can be made not depend on DRM core any more > > > > and be dma-buf centric (which it in fact is). > > > > The DRM code was mostly there for dma-buf's FD import/export > > > > with DRM PRIME UAPI and with DRM use-cases in mind, but it comes out that if > > > > the proposed 2 IOCTLs (DRM_XEN_ZCOPY_DUMB_FROM_REFS and > > DRM_XEN_ZCOPY_DUMB_TO_REFS) > > > > are extended to also provide a file descriptor of the corresponding dma-buf, > > then > > > > PRIME stuff in the driver is not needed anymore. > > > > That being said, xen-zcopy can safely be detached from DRM and moved from > > > > drivers/gpu/drm/xen into drivers/xen/dma-buf-backend(?). > > > > This driver then becomes a universal way to turn any shared buffer between > > Dom0/DomD > > > > and DomU(s) into a dma-buf, e.g. one can create a dma-buf from any grant > > references > > > > or represent a dma-buf as grant-references for export. > > > > This way the driver can be used not only for DRM use-cases, but also for > > other > > > > use-cases which may require zero copying between domains. > > > > For example, the use-cases we are about to work in the nearest future will > > use > > > > V4L, e.g. we plan to support cameras, codecs etc. and all these will benefit > > > > from zero copying much. Potentially, even block/net devices may benefit, > > > > but this needs some evaluation. > > > > > > I would love to hear comments for authors of the hyper-dmabuf > > > > and Xen community, as well as DRI-Devel and other interested parties. > > > > > > Thank you, > > > > Oleksandr > > > > > > On 03/29/2018 04:19 PM, Oleksandr Andrushchenko wrote: > > >From: Oleksandr Andrushchenko > > > > > >Hello! > > > > > >When using Xen PV DRM frontend driver then on backend side one will need > > >to do copying of display buffers' contents (filled by the > > >frontend's user-space) into buffers allocated at the backend side. > > >Taking into account the size of display buffers and frames per seconds > > >it may result in unneeded huge data bus occupation and performance loss. > > > > > >This helper driver allows implementing zero-copying us
Re: [Xen-devel] [RFC PATCH 0/3] vcpu migration improvements
On Wed, 2018-04-11 at 13:25 +0100, George Dunlap wrote: > Some compile-tested-only sketches of what I'm talking about. Let me > know what you think. > So, patches 1 and 2 of this series solves what I think was one of the nastiest races I've ever had to chase in the scheduler. :-) Having figured out what the exact root cause of the race itself is, this is the _proper_ fix, as it puts setting of VPF_migrate and SCHED_op(sleep) inside the same critical section, which is what closes the race window. I'd like to argue for this series to be considered a bugfix, and included in 4.11 (and backported as far as possible, which has been already proved to be feasible, e.g., until 4.7). The alternative would be to come up with something else which kind of works around the race, within sched_credit.c... But I don't really see a reason for doing that. Code-wise, it may probably be a bit more self- contained, but it's not like this series is that spread/intrusive in the first place. And the net effect would be basically the same. I.e., in both cases, we need to change what happens when vcpu_migrate() is called, and I don't see much difference between doing that by changing vcpu_migrate() itself, or by changing how Credit react to vcpu_migrate() being called (especially considering that Credit is the default scheduler). And therefore, between a proper fix and a workaround, which have similar impact and effects, I think we should go for the former. :-) Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/7] introduce time managment in xtf
On Mon, Apr 16, 2018 at 12:48:49PM +0200, Paul Semel wrote: > On 04/13/2018 02:05 PM, Roger Pau Monné wrote: > > > +static inline uint64_t scale_delta(uint64_t delta, uint32_t mul_frac, > > > int shift) > > > +{ > > > +uint64_t product; > > > +#ifdef __i386__ > > > +uint32_t tmp1, tmp2; > > > +#endif > > > + > > > +if ( shift < 0 ) > > > +delta >>= -shift; > > > +else > > > +delta <<= shift; > > > + > > > +#ifdef __i386__ > > > +__asm__ ( > > > +"mul %5 ; " > > > +"mov %4,%%eax ; " > > > +"mov %%edx,%4 ; " > > > +"mul %5 ; " > > > +"add %4,%%eax ; " > > > +"xor %5,%5; " > > > +"adc %5,%%edx ; " > > > +: "=A" (product), "=r" (tmp1), "=r" (tmp2) > > > +: "a" ((uint32_t)delta), "1" ((uint32_t)(delta >> 32)), "2" > > > (mul_frac) ); > > > > This line is too long. > > > > > +#else > > > +__asm__ ( > > > +"mul %%rdx ; shrd $32,%%rdx,%%rax" > > > +: "=a" (product) : "0" (delta), "d" ((uint64_t)mul_frac) ); > > > > Not sure whether you need to add a ': "d"' clobber here, since the d > > register is used but it's not in the list of output operands. > > > > > +#endif > > > + > > > +return product; > > > +} > > > + > > Actually, I'm not sure that I have to make that much changes to this > function, as @Andrew wanted to use another version of it as far as I recall. IMO if there are known issues with this function they need to be sorted out before committing. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 7/7] add sleep, msleep and NOW() macros to time manager
On Mon, Apr 16, 2018 at 12:45:17PM +0200, Paul Semel wrote: > On 04/13/2018 03:55 PM, Roger Pau Monné wrote: > > > those are helpful macro to use the time manager correctly > > > > > > Signed-off-by: Paul Semel > > > --- > > > > > > Notes: > > > v4: > > > - new patch version > > > > > > common/time.c | 10 ++ > > > include/xtf/time.h | 12 > > > 2 files changed, 22 insertions(+) > > > > > > diff --git a/common/time.c b/common/time.c > > > index 7515eb0..e2779b9 100644 > > > --- a/common/time.c > > > +++ b/common/time.c > > > @@ -163,6 +163,16 @@ static inline void mspin_sleep(uint64_t t) > > > nspin_sleep(nsec); > > > } > > > +void sleep(uint64_t t) > > > +{ > > > +spin_sleep(t); > > > +} > > > + > > > +void msleep(uint64_t t) > > > +{ > > > +mspin_sleep(t); > > > > Why can you just call mspin_sleep msleep directly? > > > > The same applies to spin_sleep. > > > > Also I was expecting to see some kind of test appear at the end of the > > series. You are basically adding a bunch of dead code, since there's > > no user of any of the newly introduced functions. > > Actually, I won't be able to add a real XSA test using this feature. Anyway, > I do think that having the sleep functions will be really useful in the > future. > Anyway, I was thinking about adding a test that is calling the gettimeofday > function or something similar. > > What do you think about it ? Yes, see my last reply to 3/7. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 3/7] add gettimeofday function to time managment
On Mon, Apr 16, 2018 at 12:16:18PM +0200, Paul Semel wrote: > Hi ! > > Thanks a lot for reviewing ! > > On 04/13/2018 03:39 PM, Roger Pau Monné wrote: > > On Tue, Apr 10, 2018 at 09:16:57PM +0200, Paul Semel wrote: > > > this function acts as the POSIX gettimeofday function > > > > > > Signed-off-by: Paul Semel > > > --- > > > > > > Notes: > > > v4: > > > - new patch version > > > > > > common/time.c | 30 ++ > > > include/xtf/time.h | 8 > > > 2 files changed, 38 insertions(+) > > > > > > diff --git a/common/time.c b/common/time.c > > > index c1b7cd1..8489f3b 100644 > > > --- a/common/time.c > > > +++ b/common/time.c > > > @@ -1,6 +1,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > Sorting. > > > > > #include > > > #include > > > @@ -109,6 +110,35 @@ uint64_t current_time(void) > > > return sec + boot_time; > > > } > > > +/* The POSIX gettimeofday syscall normally takes a second argument, > > > which is > > > + * the timezone (struct timezone). However, it sould be NULL because > > > linux > > > + * doesn't use it anymore. So we need for us to add it in this function > > > + */ > > > +int gettimeofday(struct timeval *tp, void *restrict tzp) > > > +{ > > > +uint64_t boot_time, sec; > > > +uint32_t mod, nsec; > > > + > > > +if ( tzp != NULL ) > > > +return -EOPNOTSUPP; > > > + > > > +if ( tp == NULL ) > > > +return -EINVAL; > > > + > > > +get_time_info(&boot_time, &sec, &nsec); > > > > Why are you using get_time_info here? Shouldn't you use the > > current_time function introduced in the previous patch? > > > > Or else I don't see the need to introduce current_time in the previous > > patch. > > > > Actually, I can't use *only* the current_time function here, because I won't > be able to get the nanoseconds if so. > > Anyway, in the last patch, I am using current_time function for the NOW() > macro, which I think is really helpful. > > Do you think I should drop all of those ? Without having any users of those functions it's hard to tell which ones we should keep and which ones should be removed. IMO, I would keep gettimeofday in order to get the current time. Then I would also keep the m/u/sleep functions and add a small selftest in test/selftest/main.c that makes use of those functions, for example something as simple as: s = gettimeofday msleep(1) if ( s + 1ms < gettimeofday ) xtf_failure("Fail: error in time keeping functions\n") Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] drm/xen-front: Remove CMA support
From: Oleksandr Andrushchenko Even if xen-front allocates its buffers from contiguous memory those are still not contiguous in PA space, e.g. the buffer is only contiguous in IPA space. The only use-case for this mode was if xen-front is used to allocate dumb buffers which later be used by some other driver requiring contiguous memory, but there is no currently such a use-case or it can be worked around with xen-front. Signed-off-by: Oleksandr Andrushchenko Suggested-by: Daniel Vetter --- Documentation/gpu/xen-front.rst | 12 drivers/gpu/drm/xen/Kconfig | 13 drivers/gpu/drm/xen/Makefile| 9 +-- drivers/gpu/drm/xen/xen_drm_front.c | 62 +++- drivers/gpu/drm/xen/xen_drm_front.h | 42 ++- drivers/gpu/drm/xen/xen_drm_front_gem.c | 12 +--- drivers/gpu/drm/xen/xen_drm_front_gem.h | 3 - drivers/gpu/drm/xen/xen_drm_front_gem_cma.c | 79 - drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 22 -- drivers/gpu/drm/xen/xen_drm_front_shbuf.h | 8 --- 10 files changed, 21 insertions(+), 241 deletions(-) delete mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst index 009d942386c5..d988da7d1983 100644 --- a/Documentation/gpu/xen-front.rst +++ b/Documentation/gpu/xen-front.rst @@ -18,18 +18,6 @@ Buffers allocated by the frontend driver .. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h :doc: Buffers allocated by the frontend driver -With GEM CMA helpers - - -.. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h - :doc: With GEM CMA helpers - -Without GEM CMA helpers -~~~ - -.. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h - :doc: Without GEM CMA helpers - Buffers allocated by the backend diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig index 4f4abc91f3b6..4cca160782ab 100644 --- a/drivers/gpu/drm/xen/Kconfig +++ b/drivers/gpu/drm/xen/Kconfig @@ -15,16 +15,3 @@ config DRM_XEN_FRONTEND help Choose this option if you want to enable a para-virtualized frontend DRM/KMS driver for Xen guest OSes. - -config DRM_XEN_FRONTEND_CMA - bool "Use DRM CMA to allocate dumb buffers" - depends on DRM_XEN_FRONTEND - select DRM_KMS_CMA_HELPER - select DRM_GEM_CMA_HELPER - help - Use DRM CMA helpers to allocate display buffers. - This is useful for the use-cases when guest driver needs to - share or export buffers to other drivers which only expect - contiguous buffers. - Note: in this mode driver cannot use buffers allocated - by the backend. diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile index 352730dc6c13..712afff5ffc3 100644 --- a/drivers/gpu/drm/xen/Makefile +++ b/drivers/gpu/drm/xen/Makefile @@ -5,12 +5,7 @@ drm_xen_front-objs := xen_drm_front.o \ xen_drm_front_conn.o \ xen_drm_front_evtchnl.o \ xen_drm_front_shbuf.o \ - xen_drm_front_cfg.o - -ifeq ($(CONFIG_DRM_XEN_FRONTEND_CMA),y) - drm_xen_front-objs += xen_drm_front_gem_cma.o -else - drm_xen_front-objs += xen_drm_front_gem.o -endif + xen_drm_front_cfg.o \ + xen_drm_front_gem.o obj-$(CONFIG_DRM_XEN_FRONTEND) += drm_xen_front.o diff --git a/drivers/gpu/drm/xen/xen_drm_front.c b/drivers/gpu/drm/xen/xen_drm_front.c index 4a08b77f1c9e..1b0ea9ac330e 100644 --- a/drivers/gpu/drm/xen/xen_drm_front.c +++ b/drivers/gpu/drm/xen/xen_drm_front.c @@ -12,7 +12,6 @@ #include #include #include -#include #include @@ -167,10 +166,9 @@ int xen_drm_front_mode_set(struct xen_drm_front_drm_pipeline *pipeline, return ret; } -static int be_dbuf_create_int(struct xen_drm_front_info *front_info, +int xen_drm_front_dbuf_create(struct xen_drm_front_info *front_info, u64 dbuf_cookie, u32 width, u32 height, - u32 bpp, u64 size, struct page **pages, - struct sg_table *sgt) + u32 bpp, u64 size, struct page **pages) { struct xen_drm_front_evtchnl *evtchnl; struct xen_drm_front_shbuf *shbuf; @@ -187,7 +185,6 @@ static int be_dbuf_create_int(struct xen_drm_front_info *front_info, buf_cfg.xb_dev = front_info->xb_dev; buf_cfg.pages = pages; buf_cfg.size = size; - buf_cfg.sgt = sgt; buf_cfg.be_alloc = front_info->cfg.be_alloc; shbuf = xen_drm_front_shbuf_alloc(&buf_cfg); @@ -237,22 +234,6 @@ static int be_dbuf_create_int(struct xen_drm_front_info *front_info, return ret; } -int xen_drm_front_dbuf_create_from_sgt(struct xen_drm_front_info *front_info, - u64 dbuf_cookie, u32 width, u
Re: [Xen-devel] [RFC PATCH 3/3] sched/credit: Avoid doing cpu_pick calculation twice when deciding to move
On Wed, 2018-04-11 at 13:25 +0100, George Dunlap wrote: > In vcpu_acct(), we call _csched_cpu_pick() in order to decide whether > to consider migrating; but then we throw that result away and do it > again in context_saved() if we decide we do need to move. > > Instead, just initiate the migration and let the > vcpu_migrate_finish() > in context_saved() determine if it should make any changes. > I am ambivalent about this. In fact, I never liked the duplicated pick_cpu effort myself. Still, what happens right now is: - vcpu_acct() calls _csched_cpu_pick(); - if the returned cpu is equal to where the vcpu is currently running, nothing happens; - if it is different, we initiate a migration, and go through pick again. So, we have the duplicated call to pick. Initiating a migration means making the running vcpu not runnable and hence de-scheduling it (in favour of either idle or some other runnable vcpu). Then, in vcpu_migrate_finish(), we make it runnable again, put it back in a runqueue, and raise the SCHEDULE_SOFTIRQ on the pCPU, if appropriate. It's likely that the pCPU in question is different from the one where the vcpu was running when vccpu_acct() was invoked. After this patch, vcpu_acct() initiate a migration unconditionally. This means we avoid the overhead of the double call to pick, but we always go through de-scheduling current. This potentially means letting a runnable vcpu preempt current just for figuring out immediately after that current should not really migrate, and have it preempting the other vcpu again. So, AFAICT, we're saving some overhead, but introducing some other... Anyway, this patch is not really necessary for fixing the race, so I'd leave it aside for now. Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: xenbus_dev_frontend: Really return response string
On 15/03/18 04:08, Simon Gaiser wrote: > xenbus_command_reply() did not actually copy the response string and > leaked stack content instead. > > Fixes: 9a6161fe73bd ("xen: return xenstore command failures via response > instead of rc") > Signed-off-by: Simon Gaiser Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel