[Xen-devel] Xen 4.11 RC1

[Juergen Gross]

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

[Boris Ostrovsky]

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

[Laura Abbott]

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

[osstest service owner]

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
 

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Dongwon Kim]

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 

[Xen-devel] [ovmf baseline-only test] 74631: all pass

[Platform Team regression test user]

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

[Ian Jackson]

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

[George Dunlap]

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

[Razvan Cojocaru]

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

[Tamas K Lengyel]

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

[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

[Xen-devel] [PATCH] mktarball: For qemu upstream, use their scripts/archive-source.sh

[Ian Jackson]

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

[Xen-devel] [xen-unstable test] 122343: tolerable FAIL

[osstest service owner]

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 

[Xen-devel] [distros-debian-snapshot test] 74630: tolerable FAIL

[Platform Team regression test user]

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

[Lars Kurth]

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 

Re: [Xen-devel] [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario

[Mirela Simonovic]

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

[Razvan Cojocaru]

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

[Boris Ostrovsky]

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

[osstest service owner]

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

Re: [Xen-devel] [PATCH RESEND] xen/sndif: Sync up with the canonical definition in Xen

[Boris Ostrovsky]

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

[Boris Ostrovsky]

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

[George Dunlap]

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 

Re: [Xen-devel] [PATCH 7/7] docs/parse-support-md: Correctly handle footnotes for non-leaf sections

[Juergen Gross]

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

[Andrew Cooper]

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

[Juergen Gross]

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

[Igor Druzhinin]

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(>memory_listener, >dev.bus_master_as);
+memory_listener_register(>memory_listener, _space_memory);
 memory_listener_register(>io_listener, _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

[Ian Jackson]

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

[Ian Jackson]

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

[Ian Jackson]

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

[Ian Jackson]

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 5/7] SUPPORT.md: Document the new text ordering rule

[Ian Jackson]

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 2/7] docs/parse-support-md: internals: Rename HasText to HasCaveat

[Ian Jackson]

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 3/7] SUPPORT.md, support matrix: Treat commentary before status as description

[Ian Jackson]

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

[Ian Jackson]

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 

Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks

[Anthony PERARD]

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

[Platform Team regression test user]

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

[Igor Druzhinin]

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

[Juergen Gross]

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

[Juergen Gross]

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

[Razvan Cojocaru]

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 

Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks

[Igor Druzhinin]

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

[Anthony PERARD]

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

[Julien Grall]

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

[Andrew Cooper]

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

[Juergen Gross]

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 

Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks

[Igor Druzhinin]

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

[Platform Team regression test user]

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

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

[George Dunlap]

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

[Jan Beulich]

>>> 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

[osstest service owner]

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

[Ian Jackson]

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

Re: [Xen-devel] [PATCH 6/8] x86/HVM: Hook up miscellaneous AVIC functions

[Jan Beulich]

>>> 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

[Jan Beulich]

>>> 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, >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

[Roger Pau Monne]

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, ) )
 {
 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, _grant);
 errno = saved_errno;
@@ -149,10 +148,10 @@ void 

Re: [Xen-devel] [PATCH 3/8] x86/SVM: Add AVIC vmexit handlers

[Jan Beulich]

>>> 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

[Mirela Simonovic]

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

[Jan Beulich]

>>> 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

[Oleksandr Andrushchenko]

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

[Dario Faggioli]

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

[Oleksandr Andrushchenko]

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(>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(>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(>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(>u.req.req_io_lock);
+
+    spin_lock_irqsave(_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(_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(>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(>u.req.req_io_lock);
+
+    

Re: [Xen-devel] [PATCH v2 5/5] ALSA: xen-front: Implement ALSA virtual sound driver

[Juergen Gross]

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(>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(>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(>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(>u.req.req_io_lock);
 +
 +    spin_lock_irqsave(_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(_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;
 +

Re: [Xen-devel] [PATCH] x86/msr: further correct the emulation behaviour of MSR_PRED_CMD

[Andrew Cooper]

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

[Oleksandr Andrushchenko]

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(>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(>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(>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(>u.req.req_io_lock);
+
+    spin_lock_irqsave(_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(_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(>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(>u.req.req_io_lock);
+
+    spin_lock_irqsave(_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

[Mirela Simonovic]

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 

[Xen-devel] [PATCH] x86/msr: further correct the emulation behaviour of MSR_PRED_CMD

[Jan Beulich]

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

[Oleksandr Andrushchenko]

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(>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(>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(>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(>u.req.req_io_lock);
+
+   spin_lock_irqsave(_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(_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(>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 

Re: [Xen-devel] [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

[Oleksandr Andrushchenko]

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(_info->io_lock);
   dev_set_drvdata(_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(_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(>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 

Re: [Xen-devel] [PATCH v2 4/5] ALSA: xen-front: Implement handling of shared buffers

[Juergen Gross]

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

[Juergen Gross]

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(_info->io_lock);
>>>   dev_set_drvdata(_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(_info->io_lock, flags);
>>> +
>>> +again:
>>> +    rp = channel->u.req.ring.sring->rsp_prod;
>>> +    /* ensure we see queued 

Re: [Xen-devel] [PATCH v2 2/5] ALSA: xen-front: Read sound driver configuration from Xen store

[Juergen Gross]

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 = _instance->streams_pb[(*cur_pb)++];
>>> +    } else if (!strncasecmp(str, XENSND_STREAM_TYPE_CAPTURE,
>>> +  sizeof(XENSND_STREAM_TYPE_CAPTURE))) {
>>> +    stream = _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, >pcm_hw);
>>> +
>>> +    cfg->pcm_instances =
>>> +    devm_kcalloc(_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, >pcm_instances[i],
>>> + >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

[Julien Grall]

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

[osstest service owner]

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 

Re: [Xen-devel] [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly

[Mirela Simonovic]

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

[Razvan Cojocaru]

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 

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

[Razvan Cojocaru]

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

[Dario Faggioli]

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 = >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 = >rb_left;
> +else
> +node = >rb_right;
> +
> +(*pos)++;
> +}
> +rb_link_node(>runq_elem, parent, node);
> +rb_insert_color(>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 = _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, >runq )
> -{
> -struct csched2_vcpu * svc = list_entry(iter, struct
> csched2_vcpu, runq_elem);
> +for (iter = rb_first(>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
-- 
<> (Raistlin Majere)

Re: [Xen-devel] 答复: [PATCH] x86/hpet: add a lock when cpu clear cpumask in hpet_broadcast_exit();

[Jan Beulich]

>>> 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(>lock);
>>  cpumask_clear_cpu(cpu, ch->cpumask);
>> +spin_unlock_irq(>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

[Oleksandr Andrushchenko]

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(_dir->gref, >grefs[cur_gref],
+  to_copy * sizeof(grant_ref_t));
+
+   ptr += XEN_PAGE_SIZE;
+   grefs_left -= to_copy;
+   cur_gref += to_copy;
+   }
+}
+
+static int 

Re: [Xen-devel] [RFC v2 8/9] HACK libxl_exec: Check QEMU status via QMP instead of xenstore

[Anthony PERARD]

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

[Oleksandr Andrushchenko]

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 \
- 

Re: [Xen-devel] [PATCH 1/3] x86/pv: Introduce and use x86emul_read_dr()

[Jan Beulich]

>>> 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

[Daniel Vetter]

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
> 

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

[osstest service owner]

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

[Oleksandr Andrushchenko]

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(_info->io_lock);
dev_set_drvdata(_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(_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(>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 

Re: [Xen-devel] [PATCH v2 2/5] ALSA: xen-front: Read sound driver configuration from Xen store

[Oleksandr Andrushchenko]

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, _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
+   

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

[Razvan Cojocaru]

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;
+
+

Re: [Xen-devel] [PATCH v2 1/5] ALSA: xen-front: Introduce Xen para-virtualized sound frontend driver

[Oleksandr Andrushchenko]

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(_dev->dev);
+   int ret;
+
+   dev_dbg(_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

[Oleksandr Andrushchenko]

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 

Re: [Xen-devel] [RFC PATCH 2/3] xen: Refactor migration

[Olaf Hering]

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

[Daniel Vetter]

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 

Re: [Xen-devel] [RFC PATCH 0/3] vcpu migration improvements

[Dario Faggioli]

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

[Roger Pau Monné]

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

[Roger Pau Monné]

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

[Roger Pau Monné]

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(_time, , );
> > 
> > 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

[Oleksandr Andrushchenko]

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(_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 

Re: [Xen-devel] [RFC PATCH 3/3] sched/credit: Avoid doing cpu_pick calculation twice when deciding to move

[Dario Faggioli]

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

[Juergen Gross]

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

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

[Razvan Cojocaru]

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.

Thanks for investigating! Sure enough, my suspicion was correct - all it
takes to get that domain crash is to change the VM screen resolution.


Thanks,
Razvan

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

Re: [Xen-devel] [RFC PATCH 2/3] xen: Refactor migration

[Dario Faggioli]

On Wed, 2018-04-11 at 13:25 +0100, George Dunlap wrote:
> The current sequence to initiate vcpu migration is inefficent and
> error-prone:
> 
> - The initiator sets VPF_migraging with the lock held, then drops the
>   lock and calls vcpu_sleep_nosync(), which immediately grabs the
> lock
>   again
> 
> - A number of places unnecessarily check for v->pause_flags in
> between
>   those two
> 
> - Every call to vcpu_migrate() must be prefaced with
>   vcpu_sleep_nosync() or introduce a race condition; this code
>   duplication is error-prone
> 
It's not only error prone, it's the cause of actual bugs! :-P

That's why I would also change the subject of the series into something
like "fix races happening during vcpu migration"

> - In the event that v->is_running is true at the beginning of
>   vcpu_migrate(), it's almost certain that vcpu_migrate() will end up
>   being called in context_switch() as well; we might as well simply
>   let it run there and save the duplicated effort (which will be
>   non-negligible).
> 
> Instead, introduce vcpu_migrate_start() to initiate the process.
> vcpu_migrate_start() is called with the scheduling lock held.  It not
> only sets VPF_migrating, but also calls vcpu_sleep_nosync_locked()
> (which will automatically do nothing if there's nothing to do).
> 
> Rename vcpu_migrate() to vcpu_migrate_finish().  Check for v-
> >is_running and
> pause_flags & VPF_migrating at the top and return if appropriate.
> 
> Then the way to initiate migration is consistently:
> 
> * Grab lock
> * vcpu_migrate_start()
> * Release lock
> * vcpu_migrate_finish()
> 
> Signed-off-by: George Dunlap 

> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -593,13 +593,33 @@ static void vcpu_move_nosched(struct vcpu *v,
> unsigned int new_cpu)
>  sched_move_irqs(v);
>  }
>  
> -static void vcpu_migrate(struct vcpu *v)
> +/*
> + * Initiating migration
> + * 
> + * In order to migrate, we need the vcpu in question to have stopped
> + * running and be taken off the runqueues; we also need to hold the
> lock 
> + */
>
Perhaps "and SCHED_OP(sleep) to have been called on it", instead of
"and be taken off the runqueues", if we don't want to even mention
runqueues in schedule.c.

And there are a couple of instances of whitespace damaging.

Nevertheless,

Reviewed-by: Dario Faggioli 

And I guess we can add a 'Tested-by: Olaf Hering', as he actually did
that, what do you say Olaf?

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] x86/xen: Remove use of VLAs

[Juergen Gross]

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.


Juergen

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