[Xen-devel] rootfs about xen on FVP-Base-ReVC-2xAEMv8A

[敏]

hello
now ，I am trying to run domain0（xen on FVP-Base-ReVC-2xAEMv8A）but there is a 
issue about rootfs ，
kernel panic  VFS：ubable to mount root fs on unknown-block
the filesystem image is xenial-server-cloudimg-arm64-uefi1.img 
I can not resolve this issue ，can you give me some opinion？
thank you very much！___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 00/14] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

On 2019/2/22 0:38, Wei Liu wrote:
> I think the version should have been v5?

Aha. This is the second revision of the patch series. So why should it
have been v5?

-- 
Regards,
Pu Wen

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

[Xen-devel] [linux-4.9 test] 133330: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win10-i386 broken
 test-amd64-i386-freebsd10-amd64 broken
 test-amd64-i386-xl-shadowbroken
 test-amd64-i386-qemuu-rhel6hvm-amd broken
 test-amd64-i386-xl-qemuu-ws16-amd64 broken
 test-amd64-amd64-i386-pvgrub broken
 test-amd64-i386-libvirt  broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow broken
 test-amd64-amd64-xl-qemuu-ovmf-amd64 broken
 test-amd64-amd64-xl-pvhv2-amd broken
 test-amd64-amd64-xl-qemuu-win10-i386 broken
 test-amd64-amd64-xl-qemut-win10-i386 broken
 build-armhf-pvopsbroken
 test-amd64-amd64-xl-qemut-win7-amd64 broken
 test-amd64-i386-qemuu-rhel6hvm-intel broken
 test-amd64-i386-xl-raw   broken
 test-amd64-i386-xl-qemuu-ovmf-amd64 broken
 test-amd64-i386-qemut-rhel6hvm-amd broken
 test-amd64-amd64-rumprun-amd64 broken
 test-amd64-amd64-pairbroken
 test-amd64-amd64-xl-qemut-ws16-amd64 broken
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict   broken
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrictbroken
 test-amd64-i386-xl-qemut-debianhvm-amd64broken
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadowbroken
 build-armhf  broken
 test-amd64-amd64-xl-qemuu-ws16-amd64 broken
 test-amd64-i386-xl-qemut-ws16-amd64 broken
 test-amd64-amd64-libvirt-pair broken
 test-amd64-i386-libvirt-pair broken
 test-amd64-i386-xl-qemuu-win10-i386 broken
 test-amd64-amd64-libvirt-vhd broken
 test-amd64-i386-xl   broken
 test-amd64-i386-pair broken
 test-amd64-i386-xl-qemuu-win7-amd64 broken
 test-amd64-amd64-amd64-pvgrub broken
 test-amd64-i386-xl-pvshimbroken
 test-amd64-i386-rumprun-i386 broken
 test-amd64-amd64-qemuu-nested-intel broken
 build-amd64-xsm  broken
 test-amd64-amd64-qemuu-nested-amd broken
 test-amd64-i386-xl-qemut-win7-amd64 broken
 test-amd64-i386-qemut-rhel6hvm-intel broken
 test-amd64-amd64-xl-qemuu-win7-amd64 broken
 test-amd64-i386-freebsd10-i386 broken
 test-amd64-amd64-xl-qcow2broken
 test-amd64-amd64-xl-rtds broken
 test-amd64-amd64-pygrub  broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64broken
 test-amd64-amd64-xl-qemut-debianhvm-amd64   broken
 test-amd64-amd64-xl-shadow   broken
 test-amd64-i386-rumprun-i386  2 hosts-allocate broken REGR. vs. 132748
 test-amd64-i386-xl-qemuu-ws16-amd64  2 hosts-allocate  broken REGR. vs. 132748
 test-amd64-amd64-qemuu-nested-amd  2 hosts-allocatebroken REGR. vs. 132748
 test-amd64-amd64-libvirt-vhd  2 hosts-allocate broken REGR. vs. 132748
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 2 hosts-allocate broken REGR. 
vs. 132748
 test-amd64-amd64-xl-qemuu-win10-i386  2 hosts-allocate broken REGR. vs. 132748
 test-amd64-i386-xl-qemuu-debianhvm-amd64 2 hosts-allocate broken REGR. vs. 
132748
 test-amd64-i386-xl-shadow 2 hosts-allocate broken REGR. vs. 132748
 test-amd64-i386-libvirt-pair  2 hosts-allocate broken REGR. vs. 132748
 test-amd64-amd64-xl-qemuu-ws16-amd64  2 hosts-allocate broken REGR. vs. 132748
 test-amd64-i386-libvirt   2 hosts-allocate broken REGR. vs. 132748
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 2 hosts-allocate broken 
REGR. vs. 132748
 test-amd64-i386-xl-qemuu-win7-amd64  2 hosts-allocate  broken REGR. vs. 132748
 test-amd64-i386-xl-qemuu-win10-i386  2 hosts-allocate  broken REGR. vs. 132748
 test-amd64-amd64-xl-pvhv2-amd  2 hosts-allocatebroken REGR. vs. 132748
 test-amd64-i386-qemut-rhel6hvm-amd  2 hosts-allocate   broken REGR. vs. 132748
 test-amd64-amd64-xl-qemuu-win7-amd64  2 hosts-allocate broken REGR. vs. 132748
 test-amd64-amd64-examine  2 hosts-allocate broken REGR. vs. 132748
 test-amd64-i386-xl-qemuu-ovmf-amd64  2 hosts-allocate  broken REGR. vs. 132748
 test-amd64-i386-xl-qemut-debianhvm-amd64 2 hosts-allocate broken REGR. vs. 
132748
 

[Xen-devel] [ovmf test] 133344: regressions - FAIL

[osstest service owner]

flight 133344 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133344/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
133291
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 133291

version targeted for testing:
 ovmf b49758c11280a0dfba981632ed6ed06ed80a30d8
baseline version:
 ovmf c417c1b33d06ef6ae96adb373201a5a3c3b38772

Last test of basis   133291  2019-02-18 01:41:15 Z4 days
Failing since133305  2019-02-19 00:41:21 Z3 days3 attempts
Testing same since   133344  2019-02-21 03:46:52 Z0 days1 attempts


People who touched revisions under test:
  Albecki Mateusz 
  Albecki, Mateusz 
  Bob Feng 
  Chasel Chiu 
  Chasel, Chiu 
  Dandan Bi 
  Edgar Handal 
  Fan, ZhijuX 
  Feng, Bob C 
  Gonzalez Del Cueto, Rodrigo 
  Jeff Brasen 
  Jiaxin Wu 
  Jordan Justen 
  Julien Grall 
  Laszlo Ersek 
  Liming Gao 
  Max Knutsen 
  Ray Ni 
  Rodrigo Gonzalez del Cueto 
  Ruiyu Ni 
  Sami Mujawar 
  Shenglei Zhang 
  Star Zeng 
  Wu Jiaxin 
  Zhiju.Fan 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 910 lines long.)

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

Re: [Xen-devel] About Porting Virtio to the XEN

[chengyan]

Dear Wei:

 Now,  I only make a demo in x86 platform and it is just a try.

 Not sure that whether it is successful using Virtio tech 
in the XEN project.


 I found it is a huge and difficult try.

    If there are problems related to arm in the future, I will 
ask to Julien.


    Thank you for your recommendation again.

Thanks.

在 2019/2/21 下午7:58, Wei Liu 写道:

On Thu, Feb 21, 2019 at 06:13:32PM +0800, chengyan wrote:

Dear Expert:

    I want to porting the Virtio to the XEN via reference to
the below links.

    https://wiki.xen.org/wiki/Virtio_On_Xen.

That page is very dated.

        If I have ported the Virtio as the following guides
,whether it may reach my requirement,which is in the HVM guest?

What are your requirements?

Seeing that your company seems to work on automotive projects, I know
Julien from Arm has done some work for Xen on Arm, if you can be more
specific, maybe Julien can give you an answer?

Wei.



  My expected result is that visit I/O via the virtio. Would
you please give me answers ?

Thanks.



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

.



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

[Xen-devel] [linux-4.14 test] 133351: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-armhf  broken
 build-arm64  broken
 build-i386-xsm   broken
 build-amd64  broken
 build-i386   broken
 build-amd64-xsm  broken
 build-i386-pvops broken
 build-armhf-pvopsbroken
 build-i386-pvops  2 hosts-allocate broken REGR. vs. 133261
 build-i386-xsm2 hosts-allocate broken REGR. vs. 133261
 build-i3862 hosts-allocate broken REGR. vs. 133261
 build-amd64   2 hosts-allocate broken REGR. vs. 133261
 build-armhf-pvops 2 hosts-allocate broken REGR. vs. 133261
 build-armhf   2 hosts-allocate broken REGR. vs. 133261
 build-amd64-xsm   2 hosts-allocate broken REGR. vs. 133261
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  running
 test-amd64-i386-freebsd10-i386  1 build-check(1)   running
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm  1 build-check(1) running
 test-armhf-armhf-xl-vhd   1 build-check(1)   running
 test-amd64-i386-xl-pvshim 1 build-check(1)   running
 test-arm64-arm64-xl-credit1   1 build-check(1)   running
 test-armhf-armhf-libvirt-raw  1 build-check(1)   running
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)   running
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) running
 test-amd64-i386-xl1 build-check(1)   running
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)   running
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict  1 build-check(1) running
 test-amd64-i386-examine   1 build-check(1)   running
 build-armhf-libvirt   1 build-check(1)   running
 build-i386-libvirt1 build-check(1)   running
 test-amd64-i386-libvirt   1 build-check(1)   running
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   running
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)   running
 build-amd64-rumprun   1 build-check(1)   running
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   running
 build-arm64-libvirt   1 build-check(1)   running
 test-arm64-arm64-xl   1 build-check(1)   running
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)   running
 test-arm64-arm64-xl-xsm   1 build-check(1)   running
 build-amd64-libvirt   1 build-check(1)   running
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) running
 test-armhf-armhf-xl-arndale   1 build-check(1)   running
 test-amd64-i386-rumprun-i386  1 build-check(1)   running
 test-amd64-i386-libvirt-xsm   1 build-check(1)   running
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)   running
 test-armhf-armhf-xl-credit2   1 build-check(1)   running
 test-armhf-armhf-examine  1 build-check(1)   running
 test-amd64-i386-xl-shadow 1 build-check(1)   running
 test-amd64-i386-libvirt-pair  1 build-check(1)   running
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   running
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  1 build-check(1)running
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) running
 test-arm64-arm64-xl-credit2   1 build-check(1)   running
 test-armhf-armhf-xl-rtds  1 build-check(1)   running
 test-amd64-i386-xl-raw1 build-check(1)   running
 test-amd64-i386-pair  1 build-check(1)   running
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   running
 test-armhf-armhf-libvirt  1 build-check(1)   running
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) running
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)   running
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)   running
 test-amd64-i386-xl-xsm1 build-check(1)   running
 test-arm64-arm64-examine  1 build-check(1)   running
 build-i386-rumprun1 build-check(1)   running
 test-armhf-armhf-xl-credit1   1 build-check(1)   running
 

Re: [Xen-devel] [PATCH v3 02/25] chardev: Assert IOCanReadHandler can not be negative

[Philippe Mathieu-Daudé]

On 2/20/19 12:13 PM, Philippe Mathieu-Daudé wrote:
> On 2/20/19 11:03 AM, Marc-André Lureau wrote:
>> Hi
>>
>> On Wed, Feb 20, 2019 at 2:03 AM Philippe Mathieu-Daudé
>>  wrote:
>>>
>>> The backend should not return a negative length to read.
>>> We will later change the prototype of IOCanReadHandler to return an
>>> unsigned length. Meanwhile make sure the return length is positive.
>>>
>>> Suggested-by: Paolo Bonzini 
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>
>> In such patch, you should do extensive review of existing callbacks,
>> or find a convincing argument that this can't break.
> 
> Argh I missed that.
> 
>> The problem is there are a lot of can_read callbacks, and it's not
>> trivial. The *first* of git-grep is rng_egd_chr_can_read()
>>
>>  57 QSIMPLEQ_FOREACH(req, >parent.requests, next) {
>>  58 size += req->size - req->offset;
>>  59 }
>>  60
>>  61 return size;
>>
>> Clearly not obvious if it returns >= 0.
>>
>> Another approach is to look at the caller and the return value
>> handling. If none handle negative values (or would have wrong
>> behaviour with negative values), the assert() is perhaps justified, as
>> it could prevent from doing more harm.
> 
> I'll go and audit all of them.

Actually I already did the work, but it is in the part #2 after this
series, as suggested by Paolo:

https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02294.html

I'll simply cherry-pick the commit from series #2 before this patch.

Thanks,

Phil.

>>> ---
>>>  chardev/char.c | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/chardev/char.c b/chardev/char.c
>>> index f6d61fa5f8..71ecd32b25 100644
>>> --- a/chardev/char.c
>>> +++ b/chardev/char.c
>>> @@ -159,12 +159,15 @@ int qemu_chr_write(Chardev *s, const uint8_t *buf, 
>>> int len, bool write_all)
>>>  int qemu_chr_be_can_write(Chardev *s)
>>>  {
>>>  CharBackend *be = s->be;
>>> +int receivable_bytes;
>>>
>>>  if (!be || !be->chr_can_read) {
>>>  return 0;
>>>  }
>>>
>>> -return be->chr_can_read(be->opaque);
>>> +receivable_bytes = be->chr_can_read(be->opaque);
>>> +assert(receivable_bytes >= 0);
>>> +return receivable_bytes;
>>>  }
>>>
>>>  void qemu_chr_be_write_impl(Chardev *s, uint8_t *buf, int len)
>>> --
>>> 2.20.1
>>>

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

Re: [Xen-devel] [RESEND PATCH 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'

[Ira Weiny]

On Thu, Feb 21, 2019 at 08:48:41AM +0530, Souptick Joarder wrote:
> Hi Ira,
> 
> On Wed, Feb 20, 2019 at 11:01 AM  wrote:
> >
> > From: Ira Weiny 
> >
> > To facilitate additional options to get_user_pages_fast() change the
> > singular write parameter to be gup_flags.
> >
> > This patch does not change any functionality.  New functionality will
> > follow in subsequent patches.
> >
> > Some of the get_user_pages_fast() call sites were unchanged because they
> > already passed FOLL_WRITE or 0 for the write parameter.
> >
> > Signed-off-by: Ira Weiny 
> > ---

[snip]

> > diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
> > b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> > index bd2dcfbf00cd..8fcb0a921e46 100644
> > --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> > +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> > @@ -582,7 +582,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, 
> > struct kvm_vcpu *vcpu,
> > /* If writing != 0, then the HPTE must allow writing, if we get 
> > here */
> > write_ok = writing;
> > hva = gfn_to_hva_memslot(memslot, gfn);
> > -   npages = get_user_pages_fast(hva, 1, writing, pages);
> > +   npages = get_user_pages_fast(hva, 1, writing ? FOLL_WRITE : 0, 
> > pages);
> 
> Just requesting for opinion,
> * writing ? FOLL_WRITE : 0 * is used in many places. How about placing it in a
> macro/ inline ?

I don't really think this would gain much.  And I don't think it would be more
clear.  In fact I can't even think of a macro name which would make sense.  I'm
inclined to leave this as written.

Ira

> 
> > if (npages < 1) {
> > /* Check if it's an I/O mapping */
> > down_read(>mm->mmap_sem);
> > @@ -1175,7 +1175,7 @@ void *kvmppc_pin_guest_page(struct kvm *kvm, unsigned 
> > long gpa,
> > if (!memslot || (memslot->flags & KVM_MEMSLOT_INVALID))
> > goto err;
> > hva = gfn_to_hva_memslot(memslot, gfn);
> > -   npages = get_user_pages_fast(hva, 1, 1, pages);
> > +   npages = get_user_pages_fast(hva, 1, FOLL_WRITE, pages);
> > if (npages < 1)
> > goto err;
> > page = pages[0];
> > diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> > index 24296f4cadc6..e0af53fd78c5 100644
> > --- a/arch/powerpc/kvm/e500_mmu.c
> > +++ b/arch/powerpc/kvm/e500_mmu.c
> > @@ -783,7 +783,7 @@ int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
> > if (!pages)
> > return -ENOMEM;
> >
> > -   ret = get_user_pages_fast(cfg->array, num_pages, 1, pages);
> > +   ret = get_user_pages_fast(cfg->array, num_pages, FOLL_WRITE, pages);
> > if (ret < 0)
> > goto free_pages;
> >
> > diff --git a/arch/powerpc/mm/mmu_context_iommu.c 
> > b/arch/powerpc/mm/mmu_context_iommu.c
> > index a712a650a8b6..acb0990c8364 100644
> > --- a/arch/powerpc/mm/mmu_context_iommu.c
> > +++ b/arch/powerpc/mm/mmu_context_iommu.c
> > @@ -190,7 +190,7 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, 
> > unsigned long ua,
> > for (i = 0; i < entries; ++i) {
> > cur_ua = ua + (i << PAGE_SHIFT);
> > if (1 != get_user_pages_fast(cur_ua,
> > -   1/* pages */, 1/* iswrite */, 
> > )) {
> > +   1/* pages */, FOLL_WRITE, )) {
> > ret = -EFAULT;
> > for (j = 0; j < i; ++j)
> > put_page(pfn_to_page(mem->hpas[j] >>
> > @@ -209,7 +209,7 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, 
> > unsigned long ua,
> > if (mm_iommu_move_page_from_cma(page))
> > goto populate;
> > if (1 != get_user_pages_fast(cur_ua,
> > -   1/* pages */, 1/* iswrite 
> > */,
> > +   1/* pages */, FOLL_WRITE,
> > )) {
> > ret = -EFAULT;
> > for (j = 0; j < i; ++j)
> > diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> > index fcb55b02990e..69d9366b966c 100644
> > --- a/arch/s390/kvm/interrupt.c
> > +++ b/arch/s390/kvm/interrupt.c
> > @@ -2278,7 +2278,7 @@ static int kvm_s390_adapter_map(struct kvm *kvm, 
> > unsigned int id, __u64 addr)
> > ret = -EFAULT;
> > goto out;
> > }
> > -   ret = get_user_pages_fast(map->addr, 1, 1, >page);
> > +   ret = get_user_pages_fast(map->addr, 1, FOLL_WRITE, >page);
> > if (ret < 0)
> > goto out;
> > BUG_ON(ret != 1);
> > diff --git a/arch/s390/mm/gup.c b/arch/s390/mm/gup.c
> > index 2809d11c7a28..0a6faf3d9960 100644
> > --- a/arch/s390/mm/gup.c
> > +++ b/arch/s390/mm/gup.c
> > @@ -265,7 +265,7 @@ int __get_user_pages_fast(unsigned long start, int 
> > nr_pages, int 

[Xen-devel] [PATCH v2] iommu: leave IOMMU enabled by default during kexec crash transition

[Igor Druzhinin]

It's unsafe to disable IOMMU on a live system which is the case
if we're crashing since remapping hardware doesn't usually know what
to do with ongoing bus transactions and frequently raises NMI/MCE/SMI,
etc. (depends on the firmware configuration) to signal these abnormalities.
This, in turn, doesn't play well with kexec transition process as there is
no handling available at the moment for this kind of events resulting
in failures to enter the kernel.

Modern Linux kernels taught to copy all the necessary DMAR/IR tables
following kexec from the previous kernel (Xen in our case) - so it's
currently normal to keep IOMMU enabled. It might require minor changes to
kdump command line that enables IOMMU drivers (e.g. intel_iommu=on /
intremap=on) but recent kernels don't require any additional changes for
the transition to be transparent.

A fallback option is still left for compatibility with ancient crash
kernels which didn't like to have IOMMU active under their feet on boot.

Signed-off-by: Igor Druzhinin 
---
Changes in v2:
* Fixed and clarified documentation
* Renamed option to crash-disable
* Other minor suggestions taken
---
 docs/misc/xen-command-line.pandoc | 8 +++-
 xen/arch/x86/crash.c  | 7 +--
 xen/drivers/passthrough/iommu.c   | 8 
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc 
b/docs/misc/xen-command-line.pandoc
index a03c0b4..ab853bd 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1172,7 +1172,7 @@ detection of systems known to misbehave upon accesses to 
that port.
 
 ### iommu
 = List of [ , verbose, debug, force, required,
-sharept, intremap, intpost,
+sharept, intremap, intpost, crash-disable,
 snoop, qinval, igfx, workaround_bios_bug,
 amd-iommu-perdev-intremap,
 dom0-{passthrough,strict} ]
@@ -1235,6 +1235,12 @@ boolean (e.g. `iommu=no`) can override this and leave 
the IOMMUs disabled.
 This option depends on `intremap`, and is disabled by default due to some
 corner cases in the implementation which have yet to be resolved.
 
+*   The `crash-disable` boolean controls disabling IOMMU functionality 
(DMAR/IR/QI)
+before switching to a crash kernel. This option is inactive by default and
+is for compatibility with older kdump kernels only. Modern kernels copy
+all the necessary tables from the previous one following kexec which makes
+the transition transparent for them with IOMMU functions still on.
+
 The following options are specific to Intel VT-d hardware:
 
 *   The `snoop` boolean controls the Snoop Control sub-feature, and is active
diff --git a/xen/arch/x86/crash.c b/xen/arch/x86/crash.c
index 60c98b6..01e48a1 100644
--- a/xen/arch/x86/crash.c
+++ b/xen/arch/x86/crash.c
@@ -162,8 +162,11 @@ static void nmi_shootdown_cpus(void)
 printk("Failed to shoot down CPUs {%*pbl}\n",
nr_cpu_ids, cpumask_bits(_to_crash));
 
-/* Crash shutdown any IOMMU functionality as the crashdump kernel is not
- * happy when booting if interrupt/dma remapping is still enabled */
+/*
+ * Try to crash shutdown IOMMU functionality as some old crashdump
+ * kernels are not happy when booting if interrupt/dma remapping
+ * is still enabled.
+ */
 iommu_crash_shutdown();
 
 __stop_this_cpu();
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 5ecaa10..611e857 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -35,6 +35,7 @@ bool_t __read_mostly iommu_igfx = 1;
 bool_t __read_mostly iommu_snoop = 1;
 bool_t __read_mostly iommu_qinval = 1;
 bool_t __read_mostly iommu_intremap = 1;
+bool_t __read_mostly iommu_crash_disable;
 
 static bool __hwdom_initdata iommu_hwdom_none;
 bool __hwdom_initdata iommu_hwdom_strict;
@@ -88,6 +89,10 @@ static int __init parse_iommu_param(const char *s)
 iommu_intremap = val;
 else if ( (val = parse_boolean("intpost", s, ss)) >= 0 )
 iommu_intpost = val;
+#ifdef CONFIG_KEXEC
+else if ( (val = parse_boolean("crash-disable", s, ss)) >= 0 )
+iommu_crash_disable = val;
+#endif
 else if ( (val = parse_boolean("debug", s, ss)) >= 0 )
 {
 iommu_debug = val;
@@ -579,6 +584,9 @@ void iommu_share_p2m_table(struct domain* d)
 
 void iommu_crash_shutdown(void)
 {
+if ( !iommu_crash_disable )
+return;
+
 if ( iommu_enabled )
 iommu_get_ops()->crash_shutdown();
 iommu_enabled = iommu_intremap = iommu_intpost = 0;
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v2 3/4] x86/vmx: Fix security issue when a guest balloons out the #VE info page

[Razvan Cojocaru]

On 2/21/19 10:18 PM, Andrew Cooper wrote:
> The logic in altp2m_vcpu_{en,dis}able_ve() and vmx_vcpu_update_vmfunc_ve() is
> dangerous.  After #VE has been set up, the guest can balloon out and free the
> nominated GFN, after which the processor may write to it.  Also, the unlocked
> GFN query means the MFN is stale by the time it is used.  Alternatively, a
> guest can race two disable calls to cause one VMCS to still reference the
> nominated GFN after the tracking information was dropped.
> 
> Rework the logic from scratch to make it safe.
> 
> Hold an extra page reference on the underlying frame, to account for the
> VMCS's reference.  This means that if the GFN gets ballooned out, it isn't
> freed back to Xen until #VE is disabled, and the VMCS no longer refers to the
> page.
> 
> A consequence of this is that altp2m_vcpu_disable_ve() needs to be called
> during the domain_kill() path, to drop the reference for domains which shut
> down with #VE still enabled.
> 
> For domains using altp2m, we expect a single enable call and no disable for
> the remaining lifetime of the domain.  However, to avoid problems with
> concurrent calls, use cmpxchg() to locklessly maintain safety.
> 
> This doesn't have an XSA because altp2m is not yet a security-supported
> feature.
> 
> Signed-off-by: Andrew Cooper 
> Release-acked-by: Juergen Gross 

Tested-by: Razvan Cojocaru 


Thanks,
Razvan

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

Re: [Xen-devel] xen/evtchn and forced threaded irq

[Julien Grall]

Hi Roger,

On 21/02/2019 09:14, Roger Pau Monné wrote:
> On Thu, Feb 21, 2019 at 08:38:39AM +, Julien Grall wrote:
>> Hi Roger,
>>
>> On Thu, 21 Feb 2019, 08:08 Roger Pau Monné,  wrote:
>>
>>> FWIW, you can also mask the interrupt while waiting for the thread to
>>> execute the interrupt handler. Ie:
>>>
>>
>> Thank you for providing steps, however where would the masking be done? By
>> the irqchip or a custom solution?
>
> I'm not familiar with the irqchip infrastructure in Linux, what I
> proposed below is what FreeBSD does when running interrupt handlers in
> deferred threads IIRC.
>
> If irqchip has a specific handler to dispatch to a thread, then that's
> the place where the masking should happen. Likely, the unmasking
> should be done by the irq handling infrastructure after the thread
> executing the interrupt handler has finished.
>
> Isn't there a similar way to handle interrupts in threads for Linux?

Linux has a flag (IRQF_ONESHOT) to mask interrupt until the interrupt
handler has been run. It is set for all interrupts handler that have
been forced to be threaded.

However, it looks like the flag is been ignored by the irqchip handler
we use (handle_edge_irq). Doing a bit of digging, IRQF_ONESHOT use to be
handled in handle_edge_irq until the following commit from 2009:

commit 4dbc9ca219b0f294332e734528f7b82211700170
Author: Thomas Gleixner 
Date:   Thu Aug 27 09:38:49 2009 +0200

 genirq: Do not mask oneshot edge type interrupts

 Masking oneshot edge type interrupts is wrong as we might lose an
 interrupt which is issued when the threaded handler is handling the
 device. We can keep the irq unmasked safely as with edge type
 interrupts there is no danger of interrupt floods. If the threaded
 handler has not yet finished then IRQTF_RUNTHREAD is set which will
 keep the handler thread active.

 Debugged and verified in preempt-rt.

 Signed-off-by: Thomas Gleixner 

Furthermore, it is pretty clear from the comment on top of
handle_edge_irq that the same interrupt can come-up before the first one
is one is handled by the associated event handler.

I am still trying to figure out whether the issue lies in the evtchn
driver or the Xen irqchip (events_base.c). I will have a closer look and
come back with updates here.

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

[Xen-devel] [PATCH v2 3/4] x86/vmx: Fix security issue when a guest balloons out the #VE info page

[Andrew Cooper]

The logic in altp2m_vcpu_{en,dis}able_ve() and vmx_vcpu_update_vmfunc_ve() is
dangerous.  After #VE has been set up, the guest can balloon out and free the
nominated GFN, after which the processor may write to it.  Also, the unlocked
GFN query means the MFN is stale by the time it is used.  Alternatively, a
guest can race two disable calls to cause one VMCS to still reference the
nominated GFN after the tracking information was dropped.

Rework the logic from scratch to make it safe.

Hold an extra page reference on the underlying frame, to account for the
VMCS's reference.  This means that if the GFN gets ballooned out, it isn't
freed back to Xen until #VE is disabled, and the VMCS no longer refers to the
page.

A consequence of this is that altp2m_vcpu_disable_ve() needs to be called
during the domain_kill() path, to drop the reference for domains which shut
down with #VE still enabled.

For domains using altp2m, we expect a single enable call and no disable for
the remaining lifetime of the domain.  However, to avoid problems with
concurrent calls, use cmpxchg() to locklessly maintain safety.

This doesn't have an XSA because altp2m is not yet a security-supported
feature.

Signed-off-by: Andrew Cooper 
Release-acked-by: Juergen Gross 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Razvan Cojocaru 
CC: Tamas K Lengyel 
CC: Jun Nakajima 
CC: Kevin Tian 

v2:
 * Reuse domain_relinquish_resources() rather than introducing
   domain_unmap_resources().
 * Use check_get_page_from_gfn() rather than opcoding half of it.
 * Disallow registering the #VE info page over anything which isn't plain RAM
   in the guest.
---
 xen/arch/x86/domain.c  |  7 +
 xen/arch/x86/hvm/vmx/vmx.c | 33 ---
 xen/arch/x86/mm/altp2m.c   | 59 --
 xen/include/asm-x86/hvm/vcpu.h |  7 -
 4 files changed, 80 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7a29435..b5febd6 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2071,6 +2072,12 @@ int domain_relinquish_resources(struct domain *d)
 return ret;
 }
 
+if ( altp2m_active(d) )
+{
+for_each_vcpu ( d, v )
+altp2m_vcpu_disable_ve(v);
+}
+
 if ( is_pv_domain(d) )
 {
 for_each_vcpu ( d, v )
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 24def93..395bccd 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2196,14 +2196,11 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
 
 if ( cpu_has_vmx_virt_exceptions )
 {
-p2m_type_t t;
-mfn_t mfn;
+const struct page_info *pg = vcpu_altp2m(v).veinfo_pg;
 
-mfn = get_gfn_query_unlocked(d, gfn_x(vcpu_altp2m(v).veinfo_gfn), 
);
-
-if ( !mfn_eq(mfn, INVALID_MFN) )
+if ( pg )
 {
-__vmwrite(VIRT_EXCEPTION_INFO, mfn_x(mfn) << PAGE_SHIFT);
+__vmwrite(VIRT_EXCEPTION_INFO, page_to_maddr(pg));
 /*
  * Make sure we have an up-to-date EPTP_INDEX when
  * setting SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS.
@@ -2237,21 +2234,19 @@ static int vmx_vcpu_emulate_vmfunc(const struct 
cpu_user_regs *regs)
 
 static bool_t vmx_vcpu_emulate_ve(struct vcpu *v)
 {
-bool_t rc = 0, writable;
-gfn_t gfn = vcpu_altp2m(v).veinfo_gfn;
+const struct page_info *pg = vcpu_altp2m(v).veinfo_pg;
 ve_info_t *veinfo;
+bool rc = false;
 
-if ( gfn_eq(gfn, INVALID_GFN) )
-return 0;
+if ( !pg )
+return rc;
 
-veinfo = hvm_map_guest_frame_rw(gfn_x(gfn), 0, );
-if ( !veinfo )
-return 0;
-if ( !writable || veinfo->semaphore != 0 )
-goto out;
+veinfo = __map_domain_page(pg);
 
-rc = 1;
+if ( veinfo->semaphore != 0 )
+goto out;
 
+rc = true;
 veinfo->exit_reason = EXIT_REASON_EPT_VIOLATION;
 veinfo->semaphore = ~0;
 veinfo->eptp_index = vcpu_altp2m(v).p2midx;
@@ -2266,7 +2261,11 @@ static bool_t vmx_vcpu_emulate_ve(struct vcpu *v)
 X86_EVENT_NO_EC);
 
  out:
-hvm_unmap_guest_frame(veinfo, 0);
+unmap_domain_page(veinfo);
+
+if ( rc )
+paging_mark_dirty(v->domain, page_to_mfn(pg));
+
 return rc;
 }
 
diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index 8bdefb0..50768f2 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -27,7 +27,6 @@ altp2m_vcpu_initialise(struct vcpu *v)
 vcpu_pause(v);
 
 vcpu_altp2m(v).p2midx = 0;
-vcpu_altp2m(v).veinfo_gfn = INVALID_GFN;
 atomic_inc(_get_altp2m(v)->active_vcpus);
 
 altp2m_vcpu_update_p2m(v);
@@ -58,25 +57,69 @@ altp2m_vcpu_destroy(struct vcpu *v)
 
 int 

Re: [Xen-devel] XEN on R-CAR H3

[Oleksandr]

On 21.02.19 12:11, Julien Grall wrote:

Hi Oleksandr,


Hi, Julien, Amit




On 20/02/2019 21:28, Oleksandr Tyshchenko wrote:

ср, 20 февр. 2019 г., 22:14 Julien Grall mailto:julien.gr...@arm.com>>:
If I am not mistaken, the diff between BSP's and mainline device trees is in
reserved memory area. BSP device tree (1) contains reserved memory regions, but
the mainline one (2) doesn't.
  From the log you provided, I see that Xen is trying to copy device-tree to the
address which is located in reserved area (0x5800). FYI, we always remove
these reserved area nodes from the device-tree. Maybe that's why we didn't face
an issue. Julien, what do you think, can this be a reason?

While I know that Xen does not deal with reserved area yet, we should have been
able to write in that region. We don't even reach that state as we can't get the
associated page.

It might be possible that the p2m entry is overwritten when going through the DT
for mapping all the regions (see handle_device).


Make sense.


I have just made an experiment. I returned reserved nodes back in my 
setup and got an fault, similar to what Amit had faced.



(XEN) handle /memory@4800
(XEN)   Skip it (matched)
(XEN) handle /reserved-memory
(XEN) dt_irq_number: dev=/reserved-memory
(XEN) /reserved-memory passthrough = 1 nirq = 0 naddr = 0
(XEN) handle /reserved-memory/linux,lossy_decompress
(XEN) dt_irq_number: dev=/reserved-memory/linux,lossy_decompress
(XEN) /reserved-memory/linux,lossy_decompress passthrough = 1 nirq = 0 
naddr = 1
(XEN) DT: ** translation for device 
/reserved-memory/linux,lossy_decompress **

(XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
(XEN) DT: translating address:<3> <3> 5400<3>
(XEN) DT: parent bus is default (na=2, ns=2) on /
(XEN) DT: empty ranges; 1:1 translation
(XEN) DT: parent translation for:<3> <3> <3>
(XEN) DT: with offset: 5400
(XEN) DT: one level translation:<3> <3> 5400<3>
(XEN) DT: reached root node
(XEN)   - MMIO: 005400 - 005700 P2MType=5
(XEN) handle /reserved-memory/linux,adsp
(XEN) dt_irq_number: dev=/reserved-memory/linux,adsp
(XEN) /reserved-memory/linux,adsp passthrough = 1 nirq = 0 naddr = 1
(XEN) DT: ** translation for device /reserved-memory/linux,adsp **
(XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
(XEN) DT: translating address:<3> <3> 5700<3>
(XEN) DT: parent bus is default (na=2, ns=2) on /
(XEN) DT: empty ranges; 1:1 translation
(XEN) DT: parent translation for:<3> <3> <3>
(XEN) DT: with offset: 5700
(XEN) DT: one level translation:<3> <3> 5700<3>
(XEN) DT: reached root node
(XEN)   - MMIO: 005700 - 005800 P2MType=5
(XEN) handle /reserved-memory/linux,cma
(XEN) dt_irq_number: dev=/reserved-memory/linux,cma
(XEN) /reserved-memory/linux,cma passthrough = 1 nirq = 0 naddr = 1
(XEN) DT: ** translation for device /reserved-memory/linux,cma **
(XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
(XEN) DT: translating address:<3> <3> 5800<3>
(XEN) DT: parent bus is default (na=2, ns=2) on /
(XEN) DT: empty ranges; 1:1 translation
(XEN) DT: parent translation for:<3> <3> <3>
(XEN) DT: with offset: 5800
(XEN) DT: one level translation:<3> <3> 5800<3>
(XEN) DT: reached root node
*(XEN)   - MMIO: 005800 - 007000 P2MType=5*
(XEN) handle /reserved-memory/linux,multimedia
(XEN) dt_irq_number: dev=/reserved-memory/linux,multimedia
(XEN) /reserved-memory/linux,multimedia passthrough = 1 nirq = 0 naddr = 1
(XEN) DT: ** translation for device /reserved-memory/linux,multimedia **
(XEN) DT: bus is default (na=2, ns=2) on /reserved-memory
(XEN) DT: translating address:<3> <3> 7000<3>
(XEN) DT: parent bus is default (na=2, ns=2) on /
(XEN) DT: empty ranges; 1:1 translation
(XEN) DT: parent translation for:<3> <3> <3>
(XEN) DT: with offset: 7000
(XEN) DT: one level translation:<3> <3> 7000<3>
(XEN) DT: reached root node
(XEN)   - MMIO: 007000 - 008000 P2MType=5
(XEN) handle /mmngr
(XEN) dt_irq_number: dev=/mmngr
(XEN) /mmngr passthrough = 1 nirq = 0 naddr = 0
(XEN) handle /mmngrbuf
(XEN) dt_irq_number: dev=/mmngrbuf
(XEN) /mmngrbuf passthrough = 1 nirq = 0 naddr = 0
(XEN) handle /vspm_if
(XEN) dt_irq_number: dev=/vspm_if
(XEN) /vspm_if passthrough = 1 nirq = 0 naddr = 0
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Create hypervisor node
(XEN) Create PSCI node
(XEN) Create cpus node
(XEN) Create cpu@0 (logical CPUID: 0) node
(XEN) Create cpu@1 (logical CPUID: 1) node
(XEN) Create cpu@2 (logical CPUID: 2) node
(XEN) Create cpu@3 (logical CPUID: 3) node
(XEN) Create memory node (reg size 4, nr cells 4)
(XEN)   Bank 0: 0x6000->0x7000
*(XEN) Loading zImage from 7a00 to 
6008-6208*

(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Unable to copy the kernel in the hwdom memory
(XEN) 

Re: [Xen-devel] [PATCH v2] vm_event: Add a new opcode to get VM_EVENT_INTERFACE_VERSION

[Tamas K Lengyel]

On Thu, Feb 14, 2019 at 7:18 AM Petre Pircalabu
 wrote:
>
> Currently, the VM_EVENT_INTERFACE_VERSION is determined at runtime, by
> inspecting the corresponding field in a vm_event_request. This helper
> opcode will query the hypervisor supported version before the vm_event
> related structures and layout are set-up.
>
> Signed-off-by: Petre Pircalabu 

Acked-by: Tamas K Lengyel 

>
> ---
> Changes from v1:
>  - Return -ESRCH instead of -EINVAL if DOMID_INVALID if given as
>parameter to XEN_DOMCTL_vm_event_op and op is not
>XEN_VM_EVENT_GET_VERSION. Also the log message was removed.
>  - Replace XEN_VM_EVENT_GET_INTERFACE_VERSION with
>XEN_VM_EVENT_GET_VERSION.
>  - Replace the "get_interface_version" wrapper struct with a single
>"version" field.
>  - Rename the libxc wrapper to xc_vm_event_get_version.
> ---
>  tools/libxc/include/xenctrl.h |  5 +
>  tools/libxc/xc_vm_event.c | 18 +-
>  xen/common/domctl.c   |  1 +
>  xen/common/vm_event.c | 11 ++-
>  xen/include/public/domctl.h   |  9 -
>  5 files changed, 41 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 31cdda7..a3628e5 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2003,6 +2003,11 @@ int xc_set_mem_access_multi(xc_interface *xch, 
> uint32_t domain_id,
>  int xc_get_mem_access(xc_interface *xch, uint32_t domain_id,
>uint64_t pfn, xenmem_access_t *access);
>
> +/*
> + * Returns the VM_EVENT_INTERFACE version.
> + */
> +int xc_vm_event_get_version(xc_interface *xch);
> +
>  /***
>   * Monitor control operations.
>   *
> diff --git a/tools/libxc/xc_vm_event.c b/tools/libxc/xc_vm_event.c
> index 8674607..a97c615 100644
> --- a/tools/libxc/xc_vm_event.c
> +++ b/tools/libxc/xc_vm_event.c
> @@ -35,7 +35,7 @@ int xc_vm_event_control(xc_interface *xch, uint32_t 
> domain_id, unsigned int op,
>
>  rc = do_domctl(xch, );
>  if ( !rc && port )
> -*port = domctl.u.vm_event_op.port;
> +*port = domctl.u.vm_event_op.u.enable.port;
>  return rc;
>  }
>
> @@ -156,6 +156,22 @@ void *xc_vm_event_enable(xc_interface *xch, uint32_t 
> domain_id, int param,
>  return ring_page;
>  }
>
> +int xc_vm_event_get_version(xc_interface *xch)
> +{
> +DECLARE_DOMCTL;
> +int rc;
> +
> +domctl.cmd = XEN_DOMCTL_vm_event_op;
> +domctl.domain = DOMID_INVALID;
> +domctl.u.vm_event_op.op = XEN_VM_EVENT_GET_VERSION;
> +domctl.u.vm_event_op.mode = XEN_DOMCTL_VM_EVENT_OP_MONITOR;
> +
> +rc = do_domctl(xch, );
> +if ( !rc )
> +rc = domctl.u.vm_event_op.u.version;
> +return rc;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index d08b627..bade9a6 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -392,6 +392,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>  switch ( op->cmd )
>  {
>  case XEN_DOMCTL_test_assign_device:
> +case XEN_DOMCTL_vm_event_op:
>  if ( op->domain == DOMID_INVALID )
>  {
>  case XEN_DOMCTL_createdomain:
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 26cfa2c..19c983c 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -88,7 +88,7 @@ static int vm_event_enable(
>  if ( rc < 0 )
>  goto err;
>
> -(*ved)->xen_port = vec->port = rc;
> +(*ved)->xen_port = vec->u.enable.port = rc;
>
>  /* Prepare ring buffer */
>  FRONT_RING_INIT(&(*ved)->front_ring,
> @@ -592,6 +592,15 @@ int vm_event_domctl(struct domain *d, struct 
> xen_domctl_vm_event_op *vec,
>  {
>  int rc;
>
> +if ( vec->op == XEN_VM_EVENT_GET_VERSION )
> +{
> +vec->u.version = VM_EVENT_INTERFACE_VERSION;
> +return 0;
> +}
> +
> +if ( unlikely(d == NULL) )
> +return -ESRCH;
> +
>  rc = xsm_vm_event_control(XSM_PRIV, d, vec->mode, vec->op);
>  if ( rc )
>  return rc;
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 7e1cf21..19486d5 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -781,6 +781,7 @@ struct xen_domctl_gdbsx_domstatus {
>  #define XEN_VM_EVENT_ENABLE   0
>  #define XEN_VM_EVENT_DISABLE  1
>  #define XEN_VM_EVENT_RESUME   2
> +#define XEN_VM_EVENT_GET_VERSION  3
>
>  /*
>   * Domain memory paging
> @@ -843,7 +844,13 @@ struct xen_domctl_vm_event_op {
>  uint32_t   op;   /* XEN_VM_EVENT_* */
>  uint32_t   mode; /* XEN_DOMCTL_VM_EVENT_OP_* */
>
> -uint32_t port;  /* OUT: event channel for ring */
> +union {
> +struct {
> +uint32_t port;   /* OUT: event channel for ring */
> +} enable;
> +
> +uint32_t version;
> +} u;
>  };
>
>  /*
> --
> 2.7.4

Re: [Xen-devel] [PATCH V2 3/3] xen/arm: Add SCIFA UART support for early printk

[Oleksandr]

On 21.02.19 20:43, Julien Grall wrote:

Hi Oleksandr,


Hi Julien




On 2/21/19 6:22 PM, Oleksandr wrote:
=> Actually, the main difference for the "early printk" support is in

two reg offsets:

+#define SCIFA_SCASSR   0x14    /* Serial status register */
+#define SCIFA_SCAFTDR  0x20    /* Transmit FIFO data register */

+#define SCIF_SCFSR 0x10    /* Serial status register */
+#define SCIF_SCFTDR    0x0c    /* Transmit FIFO data 
register */



I am not mistaken, we will have to introduce two options to cover 
this case, as the offsets are not correlated with each other, no?


You don't need two options. For instance, you can only introduce an 
option SCIF_VERSION that would be 0 for SCIF and 61 (ascii 'a') for 
SCIFA.


Then in the code, you can use SCIF_VERSION to decides which sets of 
macros you are using.


I think I understand the idea. Will try.



Is it something you would like to see?


Your solution below require to overwrite EARLY_PRINTK_INC and not very 
easy to extend of other version (e.g scifb). As I suggested earlier, 
we can introduce an option the same way REG_SHIFT exist for 8250. The 
definition of CONFIG_EARLY_PRINTK is:


CONFIG_EARLY_PRINTK=,,

 would be the version. Nothing for SCIF and A for SCFIA.

Then in Rules.mk, you would have something like:

ifneq ($(word 3,$(EARLY_PRINTK_CFG)),)
CFLAGS-y += -DCONFIG_EARLY_PRINTK_VERSION_$(word 3, $(EARLY_PRINTK_CFG)
else
CFLAGS-y += -DCONFIG_EARLY_PRINTK_VERSION_NONE
endif

debug-scif.inc would then contain:

#ifdef CONFIG_EARLY_PRINTK_VERSION_A
#define foo
#define bar
#elifdef CONFIG_EARLY_PRINTK_VERSION_NONE
#define foo
#define bar
#endif

The CONFIG_EARLY_PRINTK_VERSION_NONE is here to help catching new 
addition. If someone if using a different version, it would not compile.
Also, the code in Rules.mk is generic enough to extend for other 
version (e.g scifb).


Does it make sense?


Absolutely. Thank you




Cheers,


--
Regards,

Oleksandr Tyshchenko


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

Re: [Xen-devel] XEN on R-CAR H3

[Oleksandr]

On 21.02.19 20:20, Amit Tomer wrote:

Hi,


Hi





(1) 
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts?h=v4.14.75-ltsi/rcar-3.9.3.rc1

(2) 
https://elixir.bootlin.com/linux/v5.0-rc7/source/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts

Yeah, this is what I thought initially but was not able to compile dts
file after removing the reserve node.


Likely, it is because you left device nodes (mmngr,adsp,etc) which had 
links to reserved-memory regions ...





Will try it again, Thanks for pointing it out.

Thanks
-Amit.


--
Regards,

Oleksandr Tyshchenko


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

Re: [Xen-devel] [PATCH V2 3/3] xen/arm: Add SCIFA UART support for early printk

[Julien Grall]

Hi Oleksandr,

On 2/21/19 6:22 PM, Oleksandr wrote:
=> Actually, the main difference for the "early printk" support is in

two reg offsets:

+#define SCIFA_SCASSR   0x14    /* Serial status register */
+#define SCIFA_SCAFTDR  0x20    /* Transmit FIFO data register */

+#define SCIF_SCFSR 0x10    /* Serial status register */
+#define SCIF_SCFTDR    0x0c    /* Transmit FIFO data 
register */



I am not mistaken, we will have to introduce two options to cover 
this case, as the offsets are not correlated with each other, no?


You don't need two options. For instance, you can only introduce an 
option SCIF_VERSION that would be 0 for SCIF and 61 (ascii 'a') for 
SCIFA.


Then in the code, you can use SCIF_VERSION to decides which sets of 
macros you are using.


I think I understand the idea. Will try.



Is it something you would like to see?


Your solution below require to overwrite EARLY_PRINTK_INC and not very 
easy to extend of other version (e.g scifb). As I suggested earlier, we 
can introduce an option the same way REG_SHIFT exist for 8250. The 
definition of CONFIG_EARLY_PRINTK is:


CONFIG_EARLY_PRINTK=,,

 would be the version. Nothing for SCIF and A for SCFIA.

Then in Rules.mk, you would have something like:

ifneq ($(word 3,$(EARLY_PRINTK_CFG)),)
CFLAGS-y += -DCONFIG_EARLY_PRINTK_VERSION_$(word 3, $(EARLY_PRINTK_CFG)
else
CFLAGS-y += -DCONFIG_EARLY_PRINTK_VERSION_NONE
endif

debug-scif.inc would then contain:

#ifdef CONFIG_EARLY_PRINTK_VERSION_A
#define foo
#define bar
#elifdef CONFIG_EARLY_PRINTK_VERSION_NONE
#define foo
#define bar
#endif

The CONFIG_EARLY_PRINTK_VERSION_NONE is here to help catching new 
addition. If someone if using a different version, it would not compile.
Also, the code in Rules.mk is generic enough to extend for other version 
(e.g scifb).


Does it make sense?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V2 3/3] xen/arm: Add SCIFA UART support for early printk

[Oleksandr]

Hi Julien

Actually, the main difference for the "early printk" support is in 
two reg offsets:


+#define SCIFA_SCASSR   0x14    /* Serial status register */
+#define SCIFA_SCAFTDR  0x20    /* Transmit FIFO data register */

+#define SCIF_SCFSR 0x10    /* Serial status register */
+#define SCIF_SCFTDR    0x0c    /* Transmit FIFO data 
register */



I am not mistaken, we will have to introduce two options to cover 
this case, as the offsets are not correlated with each other, no?


You don't need two options. For instance, you can only introduce an 
option SCIF_VERSION that would be 0 for SCIF and 61 (ascii 'a') for 
SCIFA.


Then in the code, you can use SCIF_VERSION to decides which sets of 
macros you are using.


I think I understand the idea. Will try.



Is it something you would like to see?

[Sorry for formatting]


---
 xen/arch/arm/Rules.mk |  7 +++
 xen/arch/arm/arm32/debug-scif.inc | 22 +++---
 2 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index f264592..b29bd60 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -69,6 +69,12 @@ EARLY_PRINTK_BAUD := $(word 3,$(EARLY_PRINTK_CFG))
 endif
 endif

+# For the debug-scif.inc to recognize which UART offsets to apply
+ifeq ($(EARLY_PRINTK_INC),scifa)
+EARLY_PRINTK_SCIFA_OPTION := y
+EARLY_PRINTK_INC := scif
+endif
+
 ifneq ($(EARLY_PRINTK_INC),)
 EARLY_PRINTK := y
 endif
@@ -79,6 +85,7 @@ CFLAGS-$(EARLY_PRINTK) += 
-DEARLY_PRINTK_INC=\"debug-$(EARLY_PRINTK_INC).inc\"

 CFLAGS-$(EARLY_PRINTK) += -DEARLY_PRINTK_BAUD=$(EARLY_PRINTK_BAUD)
 CFLAGS-$(EARLY_PRINTK) += 
-DEARLY_UART_BASE_ADDRESS=$(EARLY_UART_BASE_ADDRESS)

 CFLAGS-$(EARLY_PRINTK) += -DEARLY_UART_REG_SHIFT=$(EARLY_UART_REG_SHIFT)
+CFLAGS-$(EARLY_PRINTK_SCIFA_OPTION) += -DEARLY_PRINTK_SCIFA_OPTION

 else # !CONFIG_DEBUG

diff --git a/xen/arch/arm/arm32/debug-scif.inc 
b/xen/arch/arm/arm32/debug-scif.inc

index 143f05d..49df616 100644
--- a/xen/arch/arm/arm32/debug-scif.inc
+++ b/xen/arch/arm/arm32/debug-scif.inc
@@ -1,7 +1,7 @@
 /*
  * xen/arch/arm/arm32/debug-scif.inc
  *
- * SCIF specific debug code
+ * SCIF(A) specific debug code
  *
  * Oleksandr Tyshchenko 
  * Copyright (C) 2014, Globallogic.
@@ -19,28 +19,36 @@

 #include 

+#ifdef EARLY_PRINTK_SCIFA_OPTION
+#define STATUS_REG    SCIFA_SCASSR
+#define TX_FIFO_REG   SCIFA_SCAFTDR
+#else
+#define STATUS_REG    SCIF_SCFSR
+#define TX_FIFO_REG   SCIF_SCFTDR
+#endif
+
 /*
- * SCIF UART wait UART to be ready to transmit
+ * SCIF(A) UART wait UART to be ready to transmit
  * rb: register which contains the UART base address
  * rc: scratch register
  */
 .macro early_uart_ready rb rc
 1:
-    ldrh   \rc, [\rb, #SCIF_SCFSR]   /* <- SCFSR (status register) */
+    ldrh   \rc, [\rb, #STATUS_REG]   /* Read status register */
 tst    \rc, #SCFSR_TDFE  /* Check TDFE bit */
 beq    1b    /* Wait for the UART to be 
ready */

 .endm

 /*
- * SCIF UART transmit character
+ * SCIF(A) UART transmit character
  * rb: register which contains the UART base address
  * rt: register which contains the character to transmit
  */
 .macro early_uart_transmit rb rt
-    strb   \rt, [\rb, #SCIF_SCFTDR]  /* -> SCFTDR 
(data register) */
-    ldrh   \rt, [\rb, #SCIF_SCFSR]   /* <- SCFSR 
(status register) */
+    strb   \rt, [\rb, #TX_FIFO_REG]  /* Write data 
register */
+    ldrh   \rt, [\rb, #STATUS_REG]   /* Read status 
register */
 and    \rt, \rt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear TEND 
and TDFE bits */
-    strh   \rt, [\rb, #SCIF_SCFSR]   /* -> SCFSR 
(status register) */
+    strh   \rt, [\rb, #STATUS_REG]   /* Write 
status register */

 .endm

 /*
--
2.7.4






--
Regards,

Oleksandr Tyshchenko


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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,

> (1) 
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts?h=v4.14.75-ltsi/rcar-3.9.3.rc1
>
> (2) 
> https://elixir.bootlin.com/linux/v5.0-rc7/source/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts

Yeah, this is what I thought initially but was not able to compile dts
file after removing the reserve node.

Will try it again, Thanks for pointing it out.

Thanks
-Amit.

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

Re: [Xen-devel] [PATCH v3 02/17] Document ioemu Linux stubdomain protocol

[Marek Marczykowski-Górecki]

On Thu, Feb 21, 2019 at 05:31:54PM +, Wei Liu wrote:
> On Thu, Feb 21, 2019 at 06:08:22PM +0100, Marek Marczykowski-Górecki wrote:
> > On Thu, Feb 21, 2019 at 03:39:25PM +, Wei Liu wrote:
> > > On Mon, Jan 28, 2019 at 10:30:19PM +0100, Marek Marczykowski-Górecki 
> > > wrote:
> > > > Add documentation for upcoming Linux stubdomain for qemu-upstream.
> > > > 
> > > > Signed-off-by: Marek Marczykowski-Górecki 
> > > > 
> > > > ---
> > > >  docs/misc/stubdom.txt | 50 
> > > > -
> > > >  1 file changed, 50 insertions(+)
> > > > 
> > > > diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
> > > > index 4c524f2..9c94c6b 100644
> > > > --- a/docs/misc/stubdom.txt
> > > > +++ b/docs/misc/stubdom.txt
> > > > @@ -75,6 +75,56 @@ Defined commands:
> > > > - "running" - success
> > > >  
> > > >  
> > > > +Toolstack to Linux ioemu stubdomain protocol
> > > > +
> > > > +
> > > > +This section describe communication protocol between toolstack and
> > > > +qemu-upstream running in Linux stubdomain. The protocol include
> > > > +expectations of both stubdomain, and qemu.
> > > > +
> > > > +Setup (done by toolstack, expected by stubdomain):
> > > > + - Block devices for target domain are connected as PV disks to 
> > > > stubdomain,
> > > > +   according to configuration order, starting with xvda
> > > > + - Network devices for target domain are connected as PV nics to 
> > > > stubdomain,
> > > > +   according to configuration order, starting with 0
> > > > + - [not implemented] if graphics output is expected, VFB and VKB 
> > > > devices are set for stubdomain
> > > > +   (its backend is responsible for exposing them using appropriate 
> > > > protocol
> > > > +   like VNC or Spice)
> > > > + - other target domain's devices are not connected at this point to 
> > > > stubdomain
> > > > +   (may be hot-plugged later)
> > > > + - QEMU command line is stored in
> > > > +   /vm//image/dmargs xenstore dir, each argument as 
> > > > separate key
> > > > +   in form /vm//image/dmargs/NNN, where NNN is 0-padded 
> > > > argument
> > > > +   number
> > > > + - target domain id is stored in /local/domain//target 
> > > > xenstore path
> > > > +?? - bios type is stored in /local/domain//hvmloader/bios
> > > 
> > > Since you're defining a new protocol here, you have the liberty to
> > > eliminate this uncertainty, unless for some reason you want it to be
> > > compatible with the old stubdom?
> > 
> > I'm not sure who access this xenstore key, since I haven't found how is
> > it used in minios based stubdomain. Is it used by qemu?
> 
> It is read by hvmloader afaict.

Ah, in that case I think it should be removed from this (and minios)
spec, because it is irrelevant to stubdomain.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,

> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d9836779d1..08b9cd2c44 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1805,6 +1805,8 @@ static void __init dtb_load(struct kernel_info *kinfo)
>  printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> kinfo->dtb_paddr, kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
>
> +dump_p2m_lookup(kinfo->d, kinfo->dtb_paddr);
> +
>  left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
> kinfo->fdt,
> fdt_totalsize(kinfo->fdt));
>
Please find the logs after applying this patch:

(XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading Domd0 kernel from boot module @ 7a00
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x005000-0x007000 (512MB)
(XEN) Grant table range: 0x004800-0x004804
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading zImage from 7a00 to 5008-5188
(XEN) Loading dom0 DTB to 0x5800-0x58010a44
(XEN) dom0 IPA 0x5800
(XEN) P2M @ 00080c23dc90 mfn:0x73ff5e
(XEN) 0TH[0x0] = 0x00873ff5c7ff
(XEN) 1ST[0x1] = 0x00873ff3d7ff
(XEN) 2ND[0xc0] = 0x02c0580006fd
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Unable to copy the DTB to dom0 memory (left = 68164 bytes)
(XEN) 
(XEN)
(XEN) Reboot in five seconds...

Thanks
-Amit

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

Re: [Xen-devel] [PATCH v3 04/17] libxl: Allow running qemu-xen in stubdomain

[Wei Liu]

On Thu, Feb 21, 2019 at 06:06:31PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Feb 21, 2019 at 04:01:59PM +, Wei Liu wrote:
> > On Mon, Jan 28, 2019 at 10:30:21PM +0100, Marek Marczykowski-Górecki wrote:
> > > Do not prohibit anymore using stubdomain with qemu-xen.
> > > To help distingushing MiniOS and Linux stubdomain, add helper inline
> > > functions libxl__stubdomain_is_linux() and
> > > libxl__stubdomain_is_linux_running(). Those should be used where really
> > > the difference is about MiniOS/Linux, not qemu-xen/qemu-xen-traditional.
> > > 
> > > Signed-off-by: Marek Marczykowski-Górecki 
> > > 
> > > 
> > > ---
> > > Changes in v3:
> > >  - new patch, instead of "libxl: Add "stubdomain_version" to
> > >  domain_build_info"
> > >  - helper functions as suggested by Ian Jackson
> > > ---
> > >  tools/libxl/libxl_create.c   |  9 -
> > >  tools/libxl/libxl_internal.h | 17 +
> > >  2 files changed, 17 insertions(+), 9 deletions(-)
> > > 
> (...)
> > > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > > index 459f9bf..b8c698a 100644
> > > --- a/tools/libxl/libxl_internal.h
> > > +++ b/tools/libxl/libxl_internal.h
> > > @@ -2195,6 +2195,23 @@ _hidden int 
> > > libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
> > >/* Return the system-wide default device model */
> > >  _hidden libxl_device_model_version libxl__default_device_model(libxl__gc 
> > > *gc);
> > >  
> > > +static inline
> > > +bool libxl__stubdomain_is_linux_running(libxl__gc *gc, uint32_t domid)
> > > +{
> > > +/* same logic as in libxl__stubdomain_is_linux */
> > > +return libxl__device_model_version_running(gc, domid)
> > > +== LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
> > 
> > I don't think the logic is accurate. You're precluding running
> > qemu-xen in a unikernel as stubdom.
> > 
> > I think putting an extra key in xenstore with the underlying platform is
> > more desirable.
> > 
> > > +}
> > > +
> > > +static inline
> > > +bool libxl__stubdomain_is_linux(libxl_domain_build_info *b_info)
> > > +{
> > > +/* right now qemu-tranditional implies MiniOS stubdomain and qemu-xen
> > > + * implies Linux stubdomain */
> > > +return libxl_defbool_val(b_info->device_model_stubdomain) &&
> > > +b_info->device_model_version == 
> > > LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
> > 
> > Subsequently you will need a new field in b_info.
> > 
> > What do you think?
> 
> This is _exactly_ what was in v2 of this patch and Ian suggested to
> change it:
> https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01317.html

Alright. Ian thought unikernel qemu-xen stubdomain was not coming along
any time soon. I don't disagree. You can keep the patch as-is.

I think in the future if it does come along, we can still easily
distinguish it from the rest.

Wei.

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

[Xen-devel] [linux-4.14 test] 133326: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-ws16-amd64 broken
 test-amd64-amd64-xl-qemut-win7-amd64 broken
 test-amd64-i386-xl-qemut-win10-i386 broken
 test-amd64-amd64-xl-qcow2broken
 test-amd64-amd64-xl  broken
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm   broken
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm   broken
 test-amd64-i386-qemuu-rhel6hvm-intel broken
 test-amd64-amd64-libvirt-vhd broken
 test-amd64-amd64-xl-pvhv2-intel broken
 test-amd64-i386-xl-qemut-win7-amd64 broken
 test-amd64-i386-xl-qemuu-win10-i386 broken
 build-armhf  broken
 test-amd64-amd64-xl-qemuu-ws16-amd64 broken
 test-amd64-i386-xl-qemut-win7-amd64  4 host-install(4) broken REGR. vs. 133261
 test-amd64-amd64-xl-qemut-ws16-amd64 4 host-install(4) broken REGR. vs. 133261
 test-amd64-amd64-xl-qemuu-ws16-amd64 4 host-install(4) broken REGR. vs. 133261
 test-amd64-amd64-libvirt-vhd  4 host-install(4)broken REGR. vs. 133261
 test-amd64-amd64-xl   4 host-install(4)broken REGR. vs. 133261
 test-amd64-i386-xl-qemuu-win10-i386  4 host-install(4) broken REGR. vs. 133261
 test-amd64-i386-qemuu-rhel6hvm-intel 4 host-install(4) broken REGR. vs. 133261
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 4 host-install(4) broken REGR. 
vs. 133261
 test-amd64-amd64-xl-pvhv2-intel  4 host-install(4) broken REGR. vs. 133261
 test-amd64-amd64-xl-qemut-win7-amd64 4 host-install(4) broken REGR. vs. 133261
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken 
REGR. vs. 133261
 test-amd64-i386-xl-qemut-win10-i386  4 host-install(4) broken REGR. vs. 133261
 test-amd64-amd64-xl-qcow2 4 host-install(4)broken REGR. vs. 133261
 build-armhf   4 host-install(4)broken REGR. vs. 133261
 test-amd64-i386-xl  20 guest-start/debian.repeat fail REGR. vs. 133261
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail REGR. vs. 133261
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 133261
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 133261
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 18 guest-start/debianhvm.repeat 
fail REGR. vs. 133261
 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail REGR. vs. 133261
 test-amd64-amd64-amd64-pvgrub 10 debian-di-install   fail REGR. vs. 133261
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
133261
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 133261

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-check  

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

[Wei Liu]

On Thu, Feb 21, 2019 at 10:59:41AM +0100, Roger Pau Monné wrote:
> On Wed, Feb 20, 2019 at 05:08:09PM +, Wei Liu wrote:
> > On Wed, Feb 20, 2019 at 01:09:56PM +, Wei Liu wrote:
> > [...]
> > > I think under-allocate-then-map looks plausible. xmalloc will need
> > > to allocate pages, put them into an array and call __vmap on that array
> > > directly.
> > 
> > The biggest issue with this approach is that we now need an array of
> > 1UL< > this is going to be (1UL<<20)*8 bytes long. This is not feasible.
> 
> Right. I guess the only remaining option is to allocate a virtual
> address space and populate it using multiple pages?

I probably was not clear enough -- the aforementioned array was needed
for this method, so I don't think this is feasible.

> 
> That would likely require to split some functions into smaller helpers
> so you can call them and provide the virtual address where a page
> should be mapped?
> 

Not feasible as of now. The fundamental issue is that vmap is managed by
a bitmap which has 1:1 mapping for page and address space, and it
mandates a guard page for each allocation.

To make this work we need to remove the mandatory guard page. Inventing
more complex tracking structure is probably not worth it.

Wei.

> Roger.

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

Re: [Xen-devel] [PATCH v4.1 4/6] xen/x86: Allow stubdom access to irq created for msi.

[Marek Marczykowski-Górecki]

On Thu, Feb 21, 2019 at 05:47:51PM +0100, Roger Pau Monné wrote:
> On Fri, Feb 08, 2019 at 11:17:05AM +0100, Marek Marczykowski-Górecki wrote:
> > Stubdomains need to be given sufficient privilege over the guest which it
> > provides emulation for in order for PCI passthrough to work correctly.
> > When a HVM domain try to enable MSI, QEMU in stubdomain calls
> > PHYSDEVOP_map_pirq, but later it needs to call XEN_DOMCTL_bind_pt_irq as
> > part of xc_domain_update_msi_irq. Allow for that as part of
> > PHYSDEVOP_map_pirq.
> > 
> > This is not needed for PCI INTx, because IRQ in that case is known
> > beforehand and the stubdomain is given permissions over this IRQ by
> > libxl__device_pci_add (there's a do_pci_add against the stubdomain).
> > 
> > create_irq() already grant IRQ access to hardware_domain, with
> > assumption the device model (something managing this IRQ) lives there.
> > Modify create_irq() to take additional parameter pointing at device
> > model domain - which may be dom0 or stubdomain. Do the same with
> > destroy_irq() (and msi_free_irq() which calls it) to reverse the
> > operation.
> > 
> > Then, adjust all callers to provide the parameter. In case of calls not
> > related to stubdomain-initiated allocations, give it hardware_domain, so
> > the behavior is unchanged there.
> > 
> > Inspired by 
> > https://github.com/OpenXT/xenclient-oe/blob/5e0e7304a5a3c75ef01240a1e3673665b2aaf05e/recipes-extended/xen/files/stubdomain-msi-irq-access.patch
> >  by Eric Chanudet .
> > 
> > Signed-off-by: Simon Gaiser 
> > Signed-off-by: Marek Marczykowski-Górecki 
> 
> Thanks for working on this! I've got some comments below.
> 
> > ---
> > Changes in v3:
> >  - extend commit message
> > Changes in v4:
> >  - add missing destroy_irq on error path
> > Changes in v4.1:
> >  - move irq_{grant,revoke}_access() to {create,destroy}_irq(), which
> >basically make it a different patch
> > 
> > There is one code path where I haven't managed to properly extract
> > possible stubdomain in use:
> > pci_remove_device()
> >  -> pci_cleanup_msi()
> >-> msi_free_irqs()
> >  -> msi_free_irq()
> >-> destroy_irq()
> > 
> > For now I've hardcoded hardware_domain there (in msi_free_irqs). Can it 
> > happen
> > when device is still assigned to some domU?
> > ---
> >  xen/arch/x86/hpet.c  |  5 +--
> >  xen/arch/x86/irq.c   | 46 ++--
> >  xen/arch/x86/msi.c   |  6 ++--
> >  xen/drivers/char/ns16550.c   |  6 ++--
> >  xen/drivers/passthrough/amd/iommu_init.c |  4 +--
> >  xen/drivers/passthrough/vtd/iommu.c  |  7 ++--
> >  xen/include/asm-x86/irq.h|  4 +--
> >  xen/include/asm-x86/msi.h|  2 +-
> >  8 files changed, 46 insertions(+), 34 deletions(-)
> > 
> > diff --git a/xen/arch/x86/hpet.c b/xen/arch/x86/hpet.c
> > index 4b08488ef1..6db71dfd71 100644
> > --- a/xen/arch/x86/hpet.c
> > +++ b/xen/arch/x86/hpet.c
> > @@ -11,6 +11,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -368,13 +369,13 @@ static int __init hpet_assign_irq(struct 
> > hpet_event_channel *ch)
> >  {
> >  int irq;
> >  
> > -if ( (irq = create_irq(NUMA_NO_NODE)) < 0 )
> > +if ( (irq = create_irq(NUMA_NO_NODE, hardware_domain)) < 0 )
> >  return irq;
> >  
> >  ch->msi.irq = irq;
> >  if ( hpet_setup_msi_irq(ch) )
> >  {
> > -destroy_irq(irq);
> > +destroy_irq(irq, hardware_domain);
> 
> Hm, here you should use an explicit NULL instead of hardware_domain
> (which will also be NULL by the time this gets called). This irq is
> used by Xen, and it doesn't make sense logically to give permissions
> over it to the hardware domain.

Ok.

> >  return -EINVAL;
> >  }
> >  
> > diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
> > index 8b44d6ce0b..d41b32b2f4 100644
> > --- a/xen/arch/x86/irq.c
> > +++ b/xen/arch/x86/irq.c
> > @@ -157,7 +157,7 @@ int __init bind_irq_vector(int irq, int vector, const 
> > cpumask_t *cpu_mask)
> >  /*
> >   * Dynamic irq allocate and deallocation for MSI
> >   */
> > -int create_irq(nodeid_t node)
> > +int create_irq(nodeid_t node, struct domain *dm_domain)
> 
> Using plain 'd' would be fine for me here, same below for
> destroy_irq.

I think it may be misleading, as the parameter is not about domain that
will handle that IRQ, but what domain will get access to it.

> >  {
> >  int irq, ret;
> >  struct irq_desc *desc;
> > @@ -190,19 +190,19 @@ int create_irq(nodeid_t node)
> >  desc->arch.used = IRQ_UNUSED;
> >  irq = ret;
> >  }
> > -else if ( hardware_domain )
> > +else if ( dm_domain )
> 
> Can you guarantee that dm_domain is always current->domain?

No, in some cases it will be hardware_domain.

> I think you need to assert for this, or else take a reference to
> dm_domain (get_domain) before accessing it's fields, or else 

Re: [Xen-devel] [PATCH] tools: add link path flag for local build to pkg-config files

[Wei Liu]

CC Anthony

On Thu, Feb 21, 2019 at 06:36:13PM +0100, Juergen Gross wrote:
> The qemu build process is requiring the link path of Xen libraries
> to be specified both with -L and -Wl,-rpath-link. Add the -L flag
> to the local pkg-config files.
> 
> At the same time let the pkg-config files depend on the Makefile
> creating them, too.
> 
> Signed-off-by: Juergen Gross 
> ---
>  tools/Rules.mk | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/Rules.mk b/tools/Rules.mk
> index 68f2ed7ce1..f5613f73a7 100644
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -262,7 +262,7 @@ PKG_CONFIG_DIR ?= $(XEN_ROOT)/tools/pkg-config
>  
>  PKG_CONFIG_FILTER = $(foreach l,$(PKG_CONFIG_REMOVE),-e 's!\([ 
> ,]\)$(l),!\1!g' -e 's![ ,]$(l)$$!!g')
>  
> -$(PKG_CONFIG_DIR)/%.pc: %.pc.in Makefile
> +$(PKG_CONFIG_DIR)/%.pc: %.pc.in Makefile $(XEN_ROOT)/tools/Rules.mk
>   mkdir -p $(PKG_CONFIG_DIR)
>   @sed -e 's!@@version@@!$(PKG_CONFIG_VERSION)!g' \
>-e 's!@@prefix@@!$(PKG_CONFIG_PREFIX)!g' \
> @@ -271,10 +271,10 @@ $(PKG_CONFIG_DIR)/%.pc: %.pc.in Makefile
>-e 's!@@firmwaredir@@!$(XENFIRMWAREDIR)!g' \
>-e 's!@@libexecbin@@!$(LIBEXEC_BIN)!g' \
>-e 's!@@cflagslocal@@!$(PKG_CONFIG_CFLAGS_LOCAL)!g' \
> -  -e 's!@@libsflag@@!-Wl,-rpath-link=!g' \
> +  -e 's!@@libsflag@@\([^ ]*\)!-L\1 -Wl,-rpath-link=\1!g' \
>$(PKG_CONFIG_FILTER) < $< > $@
>  
> -%.pc: %.pc.in Makefile
> +%.pc: %.pc.in Makefile $(XEN_ROOT)/tools/Rules.mk
>   @sed -e 's!@@version@@!$(PKG_CONFIG_VERSION)!g' \
>-e 's!@@prefix@@!$(PKG_CONFIG_PREFIX)!g' \
>-e 's!@@incdir@@!$(PKG_CONFIG_INCDIR)!g' \
> -- 
> 2.16.4
> 

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

Re: [Xen-devel] [PATCH] tools: add link path flag for local build to pkg-config files

[Wei Liu]

On Thu, Feb 21, 2019 at 06:36:13PM +0100, Juergen Gross wrote:
> The qemu build process is requiring the link path of Xen libraries
> to be specified both with -L and -Wl,-rpath-link. Add the -L flag
> to the local pkg-config files.
> 
> At the same time let the pkg-config files depend on the Makefile
> creating them, too.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH] tools: add link path flag for local build to pkg-config files

[Juergen Gross]

The qemu build process is requiring the link path of Xen libraries
to be specified both with -L and -Wl,-rpath-link. Add the -L flag
to the local pkg-config files.

At the same time let the pkg-config files depend on the Makefile
creating them, too.

Signed-off-by: Juergen Gross 
---
 tools/Rules.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 68f2ed7ce1..f5613f73a7 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -262,7 +262,7 @@ PKG_CONFIG_DIR ?= $(XEN_ROOT)/tools/pkg-config
 
 PKG_CONFIG_FILTER = $(foreach l,$(PKG_CONFIG_REMOVE),-e 's!\([ ,]\)$(l),!\1!g' 
-e 's![ ,]$(l)$$!!g')
 
-$(PKG_CONFIG_DIR)/%.pc: %.pc.in Makefile
+$(PKG_CONFIG_DIR)/%.pc: %.pc.in Makefile $(XEN_ROOT)/tools/Rules.mk
mkdir -p $(PKG_CONFIG_DIR)
@sed -e 's!@@version@@!$(PKG_CONFIG_VERSION)!g' \
 -e 's!@@prefix@@!$(PKG_CONFIG_PREFIX)!g' \
@@ -271,10 +271,10 @@ $(PKG_CONFIG_DIR)/%.pc: %.pc.in Makefile
 -e 's!@@firmwaredir@@!$(XENFIRMWAREDIR)!g' \
 -e 's!@@libexecbin@@!$(LIBEXEC_BIN)!g' \
 -e 's!@@cflagslocal@@!$(PKG_CONFIG_CFLAGS_LOCAL)!g' \
--e 's!@@libsflag@@!-Wl,-rpath-link=!g' \
+-e 's!@@libsflag@@\([^ ]*\)!-L\1 -Wl,-rpath-link=\1!g' \
 $(PKG_CONFIG_FILTER) < $< > $@
 
-%.pc: %.pc.in Makefile
+%.pc: %.pc.in Makefile $(XEN_ROOT)/tools/Rules.mk
@sed -e 's!@@version@@!$(PKG_CONFIG_VERSION)!g' \
 -e 's!@@prefix@@!$(PKG_CONFIG_PREFIX)!g' \
 -e 's!@@incdir@@!$(PKG_CONFIG_INCDIR)!g' \
-- 
2.16.4


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

Re: [Xen-devel] [PATCH v3 02/17] Document ioemu Linux stubdomain protocol

[Wei Liu]

On Thu, Feb 21, 2019 at 06:08:22PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Feb 21, 2019 at 03:39:25PM +, Wei Liu wrote:
> > On Mon, Jan 28, 2019 at 10:30:19PM +0100, Marek Marczykowski-Górecki wrote:
> > > Add documentation for upcoming Linux stubdomain for qemu-upstream.
> > > 
> > > Signed-off-by: Marek Marczykowski-Górecki 
> > > 
> > > ---
> > >  docs/misc/stubdom.txt | 50 -
> > >  1 file changed, 50 insertions(+)
> > > 
> > > diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
> > > index 4c524f2..9c94c6b 100644
> > > --- a/docs/misc/stubdom.txt
> > > +++ b/docs/misc/stubdom.txt
> > > @@ -75,6 +75,56 @@ Defined commands:
> > > - "running" - success
> > >  
> > >  
> > > +Toolstack to Linux ioemu stubdomain protocol
> > > +
> > > +
> > > +This section describe communication protocol between toolstack and
> > > +qemu-upstream running in Linux stubdomain. The protocol include
> > > +expectations of both stubdomain, and qemu.
> > > +
> > > +Setup (done by toolstack, expected by stubdomain):
> > > + - Block devices for target domain are connected as PV disks to 
> > > stubdomain,
> > > +   according to configuration order, starting with xvda
> > > + - Network devices for target domain are connected as PV nics to 
> > > stubdomain,
> > > +   according to configuration order, starting with 0
> > > + - [not implemented] if graphics output is expected, VFB and VKB devices 
> > > are set for stubdomain
> > > +   (its backend is responsible for exposing them using appropriate 
> > > protocol
> > > +   like VNC or Spice)
> > > + - other target domain's devices are not connected at this point to 
> > > stubdomain
> > > +   (may be hot-plugged later)
> > > + - QEMU command line is stored in
> > > +   /vm//image/dmargs xenstore dir, each argument as 
> > > separate key
> > > +   in form /vm//image/dmargs/NNN, where NNN is 0-padded 
> > > argument
> > > +   number
> > > + - target domain id is stored in /local/domain//target 
> > > xenstore path
> > > +?? - bios type is stored in /local/domain//hvmloader/bios
> > 
> > Since you're defining a new protocol here, you have the liberty to
> > eliminate this uncertainty, unless for some reason you want it to be
> > compatible with the old stubdom?
> 
> I'm not sure who access this xenstore key, since I haven't found how is
> it used in minios based stubdomain. Is it used by qemu?

It is read by hvmloader afaict.

Wei.

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

Re: [Xen-devel] Are xen.git/tools/pkg-config/*.pc used anywere/working ?

[Wei Liu]

On Thu, Feb 21, 2019 at 06:16:43PM +0100, Juergen Gross wrote:
> On 21/02/2019 18:11, Juergen Gross wrote:
> > On 21/02/2019 17:12, Wei Liu wrote:
> >> On Mon, Jan 21, 2019 at 06:28:34PM +, Anthony PERARD wrote:
> >>> Hi,
> >>>
> >>> I've been trying to use the pkg-config files generated in
> >>> tools/pkg-config/ when building QEMU, but those files only contains
> >>> "-Wl,-rpath-link" and "-l" options. At link times, the linker just
> >>> doesn't find the *.so.
> >>>
> >>> Are those *.pc actually used anywhere, and working for someone? QEMU
> >>> certainly can't use them. (The one that end-up been installed on the
> >>> system works fine.)
> >>>
> >>> I think that the file generated in tools/pkg-config/*.pc should also
> >>> have the -L options. To me, -rpath-link is only useful for the
> >>> dependency of a .so (e.g. xencall been linked against xentoollog, but
> >>> qemu doesn't need to link against it).
> >>
> >> Good point.
> >>
> >> Juergen? Presumably you had those files working when you wrote those
> >> patches?
> > 
> > I think they did.
> > 
> > Maybe I was fooled somehow? But AFAIR I did some iterations until they
> > worked for me.
> 
> Oh, I have just found an old patch lying around adding the "-L" option
> to the local pkg-config files, as qemu needs those for building... :-)
> 
> I'll post it.

Nice. :-)

Wei.

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

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

Re: [Xen-devel] Are xen.git/tools/pkg-config/*.pc used anywere/working ?

[Juergen Gross]

On 21/02/2019 18:11, Juergen Gross wrote:
> On 21/02/2019 17:12, Wei Liu wrote:
>> On Mon, Jan 21, 2019 at 06:28:34PM +, Anthony PERARD wrote:
>>> Hi,
>>>
>>> I've been trying to use the pkg-config files generated in
>>> tools/pkg-config/ when building QEMU, but those files only contains
>>> "-Wl,-rpath-link" and "-l" options. At link times, the linker just
>>> doesn't find the *.so.
>>>
>>> Are those *.pc actually used anywhere, and working for someone? QEMU
>>> certainly can't use them. (The one that end-up been installed on the
>>> system works fine.)
>>>
>>> I think that the file generated in tools/pkg-config/*.pc should also
>>> have the -L options. To me, -rpath-link is only useful for the
>>> dependency of a .so (e.g. xencall been linked against xentoollog, but
>>> qemu doesn't need to link against it).
>>
>> Good point.
>>
>> Juergen? Presumably you had those files working when you wrote those
>> patches?
> 
> I think they did.
> 
> Maybe I was fooled somehow? But AFAIR I did some iterations until they
> worked for me.

Oh, I have just found an old patch lying around adding the "-L" option
to the local pkg-config files, as qemu needs those for building... :-)

I'll post it.


Juergen


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

[Xen-devel] [linux-next test] 133322: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 test-amd64-i386-xl-qemuu-win10-i386 broken
 test-amd64-i386-libvirt  broken
 test-amd64-i386-xl-qemuu-win7-amd64 broken
 test-amd64-amd64-xl-qemuu-win10-i386 broken
 test-amd64-i386-xl-qemut-ws16-amd64 broken
 test-amd64-i386-xl-qemut-ws16-amd64  4 host-install(4) broken REGR. vs. 133293
 test-amd64-i386-xl-qemuu-win10-i386  4 host-install(4) broken REGR. vs. 133293
 test-amd64-i386-examine   5 host-install   broken REGR. vs. 133293
 test-amd64-i386-libvirt   4 host-install(4)broken REGR. vs. 133293
 test-amd64-amd64-xl-qemuu-win10-i386 4 host-install(4) broken REGR. vs. 133293
 test-amd64-i386-xl-qemuu-win7-amd64  4 host-install(4) broken REGR. vs. 133293
 build-armhf-pvops 4 host-install(4)broken REGR. vs. 133293
 build-arm64-pvops 6 kernel-build fail REGR. vs. 133293
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
133293
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 133293
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 133293
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
133293
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 133293
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
133293
 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 133293
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
133293
 test-amd64-amd64-amd64-pvgrub 10 debian-di-install   fail REGR. vs. 133293

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail like 133293
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133293
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133293
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133293
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 
133293
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133293
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 133293
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 133293
 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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   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-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxabf446c9040509ae91c1929c7b80289056cebda2
baseline version:
 linuxa3b22b9f11d9fbc48b0291ea92259a5a810e9438

Last test of basis  

Re: [Xen-devel] [PATCH 3/4] x86/vmx: Fix security issue when a guest balloons out the #VE info page

[Andrew Cooper]

On 20/02/2019 14:37, Jan Beulich wrote:
 On 19.02.19 at 23:18,  wrote:
>> @@ -58,25 +57,67 @@ altp2m_vcpu_destroy(struct vcpu *v)
>>  
>>  int altp2m_vcpu_enable_ve(struct vcpu *v, gfn_t gfn)
>>  {
>> +struct domain *d = v->domain;
>> +struct altp2mvcpu *a = _altp2m(v);
>>  p2m_type_t p2mt;
>> +mfn_t mfn;
>> +struct page_info *pg;
>> +int rc;
>> +
>> +/* Early exit path if #VE is already configured. */
>> +if ( a->veinfo_pg )
>> +return -EEXIST;
>> +
>> +mfn = get_gfn(d, gfn_x(gfn), );
>> +
>> +/*
>> + * Looking for a plain piece of guest writeable RAM.  Take an extra page
>> + * reference to reflect our intent to point the VMCS at it.
>> + */
>> +if ( mfn_eq(mfn, INVALID_MFN) || !p2m_is_ram(p2mt) ||
>> + p2m_is_readonly(p2mt) || !get_page(pg = mfn_to_page(mfn), d) )
> p2m_is_ram() is pretty broad a class, and p2m_is_readonly() removes
> only usefully p2m_ram_ro and p2m_ram_shared from the set. In
> particular p2m_ioreq_server is thus permitted, as are all p2m_paging_*
> which don't produce INVALID_MFN. I don't think that's what you want.
> I also don't think you really want to exclude p2m_ram_logdirty - if
> anything you might need to convert that type to p2m_ram_rw in case
> you find the page in that state.

Flipping logdirty back to ram cannot reasonably be a caller requirement,
but you are right that logdirty pages ought to be eligible.  Holding
extra references doesn't interact with logdirty operations.

> Can't you simply call check_get_page_from_gfn() here anyway?
>
> Furthermore I'm uncertain if get_page() is quite enough: Don't you
> also want a writable type reference? It may not strictly be needed at
> this point, but I think we're trying to make the distinction in new code,
> like was e.g. done in recent Viridian changes.

No - I don't want to take a writeable reference.

Not because it is necessarily the wrong thing to do longterm, but
because it is not the current behaviour, and is therefore substantially
more risky in terms of subtle unexpected side effects (especially for
4.12 at this point).

We have years and years of XSAs demonstrating that things tend to go
wrong.  It is irresponsible to start introducing a new reference
counting scheme without doing the work to first justify the safety of
change, and have a reasonable demonstration that the result is safe,
e.g. with an IOMMU in the mix.

~Andrew

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

Re: [Xen-devel] Are xen.git/tools/pkg-config/*.pc used anywere/working ?

[Juergen Gross]

On 21/02/2019 17:12, Wei Liu wrote:
> On Mon, Jan 21, 2019 at 06:28:34PM +, Anthony PERARD wrote:
>> Hi,
>>
>> I've been trying to use the pkg-config files generated in
>> tools/pkg-config/ when building QEMU, but those files only contains
>> "-Wl,-rpath-link" and "-l" options. At link times, the linker just
>> doesn't find the *.so.
>>
>> Are those *.pc actually used anywhere, and working for someone? QEMU
>> certainly can't use them. (The one that end-up been installed on the
>> system works fine.)
>>
>> I think that the file generated in tools/pkg-config/*.pc should also
>> have the -L options. To me, -rpath-link is only useful for the
>> dependency of a .so (e.g. xencall been linked against xentoollog, but
>> qemu doesn't need to link against it).
> 
> Good point.
> 
> Juergen? Presumably you had those files working when you wrote those
> patches?

I think they did.

Maybe I was fooled somehow? But AFAIR I did some iterations until they
worked for me.


Juergen

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

Re: [Xen-devel] [PATCH v3 04/17] libxl: Allow running qemu-xen in stubdomain

[Marek Marczykowski-Górecki]

On Thu, Feb 21, 2019 at 04:01:59PM +, Wei Liu wrote:
> On Mon, Jan 28, 2019 at 10:30:21PM +0100, Marek Marczykowski-Górecki wrote:
> > Do not prohibit anymore using stubdomain with qemu-xen.
> > To help distingushing MiniOS and Linux stubdomain, add helper inline
> > functions libxl__stubdomain_is_linux() and
> > libxl__stubdomain_is_linux_running(). Those should be used where really
> > the difference is about MiniOS/Linux, not qemu-xen/qemu-xen-traditional.
> > 
> > Signed-off-by: Marek Marczykowski-Górecki 
> > 
> > ---
> > Changes in v3:
> >  - new patch, instead of "libxl: Add "stubdomain_version" to
> >  domain_build_info"
> >  - helper functions as suggested by Ian Jackson
> > ---
> >  tools/libxl/libxl_create.c   |  9 -
> >  tools/libxl/libxl_internal.h | 17 +
> >  2 files changed, 17 insertions(+), 9 deletions(-)
> > 
(...)
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index 459f9bf..b8c698a 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -2195,6 +2195,23 @@ _hidden int 
> > libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
> >/* Return the system-wide default device model */
> >  _hidden libxl_device_model_version libxl__default_device_model(libxl__gc 
> > *gc);
> >  
> > +static inline
> > +bool libxl__stubdomain_is_linux_running(libxl__gc *gc, uint32_t domid)
> > +{
> > +/* same logic as in libxl__stubdomain_is_linux */
> > +return libxl__device_model_version_running(gc, domid)
> > +== LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
> 
> I don't think the logic is accurate. You're precluding running
> qemu-xen in a unikernel as stubdom.
> 
> I think putting an extra key in xenstore with the underlying platform is
> more desirable.
> 
> > +}
> > +
> > +static inline
> > +bool libxl__stubdomain_is_linux(libxl_domain_build_info *b_info)
> > +{
> > +/* right now qemu-tranditional implies MiniOS stubdomain and qemu-xen
> > + * implies Linux stubdomain */
> > +return libxl_defbool_val(b_info->device_model_stubdomain) &&
> > +b_info->device_model_version == 
> > LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
> 
> Subsequently you will need a new field in b_info.
> 
> What do you think?

This is _exactly_ what was in v2 of this patch and Ian suggested to
change it:
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01317.html

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] [PATCH v3 02/17] Document ioemu Linux stubdomain protocol

[Marek Marczykowski-Górecki]

On Thu, Feb 21, 2019 at 03:39:25PM +, Wei Liu wrote:
> On Mon, Jan 28, 2019 at 10:30:19PM +0100, Marek Marczykowski-Górecki wrote:
> > Add documentation for upcoming Linux stubdomain for qemu-upstream.
> > 
> > Signed-off-by: Marek Marczykowski-Górecki 
> > ---
> >  docs/misc/stubdom.txt | 50 -
> >  1 file changed, 50 insertions(+)
> > 
> > diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
> > index 4c524f2..9c94c6b 100644
> > --- a/docs/misc/stubdom.txt
> > +++ b/docs/misc/stubdom.txt
> > @@ -75,6 +75,56 @@ Defined commands:
> > - "running" - success
> >  
> >  
> > +Toolstack to Linux ioemu stubdomain protocol
> > +
> > +
> > +This section describe communication protocol between toolstack and
> > +qemu-upstream running in Linux stubdomain. The protocol include
> > +expectations of both stubdomain, and qemu.
> > +
> > +Setup (done by toolstack, expected by stubdomain):
> > + - Block devices for target domain are connected as PV disks to stubdomain,
> > +   according to configuration order, starting with xvda
> > + - Network devices for target domain are connected as PV nics to 
> > stubdomain,
> > +   according to configuration order, starting with 0
> > + - [not implemented] if graphics output is expected, VFB and VKB devices 
> > are set for stubdomain
> > +   (its backend is responsible for exposing them using appropriate protocol
> > +   like VNC or Spice)
> > + - other target domain's devices are not connected at this point to 
> > stubdomain
> > +   (may be hot-plugged later)
> > + - QEMU command line is stored in
> > +   /vm//image/dmargs xenstore dir, each argument as separate 
> > key
> > +   in form /vm//image/dmargs/NNN, where NNN is 0-padded 
> > argument
> > +   number
> > + - target domain id is stored in /local/domain//target 
> > xenstore path
> > +?? - bios type is stored in /local/domain//hvmloader/bios
> 
> Since you're defining a new protocol here, you have the liberty to
> eliminate this uncertainty, unless for some reason you want it to be
> compatible with the old stubdom?

I'm not sure who access this xenstore key, since I haven't found how is
it used in minios based stubdomain. Is it used by qemu?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] [PATCH v5 4/5] x86/mm: handle foreign mappings in p2m_entry_modify

[Wei Liu]

On Thu, Feb 21, 2019 at 05:50:40PM +0100, Roger Pau Monne wrote:
>  
>  static void ept_p2m_type_to_flags(struct p2m_domain *p2m, ept_entry_t *entry,
> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> index 254c5dfd19..7f94fdb6a3 100644
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -184,7 +184,7 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
>  l1_pgentry_t *p2m_entry, new_entry;
>  void *next;
>  unsigned int flags;
> -int rc;
> +int rc = 0;

Oh here it is. It should be moved to previous patch.

Wei.

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

Re: [Xen-devel] [PATCH v4.1 4/6] xen/x86: Allow stubdom access to irq created for msi.

[Roger Pau Monné]

On Fri, Feb 08, 2019 at 11:17:05AM +0100, Marek Marczykowski-Górecki wrote:
> Stubdomains need to be given sufficient privilege over the guest which it
> provides emulation for in order for PCI passthrough to work correctly.
> When a HVM domain try to enable MSI, QEMU in stubdomain calls
> PHYSDEVOP_map_pirq, but later it needs to call XEN_DOMCTL_bind_pt_irq as
> part of xc_domain_update_msi_irq. Allow for that as part of
> PHYSDEVOP_map_pirq.
> 
> This is not needed for PCI INTx, because IRQ in that case is known
> beforehand and the stubdomain is given permissions over this IRQ by
> libxl__device_pci_add (there's a do_pci_add against the stubdomain).
> 
> create_irq() already grant IRQ access to hardware_domain, with
> assumption the device model (something managing this IRQ) lives there.
> Modify create_irq() to take additional parameter pointing at device
> model domain - which may be dom0 or stubdomain. Do the same with
> destroy_irq() (and msi_free_irq() which calls it) to reverse the
> operation.
> 
> Then, adjust all callers to provide the parameter. In case of calls not
> related to stubdomain-initiated allocations, give it hardware_domain, so
> the behavior is unchanged there.
> 
> Inspired by 
> https://github.com/OpenXT/xenclient-oe/blob/5e0e7304a5a3c75ef01240a1e3673665b2aaf05e/recipes-extended/xen/files/stubdomain-msi-irq-access.patch
>  by Eric Chanudet .
> 
> Signed-off-by: Simon Gaiser 
> Signed-off-by: Marek Marczykowski-Górecki 

Thanks for working on this! I've got some comments below.

> ---
> Changes in v3:
>  - extend commit message
> Changes in v4:
>  - add missing destroy_irq on error path
> Changes in v4.1:
>  - move irq_{grant,revoke}_access() to {create,destroy}_irq(), which
>basically make it a different patch
> 
> There is one code path where I haven't managed to properly extract
> possible stubdomain in use:
> pci_remove_device()
>  -> pci_cleanup_msi()
>-> msi_free_irqs()
>  -> msi_free_irq()
>-> destroy_irq()
> 
> For now I've hardcoded hardware_domain there (in msi_free_irqs). Can it happen
> when device is still assigned to some domU?
> ---
>  xen/arch/x86/hpet.c  |  5 +--
>  xen/arch/x86/irq.c   | 46 ++--
>  xen/arch/x86/msi.c   |  6 ++--
>  xen/drivers/char/ns16550.c   |  6 ++--
>  xen/drivers/passthrough/amd/iommu_init.c |  4 +--
>  xen/drivers/passthrough/vtd/iommu.c  |  7 ++--
>  xen/include/asm-x86/irq.h|  4 +--
>  xen/include/asm-x86/msi.h|  2 +-
>  8 files changed, 46 insertions(+), 34 deletions(-)
> 
> diff --git a/xen/arch/x86/hpet.c b/xen/arch/x86/hpet.c
> index 4b08488ef1..6db71dfd71 100644
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -368,13 +369,13 @@ static int __init hpet_assign_irq(struct 
> hpet_event_channel *ch)
>  {
>  int irq;
>  
> -if ( (irq = create_irq(NUMA_NO_NODE)) < 0 )
> +if ( (irq = create_irq(NUMA_NO_NODE, hardware_domain)) < 0 )
>  return irq;
>  
>  ch->msi.irq = irq;
>  if ( hpet_setup_msi_irq(ch) )
>  {
> -destroy_irq(irq);
> +destroy_irq(irq, hardware_domain);

Hm, here you should use an explicit NULL instead of hardware_domain
(which will also be NULL by the time this gets called). This irq is
used by Xen, and it doesn't make sense logically to give permissions
over it to the hardware domain.

>  return -EINVAL;
>  }
>  
> diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
> index 8b44d6ce0b..d41b32b2f4 100644
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -157,7 +157,7 @@ int __init bind_irq_vector(int irq, int vector, const 
> cpumask_t *cpu_mask)
>  /*
>   * Dynamic irq allocate and deallocation for MSI
>   */
> -int create_irq(nodeid_t node)
> +int create_irq(nodeid_t node, struct domain *dm_domain)

Using plain 'd' would be fine for me here, same below for
destroy_irq.

>  {
>  int irq, ret;
>  struct irq_desc *desc;
> @@ -190,19 +190,19 @@ int create_irq(nodeid_t node)
>  desc->arch.used = IRQ_UNUSED;
>  irq = ret;
>  }
> -else if ( hardware_domain )
> +else if ( dm_domain )

Can you guarantee that dm_domain is always current->domain?

I think you need to assert for this, or else take a reference to
dm_domain (get_domain) before accessing it's fields, or else you risk
the domain being destroyed while modifying it's fields.

>  {
> -ret = irq_permit_access(hardware_domain, irq);
> +ret = irq_permit_access(dm_domain, irq);
>  if ( ret )
>  printk(XENLOG_G_ERR
> -   "Could not grant Dom0 access to IRQ%d (error %d)\n",
> -   irq, ret);
> +   "Could not grant Dom%u access to IRQ%d (error %d)\n",
> +   dm_domain->domain_id, irq, ret);
>  }
>  
>  

Re: [Xen-devel] [PATCH v5 3/5] p2m: change write_p2m_entry to return an error code

[Wei Liu]

On Thu, Feb 21, 2019 at 05:50:39PM +0100, Roger Pau Monne wrote:
[...]
> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> index 04e9d81cf6..254c5dfd19 100644
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -184,6 +184,8 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
>  l1_pgentry_t *p2m_entry, new_entry;
>  void *next;
>  unsigned int flags;
> +int rc;

Shouldn't rc be initialised to 0 here? There seems to be a path which
can leave rc uninitialised without calling write_p2m_entry.

Wei.

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

Re: [Xen-devel] [PATCH v5 1/5] x86/p2m: pass the p2m to write_p2m_entry handlers

[Wei Liu]

On Thu, Feb 21, 2019 at 05:50:37PM +0100, Roger Pau Monne wrote:
> Current callers pass the p2m to paging_write_p2m_entry, but the
> implementation specific handlers of the write_p2m_entry hook instead
> of a p2m get a domain struct due to the handling done in
> paging_write_p2m_entry.
> 
> Change the code so that the implementations of write_p2m_entry take a
> p2m instead of a domain.
> 
> This is a non-functional change, but will be used by follow up
> patches.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Wei Liu 

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

[Xen-devel] [PATCH v5 5/5] npt/shadow: allow getting foreign page table entries

[Roger Pau Monne]

Current npt and shadow code to get an entry will always return
INVALID_MFN for foreign entries. Allow to return the entry mfn for
foreign entries, like it's done for grant table entries.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
---
Changes since v2:
 - Use p2m_is_any_ram.
---
 xen/arch/x86/mm/p2m-pt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 7f94fdb6a3..bbc9a3e278 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -907,8 +907,8 @@ pod_retry_l1:
 *t = p2m_recalc_type(recalc || _needs_recalc(flags), l1t, p2m, gfn);
 unmap_domain_page(l1e);
 
-ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t) || p2m_is_paging(*t));
-return (p2m_is_valid(*t) || p2m_is_grant(*t)) ? mfn : INVALID_MFN;
+ASSERT(mfn_valid(mfn) || !p2m_is_any_ram(*t) || p2m_is_paging(*t));
+return (p2m_is_valid(*t) || p2m_is_any_ram(*t)) ? mfn : INVALID_MFN;
 }
 
 static void p2m_pt_change_entry_type_global(struct p2m_domain *p2m,
-- 
2.17.2 (Apple Git-113)


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

[Xen-devel] [PATCH v5 3/5] p2m: change write_p2m_entry to return an error code

[Roger Pau Monne]

This is in preparation for also changing p2m_entry_modify to return an
error code.

No functional change intended.

Signed-off-by: Roger Pau Monné 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Tim Deegan 
---
Changes since v4:
 - Handle errors in loops to avoid overwriting the variable
   containing the error code in non-debug builds.
 - Change error handling in p2m_next_level so it's done in a single
   place.

Changes since v3:
 - Use asserts instead of bugs to check return code from
   write_p2m_entry from callers that don't support or expect
   write_p2m_entry to fail.

Changes since v2:
 - New in this version.
---
 xen/arch/x86/mm/hap/hap.c|  4 +-
 xen/arch/x86/mm/hap/nested_hap.c |  4 +-
 xen/arch/x86/mm/p2m-pt.c | 83 ++--
 xen/arch/x86/mm/paging.c | 12 +++--
 xen/arch/x86/mm/shadow/common.c  |  4 +-
 xen/arch/x86/mm/shadow/none.c|  7 +--
 xen/arch/x86/mm/shadow/private.h |  6 +--
 xen/include/asm-x86/p2m.h|  4 +-
 xen/include/asm-x86/paging.h |  8 +--
 9 files changed, 97 insertions(+), 35 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 2db7f2c04a..fdf77c59a5 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -708,7 +708,7 @@ static void hap_update_paging_modes(struct vcpu *v)
 put_gfn(d, cr3_gfn);
 }
 
-static void
+static int
 hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
 l1_pgentry_t new, unsigned int level)
 {
@@ -746,6 +746,8 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long 
gfn, l1_pgentry_t *p,
 
 if ( flush_nestedp2m )
 p2m_flush_nestedp2m(d);
+
+return 0;
 }
 
 static unsigned long hap_gva_to_gfn_real_mode(
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index d2a07a5c79..abe5958a52 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -71,7 +71,7 @@
 /*NESTED VIRT P2M FUNCTIONS */
 //
 
-void
+int
 nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
 l1_pgentry_t *p, l1_pgentry_t new, unsigned int level)
 {
@@ -87,6 +87,8 @@ nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned 
long gfn,
 flush_tlb_mask(p2m->dirty_cpumask);
 
 paging_unlock(d);
+
+return 0;
 }
 
 //
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 04e9d81cf6..254c5dfd19 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -184,6 +184,8 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
 l1_pgentry_t *p2m_entry, new_entry;
 void *next;
 unsigned int flags;
+int rc;
+mfn_t mfn = INVALID_MFN;
 
 if ( !(p2m_entry = p2m_find_entry(*table, gfn_remainder, gfn,
   shift, max)) )
@@ -194,7 +196,7 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
 /* PoD/paging: Not present doesn't imply empty. */
 if ( !flags )
 {
-mfn_t mfn = p2m_alloc_ptp(p2m, level);
+mfn = p2m_alloc_ptp(p2m, level);
 
 if ( mfn_eq(mfn, INVALID_MFN) )
 return -ENOMEM;
@@ -202,13 +204,14 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
 new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
 
 p2m_add_iommu_flags(_entry, level, 
IOMMUF_readable|IOMMUF_writable);
-p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
+rc = p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
+if ( rc )
+ASSERT_UNREACHABLE();
 }
 else if ( flags & _PAGE_PSE )
 {
 /* Split superpages pages into smaller ones. */
 unsigned long pfn = l1e_get_pfn(*p2m_entry);
-mfn_t mfn;
 l1_pgentry_t *l1_entry;
 unsigned int i;
 
@@ -250,18 +253,37 @@ p2m_next_level(struct p2m_domain *p2m, void **table,
 {
 new_entry = l1e_from_pfn(pfn | (i << ((level - 1) * 
PAGETABLE_ORDER)),
  flags);
-p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, level);
+rc = p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, 
level);
+if ( rc )
+{
+ASSERT_UNREACHABLE();
+break;
+}
 }
 
 unmap_domain_page(l1_entry);
 
-new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
-p2m_add_iommu_flags(_entry, level, 
IOMMUF_readable|IOMMUF_writable);
-p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
+if ( !rc )
+{
+new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
+p2m_add_iommu_flags(_entry, level,
+IOMMUF_readable|IOMMUF_writable);
+rc = p2m->write_p2m_entry(p2m, gfn, p2m_entry, 

[Xen-devel] [PATCH v5 1/5] x86/p2m: pass the p2m to write_p2m_entry handlers

[Roger Pau Monne]

Current callers pass the p2m to paging_write_p2m_entry, but the
implementation specific handlers of the write_p2m_entry hook instead
of a p2m get a domain struct due to the handling done in
paging_write_p2m_entry.

Change the code so that the implementations of write_p2m_entry take a
p2m instead of a domain.

This is a non-functional change, but will be used by follow up
patches.

Signed-off-by: Roger Pau Monné 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Tim Deegan 
---
Changes since v4:
 - New in this version.
---
 xen/arch/x86/mm/hap/hap.c| 3 ++-
 xen/arch/x86/mm/paging.c | 2 +-
 xen/arch/x86/mm/shadow/common.c  | 4 +++-
 xen/arch/x86/mm/shadow/none.c| 2 +-
 xen/arch/x86/mm/shadow/private.h | 2 +-
 xen/include/asm-x86/paging.h | 3 ++-
 6 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3d651b94c3..28fe48d158 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -709,9 +709,10 @@ static void hap_update_paging_modes(struct vcpu *v)
 }
 
 static void
-hap_write_p2m_entry(struct domain *d, unsigned long gfn, l1_pgentry_t *p,
+hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
 l1_pgentry_t new, unsigned int level)
 {
+struct domain *d = p2m->domain;
 uint32_t old_flags;
 bool_t flush_nestedp2m = 0;
 
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index d5836eb688..e6ed3006fe 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -941,7 +941,7 @@ void paging_write_p2m_entry(struct p2m_domain *p2m, 
unsigned long gfn,
 if ( v->domain != d )
 v = d->vcpu ? d->vcpu[0] : NULL;
 if ( likely(v && paging_mode_enabled(d) && paging_get_hostmode(v) != NULL) 
)
-paging_get_hostmode(v)->write_p2m_entry(d, gfn, p, new, level);
+paging_get_hostmode(v)->write_p2m_entry(p2m, gfn, p, new, level);
 else
 safe_write_pte(p, new);
 }
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 07840ff727..6c67ef4996 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3177,10 +3177,12 @@ static void sh_unshadow_for_p2m_change(struct domain 
*d, unsigned long gfn,
 }
 
 void
-shadow_write_p2m_entry(struct domain *d, unsigned long gfn,
+shadow_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
l1_pgentry_t *p, l1_pgentry_t new,
unsigned int level)
 {
+struct domain *d = p2m->domain;
+
 paging_lock(d);
 
 /* If there are any shadows, update them.  But if shadow_teardown()
diff --git a/xen/arch/x86/mm/shadow/none.c b/xen/arch/x86/mm/shadow/none.c
index 4de645a433..316002771d 100644
--- a/xen/arch/x86/mm/shadow/none.c
+++ b/xen/arch/x86/mm/shadow/none.c
@@ -60,7 +60,7 @@ static void _update_paging_modes(struct vcpu *v)
 ASSERT_UNREACHABLE();
 }
 
-static void _write_p2m_entry(struct domain *d, unsigned long gfn,
+static void _write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
  l1_pgentry_t *p, l1_pgentry_t new,
  unsigned int level)
 {
diff --git a/xen/arch/x86/mm/shadow/private.h b/xen/arch/x86/mm/shadow/private.h
index e8ed7ac714..0aaed1edfc 100644
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -372,7 +372,7 @@ extern int sh_remove_write_access(struct domain *d, mfn_t 
readonly_mfn,
   unsigned long fault_addr);
 
 /* Functions that atomically write PT/P2M entries and update state */
-void shadow_write_p2m_entry(struct domain *d, unsigned long gfn,
+void shadow_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
 l1_pgentry_t *p, l1_pgentry_t new,
 unsigned int level);
 
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index fdcc22844b..7ec09d7b11 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -124,7 +124,8 @@ struct paging_mode {
 void  (*update_cr3)(struct vcpu *v, int do_locking,
 bool noflush);
 void  (*update_paging_modes   )(struct vcpu *v);
-void  (*write_p2m_entry   )(struct domain *d, unsigned long 
gfn,
+void  (*write_p2m_entry   )(struct p2m_domain *p2m,
+unsigned long gfn,
 l1_pgentry_t *p, l1_pgentry_t new,
 unsigned int level);
 
-- 
2.17.2 (Apple Git-113)


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

[Xen-devel] [PATCH v5 2/5] x86/mm: split p2m ioreq server pages special handling into helper

[Roger Pau Monne]

So that it can be shared by both ept, npt and shadow code, instead of
duplicating it.

No change in functionality intended.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Paul Durrant 
Reviewed-by: George Dunlap 
Reviewed-by: Kevin Tian 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Paul Durrant 
Cc: Tim Deegan 
---
Changes since v4:
 - Remove the p2m_get_hostp2m from callers of p2m_entry_modify.

Changes since v1:
 - Remove unused p2mt_old from p2m_pt_set_entry.
---
 xen/arch/x86/mm/hap/hap.c   |  3 ++
 xen/arch/x86/mm/p2m-ept.c   | 55 +++--
 xen/arch/x86/mm/p2m-pt.c| 24 --
 xen/arch/x86/mm/shadow/common.c |  3 ++
 xen/include/asm-x86/p2m.h   | 32 +++
 5 files changed, 56 insertions(+), 61 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 28fe48d158..2db7f2c04a 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -735,6 +735,9 @@ hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long 
gfn, l1_pgentry_t *p,
 && perms_strictly_increased(old_flags, l1e_get_flags(new)) );
 }
 
+p2m_entry_modify(p2m, p2m_flags_to_type(l1e_get_flags(new)),
+ p2m_flags_to_type(old_flags), level);
+
 safe_write_pte(p, new);
 if ( old_flags & _PAGE_PRESENT )
 flush_tlb_mask(d->dirty_cpumask);
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index bb562607f7..0ece6608cb 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -46,7 +46,8 @@ static inline bool_t is_epte_valid(ept_entry_t *e)
 }
 
 /* returns : 0 for success, -errno otherwise */
-static int atomic_write_ept_entry(ept_entry_t *entryptr, ept_entry_t new,
+static int atomic_write_ept_entry(struct p2m_domain *p2m,
+  ept_entry_t *entryptr, ept_entry_t new,
   int level)
 {
 int rc;
@@ -89,6 +90,8 @@ static int atomic_write_ept_entry(ept_entry_t *entryptr, 
ept_entry_t new,
 if ( unlikely(p2m_is_foreign(entryptr->sa_p2mt)) && check_foreign )
 oldmfn = entryptr->mfn;
 
+p2m_entry_modify(p2m, new.sa_p2mt, entryptr->sa_p2mt, level);
+
 write_atomic(>epte, new.epte);
 
 if ( unlikely(oldmfn != mfn_x(INVALID_MFN)) )
@@ -390,7 +393,8 @@ static int ept_next_level(struct p2m_domain *p2m, bool_t 
read_only,
  * present entries in the given page table, optionally marking the entries
  * also for their subtrees needing P2M type re-calculation.
  */
-static bool_t ept_invalidate_emt(mfn_t mfn, bool_t recalc, int level)
+static bool_t ept_invalidate_emt(struct p2m_domain *p2m, mfn_t mfn,
+ bool_t recalc, int level)
 {
 int rc;
 ept_entry_t *epte = map_domain_page(mfn);
@@ -408,7 +412,7 @@ static bool_t ept_invalidate_emt(mfn_t mfn, bool_t recalc, 
int level)
 e.emt = MTRR_NUM_TYPES;
 if ( recalc )
 e.recalc = 1;
-rc = atomic_write_ept_entry([i], e, level);
+rc = atomic_write_ept_entry(p2m, [i], e, level);
 ASSERT(rc == 0);
 changed = 1;
 }
@@ -459,7 +463,7 @@ static int ept_invalidate_emt_range(struct p2m_domain *p2m,
 rc = -ENOMEM;
 goto out;
 }
-wrc = atomic_write_ept_entry([index], split_ept_entry, i);
+wrc = atomic_write_ept_entry(p2m, [index], split_ept_entry, i);
 ASSERT(wrc == 0);
 
 for ( ; i > target; --i )
@@ -479,7 +483,7 @@ static int ept_invalidate_emt_range(struct p2m_domain *p2m,
 {
 e.emt = MTRR_NUM_TYPES;
 e.recalc = 1;
-wrc = atomic_write_ept_entry([index], e, target);
+wrc = atomic_write_ept_entry(p2m, [index], e, target);
 ASSERT(wrc == 0);
 rc = 1;
 }
@@ -549,17 +553,11 @@ static int resolve_misconfig(struct p2m_domain *p2m, 
unsigned long gfn)
 nt = p2m_recalc_type(e.recalc, e.sa_p2mt, p2m, gfn + i);
 if ( nt != e.sa_p2mt )
 {
-if ( e.sa_p2mt == p2m_ioreq_server )
-{
-ASSERT(p2m->ioreq.entry_count > 0);
-p2m->ioreq.entry_count--;
-}
-
 e.sa_p2mt = nt;
 ept_p2m_type_to_flags(p2m, , e.sa_p2mt, e.access);
 }
 e.recalc = 0;
-wrc = atomic_write_ept_entry([i], e, level);
+wrc = atomic_write_ept_entry(p2m, [i], e, level);
 ASSERT(wrc == 0);
 }
 }
@@ -595,7 +593,7 @@ static int resolve_misconfig(struct p2m_domain *p2m, 
unsigned long gfn)
 {
 if ( ept_split_super_page(p2m, , level, level - 1) )
 {
-wrc = 

[Xen-devel] [PATCH v5 0/5] pvh/dom0/shadow/amd fixes

[Roger Pau Monne]

The remaining set of patches contain changes to the p2m code that could
affect HVM guests. Note that without those changes a PVH dom0 running on
AMD hardware will be unable to create guests. Overall the patches are a
nice cleanup to the handling of p2m_ioreq_server and p2m_map_foreign
types IMO.

The series can also be found at:

git://xenbits.xen.org/people/royger/xen.git fixes-v5

Thanks, Roger.

Roger Pau Monne (5):
  x86/p2m: pass the p2m to write_p2m_entry handlers
  x86/mm: split p2m ioreq server pages special handling into helper
  p2m: change write_p2m_entry to return an error code
  x86/mm: handle foreign mappings in p2m_entry_modify
  npt/shadow: allow getting foreign page table entries

 xen/arch/x86/mm/hap/hap.c|  17 -
 xen/arch/x86/mm/hap/nested_hap.c |   4 +-
 xen/arch/x86/mm/p2m-ept.c| 106 ++-
 xen/arch/x86/mm/p2m-pt.c | 118 ++-
 xen/arch/x86/mm/paging.c |  12 ++--
 xen/arch/x86/mm/shadow/common.c  |  18 -
 xen/arch/x86/mm/shadow/none.c|   7 +-
 xen/arch/x86/mm/shadow/private.h |   6 +-
 xen/include/asm-x86/p2m.h|  62 +++-
 xen/include/asm-x86/paging.h |   9 +--
 10 files changed, 204 insertions(+), 155 deletions(-)

-- 
2.17.2 (Apple Git-113)


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

Re: [Xen-devel] [PATCH v2 00/14] Add support for Hygon Dhyana Family 18h processor

[Wei Liu]

I think the version should have been v5?

Wei.

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

Re: [Xen-devel] [PATCH v2] vm_event: Add a new opcode to get VM_EVENT_INTERFACE_VERSION

[Wei Liu]

On Thu, Feb 14, 2019 at 04:18:11PM +0200, Petre Pircalabu wrote:
> Currently, the VM_EVENT_INTERFACE_VERSION is determined at runtime, by
> inspecting the corresponding field in a vm_event_request. This helper
> opcode will query the hypervisor supported version before the vm_event
> related structures and layout are set-up.
> 
> Signed-off-by: Petre Pircalabu 

Acked-by: Wei Liu 


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

Re: [Xen-devel] [PATCH v4 3/6] libxl: don't try to manipulate json config for stubdomain

[Wei Liu]

On Thu, Feb 07, 2019 at 01:07:46AM +0100, Marek Marczykowski-Górecki wrote:
> Stubdomain do not have it's own config file - its configuration is
> derived from target domains. Do not try to manipulate it when attaching
> PCI device.
> 
> This bug prevented starting HVM with stubdomain and PCI passthrough
> device attached.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Wei Liu 

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

Re: [Xen-devel] Are xen.git/tools/pkg-config/*.pc used anywere/working ?

[Wei Liu]

On Mon, Jan 21, 2019 at 06:28:34PM +, Anthony PERARD wrote:
> Hi,
> 
> I've been trying to use the pkg-config files generated in
> tools/pkg-config/ when building QEMU, but those files only contains
> "-Wl,-rpath-link" and "-l" options. At link times, the linker just
> doesn't find the *.so.
> 
> Are those *.pc actually used anywhere, and working for someone? QEMU
> certainly can't use them. (The one that end-up been installed on the
> system works fine.)
> 
> I think that the file generated in tools/pkg-config/*.pc should also
> have the -L options. To me, -rpath-link is only useful for the
> dependency of a .so (e.g. xencall been linked against xentoollog, but
> qemu doesn't need to link against it).

Good point.

Juergen? Presumably you had those files working when you wrote those
patches?

Wei.

> 
> Cheers,
> 
> -- 
> Anthony PERARD

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

Re: [Xen-devel] [PATCH v3 15/17] tools: add missing libxenvchan cflags

[Wei Liu]

On Mon, Jan 28, 2019 at 10:30:32PM +0100, Marek Marczykowski-Górecki wrote:
> libxenvchan.h include xenevtchn.h and xengnttab.h, so applications built
> with it needs applicable -I in CFLAGS too.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 08/17] xl: add stubdomain related options to xl config parser

[Wei Liu]

On Mon, Jan 28, 2019 at 10:30:25PM +0100, Marek Marczykowski-Górecki wrote:
> Signed-off-by: Marek Marczykowski-Górecki 
> Reviewed-by: Jason Andryuk 
> ---
>  docs/man/xl.cfg.5.pod.in | 23 +++
>  tools/xl/xl_parse.c  |  7 +++
>  2 files changed, 26 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 3b92f39..f475196 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -2694,10 +2694,25 @@ model which they were installed with.
>  
>  =item B
>  
> -Override the path to the binary to be used as the device-model. The
> -binary provided here MUST be consistent with the
> -B which you have specified. You should not
> -normally need to specify this option.
> +Override the path to the binary to be used as the device-model running in
> +toolstack domain. The binary provided here MUST be consistent with the
> +B which you have specified. You should not normally 
> need
> +to specify this option.
> +
> +=item B
> +
> +Override the path to the kernel image used as device-model stubdomain.
> +The binary provided here MUST be consistent with the
> +B which you have specified.
> +In case of B it is expected to be MiniOS-based 
> stubdomain
> +image, in case of B it is expected to be Linux-based stubdomain
> +kernel.
> +
> +=item B
> +
> +Override the path to the ramdisk image used as device-model stubdomain.
> +The binary provided here is to be used by a kernel pointed by 
> B.
> +It is known to be used only by Linux-based stubdomain kernel.


Where is the documentation for stubdom_memory?

>  
>  =item B
>  
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 352cd21..77e4cf0 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -2502,6 +2502,13 @@ skip_usbdev:
>  xlu_cfg_replace_string(config, "device_model_user",
> _info->device_model_user, 0);
>  
> +xlu_cfg_replace_string (config, "stubdomain_kernel",
> +_info->stubdomain_kernel, 0);
> +xlu_cfg_replace_string (config, "stubdomain_ramdisk",
> +_info->stubdomain_ramdisk, 0);
> +if (!xlu_cfg_get_long (config, "stubdomain_memory", , 0))
> +b_info->stubdomain_memkb = l * 1024;
> +
>  #define parse_extra_args(type)\
>  e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
>  _info->extra##type, 0);\
> -- 
> git-series 0.9.1

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

Re: [Xen-devel] [PATCH v3 09/17] tools/libvchan: notify server when client is connected

[Wei Liu]

On Mon, Jan 28, 2019 at 10:30:26PM +0100, Marek Marczykowski-Górecki wrote:
> Let the server know when the client is connected. Otherwise server will
> notice only when client send some data.
> This change does not break existing clients, as libvchan user should
> handle spurious notifications anyway (for example acknowledge of remote
> side reading the data).
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
> I had this patch in Qubes for a long time and totally forgot it wasn't
> upstream thing...
> ---
>  tools/libvchan/init.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
> index 180833d..50a64c1 100644
> --- a/tools/libvchan/init.c
> +++ b/tools/libvchan/init.c
> @@ -447,6 +447,9 @@ struct libxenvchan *libxenvchan_client_init(struct 
> xentoollog_logger *logger,
>   ctrl->ring->cli_live = 1;
>   ctrl->ring->srv_notify = VCHAN_NOTIFY_WRITE;
>  
> +/* wake up the server */
> +xenevtchn_notify(ctrl->event, ctrl->event_port);
> +

Indentation is wrong. Fix it and:

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 11/17] libxl: move xswait declaration up in libxl_internal.h

[Wei Liu]

On Mon, Jan 28, 2019 at 10:30:28PM +0100, Marek Marczykowski-Górecki wrote:
> It will be needed for qmp_ev_* over vchan.
> 
> No functional change.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 07/17] libxl: create vkb device only for guests with graphics output

[Wei Liu]

On Mon, Jan 28, 2019 at 10:30:24PM +0100, Marek Marczykowski-Górecki wrote:
> The forced vkb device is meant for better performance of qemu access
> (at least according to ebbd2561b4cefb299f0f68a88b2788504223de18 "libxl:
> Add a vkbd frontend/backend pair for HVM guests"), which isn't used if
> there is no configured channel to actually access that keyboard.
> 
> One can still add vkb device manually if needed.
> 
> This is continuation of b053f0c4c9e533f3d97837cf897eb920b8355ed3 "libxl: do
> not start dom0 qemu for stubdomain when not needed".
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> Reviewed-by: Jason Andryuk 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 05/17] libxl: Handle Linux stubdomain specific QEMU options.

[Wei Liu]

On Mon, Jan 28, 2019 at 10:30:22PM +0100, Marek Marczykowski-Górecki wrote:
> From: Eric Shelton 
> 
> This patch creates an appropriate command line for the QEMU instance
> running in a Linux-based stubdomain.
> 
> NOTE: a number of items are not currently implemented for Linux-based
> stubdomains, such as:
> - save/restore
> - QMP socket
> - graphics output (e.g., VNC)
> 
> Signed-off-by: Eric Shelton 
> 
> Simon:
>  * fix disk path
>  * fix cdrom path and "format"
>  * pass downscript for network interfaces
> 
> Signed-off-by: Simon Gaiser 
> [drop Qubes-specific parts]
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 06/17] libxl: write qemu arguments into separate xenstore keys

[Wei Liu]

On Mon, Jan 28, 2019 at 10:30:23PM +0100, Marek Marczykowski-Górecki wrote:
> This allows using arguments with spaces, like -append, without
> nominating any special "separator" character.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 10/17] libxl: typo fix in comment

[Wei Liu]

On Mon, Jan 28, 2019 at 10:30:27PM +0100, Marek Marczykowski-Górecki wrote:
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 04/17] libxl: Allow running qemu-xen in stubdomain

[Wei Liu]

On Mon, Jan 28, 2019 at 10:30:21PM +0100, Marek Marczykowski-Górecki wrote:
> Do not prohibit anymore using stubdomain with qemu-xen.
> To help distingushing MiniOS and Linux stubdomain, add helper inline
> functions libxl__stubdomain_is_linux() and
> libxl__stubdomain_is_linux_running(). Those should be used where really
> the difference is about MiniOS/Linux, not qemu-xen/qemu-xen-traditional.
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> 
> ---
> Changes in v3:
>  - new patch, instead of "libxl: Add "stubdomain_version" to
>  domain_build_info"
>  - helper functions as suggested by Ian Jackson
> ---
>  tools/libxl/libxl_create.c   |  9 -
>  tools/libxl/libxl_internal.h | 17 +
>  2 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index a4e74a5..bb62542 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -160,15 +160,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>  }
>  }
>  
> -if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
> -b_info->device_model_version !=
> -LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
> -libxl_defbool_val(b_info->device_model_stubdomain)) {
> -LOG(ERROR,
> -"device model stubdomains require \"qemu-xen-traditional\"");
> -return ERROR_INVAL;
> -}
> -
>  if (!b_info->max_vcpus)
>  b_info->max_vcpus = 1;
>  if (!b_info->avail_vcpus.size) {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 459f9bf..b8c698a 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2195,6 +2195,23 @@ _hidden int 
> libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>/* Return the system-wide default device model */
>  _hidden libxl_device_model_version libxl__default_device_model(libxl__gc 
> *gc);
>  
> +static inline
> +bool libxl__stubdomain_is_linux_running(libxl__gc *gc, uint32_t domid)
> +{
> +/* same logic as in libxl__stubdomain_is_linux */
> +return libxl__device_model_version_running(gc, domid)
> +== LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;

I don't think the logic is accurate. You're precluding running
qemu-xen in a unikernel as stubdom.

I think putting an extra key in xenstore with the underlying platform is
more desirable.

> +}
> +
> +static inline
> +bool libxl__stubdomain_is_linux(libxl_domain_build_info *b_info)
> +{
> +/* right now qemu-tranditional implies MiniOS stubdomain and qemu-xen
> + * implies Linux stubdomain */
> +return libxl_defbool_val(b_info->device_model_stubdomain) &&
> +b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;

Subsequently you will need a new field in b_info.

What do you think?

Wei.

> +}
> +
>  #define DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, fmt, _a...)  \
>  libxl__sprintf(gc, "/local/domain/%u/device-model/%u" fmt, dm_domid,   \
> domid, ##_a)
> -- 
> git-series 0.9.1

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

Re: [Xen-devel] [PATCH v3 02/17] Document ioemu Linux stubdomain protocol

[Wei Liu]

On Mon, Jan 28, 2019 at 10:30:19PM +0100, Marek Marczykowski-Górecki wrote:
> Add documentation for upcoming Linux stubdomain for qemu-upstream.
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
>  docs/misc/stubdom.txt | 50 -
>  1 file changed, 50 insertions(+)
> 
> diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
> index 4c524f2..9c94c6b 100644
> --- a/docs/misc/stubdom.txt
> +++ b/docs/misc/stubdom.txt
> @@ -75,6 +75,56 @@ Defined commands:
> - "running" - success
>  
>  
> +Toolstack to Linux ioemu stubdomain protocol
> +
> +
> +This section describe communication protocol between toolstack and
> +qemu-upstream running in Linux stubdomain. The protocol include
> +expectations of both stubdomain, and qemu.
> +
> +Setup (done by toolstack, expected by stubdomain):
> + - Block devices for target domain are connected as PV disks to stubdomain,
> +   according to configuration order, starting with xvda
> + - Network devices for target domain are connected as PV nics to stubdomain,
> +   according to configuration order, starting with 0
> + - [not implemented] if graphics output is expected, VFB and VKB devices are 
> set for stubdomain
> +   (its backend is responsible for exposing them using appropriate protocol
> +   like VNC or Spice)
> + - other target domain's devices are not connected at this point to 
> stubdomain
> +   (may be hot-plugged later)
> + - QEMU command line is stored in
> +   /vm//image/dmargs xenstore dir, each argument as separate key
> +   in form /vm//image/dmargs/NNN, where NNN is 0-padded argument
> +   number
> + - target domain id is stored in /local/domain//target xenstore 
> path
> +?? - bios type is stored in /local/domain//hvmloader/bios

Since you're defining a new protocol here, you have the liberty to
eliminate this uncertainty, unless for some reason you want it to be
compatible with the old stubdom?


Wei.

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

Re: [Xen-devel] [PATCH] tools/xentop: Display '-' when stats are not available.

[Wei Liu]

On Wed, Feb 20, 2019 at 04:19:25PM +, Ronan Abhamon wrote:
> From: Pritha Srivastava 
> 
> Displaying 0 is misleading.
> 
> Signed-off-by: Pritha Srivastava 
> Signed-off-by: Ronan Abhamon 
> ---
>  tools/xenstat/libxenstat/src/xenstat.c   |   6 +
>  tools/xenstat/libxenstat/src/xenstat.h   |   3 +
>  tools/xenstat/libxenstat/src/xenstat_linux.c |  47 +++---
>  tools/xenstat/libxenstat/src/xenstat_priv.h  |   1 +
>  tools/xenstat/xentop/xentop.c| 159 +++
>  5 files changed, 158 insertions(+), 58 deletions(-)
> 
> diff --git a/tools/xenstat/libxenstat/src/xenstat.c 
> b/tools/xenstat/libxenstat/src/xenstat.c
> index fbe44f3c56..8fa12d7bc0 100644
> --- a/tools/xenstat/libxenstat/src/xenstat.c
> +++ b/tools/xenstat/libxenstat/src/xenstat.c
> @@ -729,6 +729,12 @@ unsigned long long xenstat_vbd_wr_sects(xenstat_vbd * 
> vbd)
>   return vbd->wr_sects;
>  }
>  
> +/* Returns error while getting stats (1 if error happened, 0 otherwise) */
> +unsigned int xenstat_vbd_error(xenstat_vbd * vbd)
> +{
> + return vbd->error;
> +}
> +

You can do away with this function by accessing vbd->error directly in
code.

>  /*
>   * Tmem functions
>   */
> diff --git a/tools/xenstat/libxenstat/src/xenstat.h 
> b/tools/xenstat/libxenstat/src/xenstat.h
> index 47ec60e14d..fe13b65727 100644
> --- a/tools/xenstat/libxenstat/src/xenstat.h
> +++ b/tools/xenstat/libxenstat/src/xenstat.h
> @@ -193,6 +193,9 @@ unsigned long long xenstat_vbd_wr_reqs(xenstat_vbd * vbd);
>  unsigned long long xenstat_vbd_rd_sects(xenstat_vbd * vbd);
>  unsigned long long xenstat_vbd_wr_sects(xenstat_vbd * vbd);
>  
> +/* Returns error while getting stats (1 if error happened, 0 otherwise) */
> +unsigned int xenstat_vbd_error(xenstat_vbd * vbd);
> +
>  /*
>   * Tmem functions - extract tmem information
>   */
> diff --git a/tools/xenstat/libxenstat/src/xenstat_linux.c 
> b/tools/xenstat/libxenstat/src/xenstat_linux.c
> index 7cdd3bf91f..9421ca43c8 100644
> --- a/tools/xenstat/libxenstat/src/xenstat_linux.c
> +++ b/tools/xenstat/libxenstat/src/xenstat_linux.c
> @@ -436,13 +436,15 @@ int xenstat_collect_vbds(xenstat_node * node)
>   ret = sscanf(dp->d_name, "%3s-%u-%u", buf, , );
>   if (ret != 3)
>   continue;
> + if (!(strstr(buf, "vbd")) && !(strstr(buf, "tap")))
> + continue;
>  
>   if (strcmp(buf,"vbd") == 0)
>   vbd.back_type = 1;
>   else if (strcmp(buf,"tap") == 0)
>   vbd.back_type = 2;
>   else
> - continue;
> + vbd.back_type = 0;
>  
>   domain = xenstat_node_domain(node, domid);
>   if (domain == NULL) {
> @@ -453,36 +455,29 @@ int xenstat_collect_vbds(xenstat_node * node)
>   continue;
>   }
>  
> - if((read_attributes_vbd(dp->d_name, "statistics/oo_req", buf, 
> 256)<=0)
> -|| ((ret = sscanf(buf, "%llu", _reqs)) != 1))
> - {
> - continue;
> - }
> -
> - if((read_attributes_vbd(dp->d_name, "statistics/rd_req", buf, 
> 256)<=0)
> -|| ((ret = sscanf(buf, "%llu", _reqs)) != 1))
> + if (vbd.back_type == 1 || vbd.back_type == 2)
>   {
> - continue;
> - }
>  
> - if((read_attributes_vbd(dp->d_name, "statistics/wr_req", buf, 
> 256)<=0)
> -|| ((ret = sscanf(buf, "%llu", _reqs)) != 1))
> - {
> - continue;
> - }
> -
> - if((read_attributes_vbd(dp->d_name, "statistics/rd_sect", buf, 
> 256)<=0)
> -|| ((ret = sscanf(buf, "%llu", _sects)) != 1))
> - {
> - continue;
> + vbd.error = 0;
> +
> + if ((read_attributes_vbd(dp->d_name, 
> "statistics/oo_req", buf, 256)<=0) ||
> + ((ret = sscanf(buf, "%llu", _reqs)) != 
> 1) ||
> + (read_attributes_vbd(dp->d_name, 
> "statistics/rd_req", buf, 256)<=0) ||
> + ((ret = sscanf(buf, "%llu", _reqs)) != 
> 1) ||
> + (read_attributes_vbd(dp->d_name, 
> "statistics/wr_req", buf, 256)<=0) ||
> + ((ret = sscanf(buf, "%llu", _reqs)) != 
> 1) ||
> + (read_attributes_vbd(dp->d_name, 
> "statistics/rd_sect", buf, 256)<=0) ||
> + ((ret = sscanf(buf, "%llu", _sects)) != 
> 1) ||
> + (read_attributes_vbd(dp->d_name, 
> "statistics/wr_sect", buf, 256)<=0) ||
> + ((ret = sscanf(buf, "%llu", _sects)) != 
> 1))
> + {
> + vbd.error = 1;
> + }
>   }
> -
> - 

[Xen-devel] [linux-4.19 test] 133319: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 broken
 test-amd64-i386-xl-shadowbroken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow broken
 test-amd64-amd64-rumprun-amd64 broken
 test-amd64-i386-xl-qemut-ws16-amd64 broken
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsmbroken
 test-armhf-armhf-xl-rtds broken
 test-amd64-amd64-qemuu-nested-amd broken
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsmbroken
 build-amd64-libvirt  broken  in 133304
 test-amd64-i386-pair broken  in 133304
 test-amd64-i386-rumprun-i386 broken  in 133304
 test-amd64-amd64-xl-qemut-debianhvm-amd64 broken in 133304
 test-amd64-i386-freebsd10-i386broken in 133304
 test-amd64-i386-xl-qemut-win10-i386   broken in 133304
 test-amd64-i386-xl-qemuu-ws16-amd64   broken in 133304
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict  broken in 
133304
 build-amd64-libvirt4 host-install(4) broken in 133304 REGR. vs. 129313
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
129313
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
129313

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 4 host-install(4) broken 
in 133304 pass in 133319
 test-amd64-i386-xl-qemuu-ws16-amd64 4 host-install(4) broken in 133304 pass in 
133319
 test-amd64-i386-freebsd10-i386 4 host-install(4) broken in 133304 pass in 
133319
 test-amd64-i386-pair 4 host-install/src_host(4) broken in 133304 pass in 133319
 test-amd64-i386-xl-qemut-win10-i386 4 host-install(4) broken in 133304 pass in 
133319
 test-amd64-amd64-xl-qemut-debianhvm-amd64 4 host-install(4) broken in 133304 
pass in 133319
 test-amd64-i386-rumprun-i386 4 host-install(4) broken in 133304 pass in 133319
 test-amd64-amd64-examine  5 host-install   broken in 133304 pass in 133319
 test-armhf-armhf-xl-rtds  4 host-install(4)  broken pass in 133304
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 4 host-install(4) broken pass in 
133304
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 4 host-install(4) broken 
pass in 133304
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 4 host-install(4) broken pass 
in 133304
 test-amd64-amd64-qemuu-nested-amd  4 host-install(4) broken pass in 133304
 test-amd64-amd64-xl-qemuu-ovmf-amd64  4 host-install(4)  broken pass in 133304
 test-amd64-i386-xl-qemut-ws16-amd64  4 host-install(4)   broken pass in 133304
 test-amd64-amd64-rumprun-amd64  4 host-install(4)broken pass in 133304
 test-amd64-i386-xl-shadow 4 host-install(4)  broken pass in 133304
 test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail in 133287 pass 
in 133319
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail in 133304 pass 
in 133287
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail in 133304 pass in 
133287
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail in 
133304 pass in 133287
 test-amd64-amd64-i386-pvgrub 10 debian-di-install fail in 133304 pass in 133319
 test-armhf-armhf-xl-cubietruck  6 xen-installfail in 133304 pass in 133319
 test-amd64-i386-freebsd10-i386  7 xen-boot fail pass in 133287
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail pass in 
133287
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail pass in 
133287
 test-amd64-amd64-libvirt-vhd 10 debian-di-install  fail pass in 133287
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot  fail pass in 133304
 test-amd64-i386-examine   8 reboot fail pass in 133304
 test-amd64-i386-libvirt   7 xen-boot   fail pass in 133304
 test-amd64-amd64-xl-pvhv2-intel  7 xen-bootfail pass in 133304
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail pass in 
133304
 test-amd64-i386-xl-raw7 xen-boot   fail pass in 133304
 test-amd64-i386-xl7 xen-boot   fail pass in 133304
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot   fail pass in 133304
 test-amd64-amd64-xl-shadow7 xen-boot   fail pass in 133304
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail pass in 
133304
 test-amd64-amd64-amd64-pvgrub  7 xen-boot  fail pass in 133304

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 133304 REGR. vs. 

Re: [Xen-devel] [PATCH for-4.12] x86: Improve the efficiency of domain_relinquish_resources()

[Wei Liu]

On Thu, Feb 21, 2019 at 12:22:13PM +, Andrew Cooper wrote:
> pci_release_devices() takes the global PCI lock.  Once pci_release_devices()
> has completed, it will be called redundantly each time paging_teardown() and
> vcpu_destroy_pagetables() continue.
> 
> This is liable to be millions of times for a reasonably sized guest, and is a
> serialising bottleneck now that domain_kill() can be run concurrently on
> different domains.
> 
> Instead of propagating the opencoding of the relinquish state machine, take
> the opportunity to clean it up.
> 
> Leave a proper set of comments explaining that domain_relinquish_resources()
> implements a co-routine.  Introduce a documented PROGRESS() macro to avoid
> latent bugs such as the RELMEM_xen case, and make the new PROG_* states
> private to domain_relinquish_resources().
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH tentitively for-4.12 0/4] x86/altp2m: Fix multiple security issues

[Juergen Gross]

On 19/02/2019 23:18, Andrew Cooper wrote:
> There are no XSAs because altp2m isn't security supported.  However, it would
> be very nice to have it in a less broken state for 4.12.
> 
> Overall the risk of regression to other parts of Xen is minimal, as most of
> these changes are only in altp2m-enabled paths.
> 
> Andrew Cooper (4):
>   xen/common: Break domain_unmap_resources() out of domain_kill()
>   x86/altp2m: Rework #VE enable/disable paths
>   x86/vmx: Fix security issue when a guest balloons out the #VE info page
>   x86/vmx: Properly flush the TLB when an altp2m is modified
> 
>  xen/arch/x86/domain.c  |  7 
>  xen/arch/x86/hvm/hvm.c | 19 ++
>  xen/arch/x86/hvm/vmx/vmx.c | 69 
>  xen/arch/x86/mm/altp2m.c   | 80 
> +++---
>  xen/common/domain.c| 16 +++--
>  xen/include/asm-x86/altp2m.h   |  4 ++-
>  xen/include/asm-x86/domain.h   |  3 ++
>  xen/include/asm-x86/hvm/vcpu.h |  7 +++-
>  xen/include/xen/domain.h   |  4 +++
>  9 files changed, 153 insertions(+), 56 deletions(-)
> 

For the series:

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.12] x86: Improve the efficiency of domain_relinquish_resources()

[Juergen Gross]

On 21/02/2019 13:22, Andrew Cooper wrote:
> pci_release_devices() takes the global PCI lock.  Once pci_release_devices()
> has completed, it will be called redundantly each time paging_teardown() and
> vcpu_destroy_pagetables() continue.
> 
> This is liable to be millions of times for a reasonably sized guest, and is a
> serialising bottleneck now that domain_kill() can be run concurrently on
> different domains.
> 
> Instead of propagating the opencoding of the relinquish state machine, take
> the opportunity to clean it up.
> 
> Leave a proper set of comments explaining that domain_relinquish_resources()
> implements a co-routine.  Introduce a documented PROGRESS() macro to avoid
> latent bugs such as the RELMEM_xen case, and make the new PROG_* states
> private to domain_relinquish_resources().
> 
> Signed-off-by: Andrew Cooper 

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 for-4.12] x86: Improve the efficiency of domain_relinquish_resources()

[Andrew Cooper]

pci_release_devices() takes the global PCI lock.  Once pci_release_devices()
has completed, it will be called redundantly each time paging_teardown() and
vcpu_destroy_pagetables() continue.

This is liable to be millions of times for a reasonably sized guest, and is a
serialising bottleneck now that domain_kill() can be run concurrently on
different domains.

Instead of propagating the opencoding of the relinquish state machine, take
the opportunity to clean it up.

Leave a proper set of comments explaining that domain_relinquish_resources()
implements a co-routine.  Introduce a documented PROGRESS() macro to avoid
latent bugs such as the RELMEM_xen case, and make the new PROG_* states
private to domain_relinquish_resources().

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
CC: Stefano Stabellini 
CC: Julien Grall 

So I know Xen 4.12 isn't going to crash and burn without this change, but I
also can't un-see the unnecessary global PCI lock contention.  In terms of
risk, this is extremely low - this function has complete coverage in testing,
and its behaviour isn't changing dramatically.

ARM: There are no problems, latent or otherwise, with your version of
domain_relinquish_resources(), but I'd recommend the same cleanup in due
course.
---
 xen/arch/x86/domain.c| 71 +---
 xen/include/asm-x86/domain.h | 10 +--
 2 files changed, 48 insertions(+), 33 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 32dc4253..7a29435 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -475,8 +475,6 @@ int arch_domain_create(struct domain *d,
 int rc;
 
 INIT_LIST_HEAD(>arch.pdev_list);
-
-d->arch.relmem = RELMEM_not_started;
 INIT_PAGE_LIST_HEAD(>arch.relmem_list);
 
 spin_lock_init(>arch.e820_lock);
@@ -2020,18 +2018,51 @@ int domain_relinquish_resources(struct domain *d)
 
 BUG_ON(!cpumask_empty(d->dirty_cpumask));
 
-switch ( d->arch.relmem )
+/*
+ * This hypercall can take minutes of wallclock time to complete.  This
+ * logic implements a co-routine, stashing state in struct domain across
+ * hypercall continuation boundaries.
+ */
+switch ( d->arch.rel_priv )
 {
-case RELMEM_not_started:
+/*
+ * Record the current progress.  Subsequent hypercall continuations
+ * will logically restart work from this point.
+ *
+ * PROGRESS() markers must not be in the middle of loops.  The loop
+ * variable isn't preserved across a continuation.
+ *
+ * To avoid redundant work, there should be a marker before each
+ * function which may return -ERESTART.
+ */
+#define PROGRESS(x) \
+d->arch.rel_priv = PROG_ ## x; /* Fallthrough */ case PROG_ ## x
+
+enum {
+PROG_paging = 1,
+PROG_vcpu_pagetables,
+PROG_shared,
+PROG_xen,
+PROG_l4,
+PROG_l3,
+PROG_l2,
+PROG_done,
+};
+
+case 0:
 ret = pci_release_devices(d);
 if ( ret )
 return ret;
 
+PROGRESS(paging):
+
 /* Tear down paging-assistance stuff. */
 ret = paging_teardown(d);
 if ( ret )
 return ret;
 
+PROGRESS(vcpu_pagetables):
+
 /* Drop the in-use references to page-table bases. */
 for_each_vcpu ( d, v )
 {
@@ -2058,10 +2089,7 @@ int domain_relinquish_resources(struct domain *d)
 d->arch.auto_unmask = 0;
 }
 
-d->arch.relmem = RELMEM_shared;
-/* fallthrough */
-
-case RELMEM_shared:
+PROGRESS(shared):
 
 if ( is_hvm_domain(d) )
 {
@@ -2072,45 +2100,40 @@ int domain_relinquish_resources(struct domain *d)
 return ret;
 }
 
-d->arch.relmem = RELMEM_xen;
-
 spin_lock(>page_alloc_lock);
 page_list_splice(>arch.relmem_list, >page_list);
 INIT_PAGE_LIST_HEAD(>arch.relmem_list);
 spin_unlock(>page_alloc_lock);
 
-/* Fallthrough. Relinquish every page of memory. */
-case RELMEM_xen:
+PROGRESS(xen):
+
 ret = relinquish_memory(d, >xenpage_list, ~0UL);
 if ( ret )
 return ret;
-d->arch.relmem = RELMEM_l4;
-/* fallthrough */
 
-case RELMEM_l4:
+PROGRESS(l4):
+
 ret = relinquish_memory(d, >page_list, PGT_l4_page_table);
 if ( ret )
 return ret;
-d->arch.relmem = RELMEM_l3;
-/* fallthrough */
 
-case RELMEM_l3:
+PROGRESS(l3):
+
 ret = relinquish_memory(d, >page_list, PGT_l3_page_table);
 if ( ret )
 return ret;
-d->arch.relmem = RELMEM_l2;
-/* fallthrough */
 
-case RELMEM_l2:
+PROGRESS(l2):
+
 ret = relinquish_memory(d, >page_list, 

Re: [Xen-devel] [PATCH for-next v2] xen: make grant table configurable

[Wei Liu]

On Thu, Feb 21, 2019 at 12:02:13PM +, Julien Grall wrote:
> 
> 
> On 21/02/2019 12:01, Wei Liu wrote:
> > On Fri, Jan 18, 2019 at 12:43:57PM +, Wei Liu wrote:
> > > Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm
> > > hypervisors build with grant table disabled.
> > > 
> > > Signed-off-by: Wei Liu 
> > 
> > I know this patch can only be applied after the tree is reopen but ...
> > 
> > > 
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index 221c762ada..0f1c1b6431 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -1392,7 +1392,9 @@ static arm_hypercall_t arm_hypercall_table[] = {
> > >   HYPERCALL_DEPRECATED(physdev_op_compat, 1),
> > >   HYPERCALL(sysctl, 2),
> > >   HYPERCALL(hvm_op, 2),
> > > +#ifdef CONFIG_GRANT_TABLE
> > >   HYPERCALL(grant_table_op, 3),
> > > +#endif
> > >   HYPERCALL(multicall, 2),
> > >   HYPERCALL(platform_op, 1),
> > >   HYPERCALL_ARM(vcpu_op, 3),
> > 
> > can I get an ack from one of the Arm maintainers so that I can queue it
> > up?
> 
> Acked-by: Julien Grall 

Thank you!

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

Re: [Xen-devel] [PATCH for-next v2] xen: make grant table configurable

[Julien Grall]

On 21/02/2019 12:01, Wei Liu wrote:

On Fri, Jan 18, 2019 at 12:43:57PM +, Wei Liu wrote:

Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm
hypervisors build with grant table disabled.

Signed-off-by: Wei Liu 


I know this patch can only be applied after the tree is reopen but ...



diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 221c762ada..0f1c1b6431 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1392,7 +1392,9 @@ static arm_hypercall_t arm_hypercall_table[] = {
  HYPERCALL_DEPRECATED(physdev_op_compat, 1),
  HYPERCALL(sysctl, 2),
  HYPERCALL(hvm_op, 2),
+#ifdef CONFIG_GRANT_TABLE
  HYPERCALL(grant_table_op, 3),
+#endif
  HYPERCALL(multicall, 2),
  HYPERCALL(platform_op, 1),
  HYPERCALL_ARM(vcpu_op, 3),


can I get an ack from one of the Arm maintainers so that I can queue it
up?


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

[Joao Martins]

On 2/21/19 7:57 AM, Juergen Gross wrote:
> On 21/02/2019 00:39, Marek Marczykowski-Górecki wrote:
>> On Wed, Feb 20, 2019 at 08:15:30PM +, Joao Martins wrote:
>>>  2. PV Driver support (patches 17 - 39)
>>>
>>>  We start by redirecting hypercalls from the backend to routines
>>>  which emulate the behaviour that PV backends expect i.e. grant
>>>  table and interdomain events. Next, we add support for late
>>>  initialization of xenbus, followed by implementing
>>>  frontend/backend communication mechanisms (i.e. grant tables and
>>>  interdomain event channels). Finally, introduce xen-shim.ko,
>>>  which will setup a limited Xen environment. This uses the added
>>>  functionality of Xen specific shared memory (grant tables) and
>>>  notifications (event channels).
>>
>> Does it mean backends could be run in another guest, similarly as on
>> real Xen? AFAIK virtio doesn't allow that as virtio backends need
>> arbitrary write access to guest memory. But grant tables provide enough
>> abstraction to do that safely.
> 
> As long as the grant table emulation in xen-shim isn't just a wrapper to
> "normal" KVM guest memory access.
> 
> I guess the xen-shim implementation doesn't support the same kind of
> guest memory isolation as Xen does?
> 
It doesn't, but it's also two different usecases.

The xen-shim is meant to when PV backend lives in the hypervisor (similar model
as KVM vhost), whereas domU grant mapping that Marek is asking about require
additional hypercalls handled by guest (i.e. in kvm_xen_hypercall). This would
equate to how Xen currently performs grant mapping/unmapping.

Joao

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

Re: [Xen-devel] [PATCH for-next v2] xen: make grant table configurable

[Wei Liu]

On Fri, Jan 18, 2019 at 12:43:57PM +, Wei Liu wrote:
> Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm
> hypervisors build with grant table disabled.
> 
> Signed-off-by: Wei Liu 

I know this patch can only be applied after the tree is reopen but ...

> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 221c762ada..0f1c1b6431 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1392,7 +1392,9 @@ static arm_hypercall_t arm_hypercall_table[] = {
>  HYPERCALL_DEPRECATED(physdev_op_compat, 1),
>  HYPERCALL(sysctl, 2),
>  HYPERCALL(hvm_op, 2),
> +#ifdef CONFIG_GRANT_TABLE
>  HYPERCALL(grant_table_op, 3),
> +#endif
>  HYPERCALL(multicall, 2),
>  HYPERCALL(platform_op, 1),
>  HYPERCALL_ARM(vcpu_op, 3),

can I get an ack from one of the Arm maintainers so that I can queue it
up?

Thanks,
Wei.

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

Re: [Xen-devel] About Porting Virtio to the XEN

[Wei Liu]

On Thu, Feb 21, 2019 at 06:13:32PM +0800, chengyan wrote:
> Dear Expert:
> 
>    I want to porting the Virtio to the XEN via reference to
> the below links.
> 
>    https://wiki.xen.org/wiki/Virtio_On_Xen.

That page is very dated.
> 
>        If I have ported the Virtio as the following guides
> ,whether it may reach my requirement,which is in the HVM guest?

What are your requirements?

Seeing that your company seems to work on automotive projects, I know
Julien from Arm has done some work for Xen on Arm, if you can be more
specific, maybe Julien can give you an answer?

Wei.

> 
> 
>  My expected result is that visit I/O via the virtio. Would
> you please give me answers ?
> 
> Thanks.
> 
> 
> 

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


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

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

[Joao Martins]

On 2/20/19 11:39 PM, Marek Marczykowski-Górecki wrote:
> On Wed, Feb 20, 2019 at 08:15:30PM +, Joao Martins wrote:
>>  2. PV Driver support (patches 17 - 39)
>>
>>  We start by redirecting hypercalls from the backend to routines
>>  which emulate the behaviour that PV backends expect i.e. grant
>>  table and interdomain events. Next, we add support for late
>>  initialization of xenbus, followed by implementing
>>  frontend/backend communication mechanisms (i.e. grant tables and
>>  interdomain event channels). Finally, introduce xen-shim.ko,
>>  which will setup a limited Xen environment. This uses the added
>>  functionality of Xen specific shared memory (grant tables) and
>>  notifications (event channels).
> 
> Does it mean backends could be run in another guest, similarly as on
> real Xen? AFAIK virtio doesn't allow that as virtio backends need
> arbitrary write access to guest memory. But grant tables provide enough
> abstraction to do that safely.
> 
In this series not yet. Here we are trying to resemble how KVM drives its kernel
PV backends (i.e. vhost virtio).

The domU grant {un,}mapping could be added complementary. The main difference
between domU gntmap vs shim gntmap is that the former maps/unmaps the  guest
page on the backend. Most of it is common code I think.

Joao

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

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

[Joao Martins]

On 2/20/19 9:09 PM, Paolo Bonzini wrote:
> On 20/02/19 21:15, Joao Martins wrote:
>>  2. PV Driver support (patches 17 - 39)
>>
>>  We start by redirecting hypercalls from the backend to routines
>>  which emulate the behaviour that PV backends expect i.e. grant
>>  table and interdomain events. Next, we add support for late
>>  initialization of xenbus, followed by implementing
>>  frontend/backend communication mechanisms (i.e. grant tables and
>>  interdomain event channels). Finally, introduce xen-shim.ko,
>>  which will setup a limited Xen environment. This uses the added
>>  functionality of Xen specific shared memory (grant tables) and
>>  notifications (event channels).
> 
> I am a bit worried by the last patches, they seem really brittle and
> prone to breakage.  I don't know Xen well enough to understand if the
> lack of support for GNTMAP_host_map is fixable, but if not, you have to
> define a completely different hypercall.
> 
I guess Ankur already answered this; so just to stack this on top of his 
comment.

The xen_shim_domain() is only meant to handle the case where the backend
has/can-have full access to guest memory [i.e. netback and blkback would work
with similar assumptions as vhost?]. For the normal case, where a backend *in a
guest* maps and unmaps other guest memory, this is not applicable and these
changes don't affect that case.

IOW, the PV backend here sits on the hypervisor, and the hypercalls aren't
actual hypercalls but rather invoking shim_hypercall(). The call chain would go
more or less like:


 gnttab_map_refs(map_ops, pages)
   HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,...)
 shim_hypercall()
   shim_hcall_gntmap()

Our reasoning was that given we are already in KVM, why mapping a page if the
user (i.e. the kernel PV backend) is himself? The lack of GNTMAP_host_map is how
the shim determines its user doesn't want to map the page. Also, there's another
issue where PV backends always need a struct page to reference the device
inflight data as Ankur pointed out.

> Of course, tests are missing.

FWIW: this was deliberate as we wanted to get folks impressions before
proceeding further with the work.

> You should use the
> tools/testing/selftests/kvm/ framework, and ideally each patch should
> come with coverage for the newly-added code.
> Got it.

Cheers,
Joao

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

[Xen-devel] [libvirt test] 133320: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 133272
 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 133272

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 133272
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133272
 test-amd64-amd64-libvirt 13 migrate-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-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-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-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  a27031c4085906612804776a489a39da4d9ba963
baseline version:
 libvirt  0624ac3fa846b3e2a8e70e4cc2fd8477710cd76d

Last test of basis   133272  2019-02-15 22:58:38 Z5 days
Failing since133306  2019-02-19 04:19:06 Z2 days2 attempts
Testing same since   133320  2019-02-20 04:19:00 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Chris Venteicher 
  Daniel P. Berrangé 
  Eric Blake 
  Jiri Denemark 
  Ján Tomko 
  Nikolay Shirokovskiy 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-arm64-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   fail
 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-xsmblocked 
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd fail



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

Re: [Xen-devel] About Porting Virtio to the XEN

[Roger Pau Monné]

On Thu, Feb 21, 2019 at 06:13:32PM +0800, chengyan wrote:
> Dear Expert:
> 
>    I want to porting the Virtio to the XEN via reference to
> the below links.
> 
>    https://wiki.xen.org/wiki/Virtio_On_Xen.

The wikipage you mention is very outdated AFAICT. The following
wikipage is likely more relevant:

https://wiki.xenproject.org/wiki/QEMU_Upstream#VirtIO

>        If I have ported the Virtio as the following guides
> ,whether it may reach my requirement,which is in the HVM guest?
>
> 
>  My expected result is that visit I/O via the virtio. Would
> you please give me answers ?

I'm afraid you haven't provided enough information for us to help you.

What have you done exactly?

I assume what you did didn't work out as you would expect, can you
provide the error that you get?

Thanks, Roger.

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

[Xen-devel] About Porting Virtio to the XEN

[chengyan]

Dear Expert:

   I want to porting the Virtio to the XEN via 
reference to the below links.


   https://wiki.xen.org/wiki/Virtio_On_Xen.

       If I have ported the Virtio as the following guides 
,whether it may reach my requirement,which is in the HVM guest?



 My expected result is that visit I/O via the virtio. 
Would you please give me answers ?


Thanks.



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

Re: [Xen-devel] XEN on R-CAR H3

[Julien Grall]

Hi Oleksandr,

On 20/02/2019 21:28, Oleksandr Tyshchenko wrote:
> ср, 20 февр. 2019 г., 22:14 Julien Grall  >:
> If I am not mistaken, the diff between BSP's and mainline device trees is in 
> reserved memory area. BSP device tree (1) contains reserved memory regions, 
> but 
> the mainline one (2) doesn't.
>  From the log you provided, I see that Xen is trying to copy device-tree to 
> the 
> address which is located in reserved area (0x5800). FYI, we always remove 
> these reserved area nodes from the device-tree. Maybe that's why we didn't 
> face 
> an issue. Julien, what do you think, can this be a reason?
While I know that Xen does not deal with reserved area yet, we should have been 
able to write in that region. We don't even reach that state as we can't get 
the 
associated page.

It might be possible that the p2m entry is overwritten when going through the 
DT 
for mapping all the regions (see handle_device).

Printing the lookup would actually help to know what's going on.

Cheers,

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

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

[Roger Pau Monné]

On Wed, Feb 20, 2019 at 05:08:09PM +, Wei Liu wrote:
> On Wed, Feb 20, 2019 at 01:09:56PM +, Wei Liu wrote:
> [...]
> > I think under-allocate-then-map looks plausible. xmalloc will need
> > to allocate pages, put them into an array and call __vmap on that array
> > directly.
> 
> The biggest issue with this approach is that we now need an array of
> 1UL< this is going to be (1UL<<20)*8 bytes long. This is not feasible.

Right. I guess the only remaining option is to allocate a virtual
address space and populate it using multiple pages?

That would likely require to split some functions into smaller helpers
so you can call them and provide the virtual address where a page
should be mapped?

Roger.

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

Re: [Xen-devel] [PATCH] drm: add func to better detect wether swiotlb is needed

[Paul Durrant]

> -Original Message-
> From: Michael D Labriola [mailto:michael.d.labri...@gmail.com]
> Sent: 19 February 2019 23:08
> To: dri-de...@lists.freedesktop.org; Alex Deucher
> ; Christian Koenig ;
> Chunming Zhou ; amd-...@lists.freedesktop.org; Monk
> Liu 
> Cc: Juergen Gross ; Christoph Hellwig
> ; Andrew Cooper ; Paul
> Durrant ; xen-de...@lists.xen.org; Jan Beulich
> ; Konrad Rzeszutek Wilk ;
> Michael D Labriola 
> Subject: [PATCH] drm: add func to better detect wether swiotlb is needed
> 
> This commit fixes DRM failures on Xen PV systems that were introduced in
> v4.17 by the following commits:
> 
> 82626363 drm: add func to get max iomem address v2
> fd5fd480 drm/amdgpu: only enable swiotlb alloc when need v2
> 1bc3d3cc drm/radeon: only enable swiotlb path when need v2
> 
> The introduction of ->need_swiotlb to the ttm_dma_populate() conditionals
> in the radeon and amdgpu device drivers causes Gnome to immediately crash
> on Xen PV systems, returning the user to the login screen.  The following
> kernel errors get logged:
> 
> [   28.554259] radeon_dp_aux_transfer_native: 200 callbacks suppressed
> [   31.219821] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [   31.220030] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [   31.226109] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [   31.226300] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [   31.300734] gnome-shell[1935]: segfault at 88 ip 7f39151cd904 sp
> 7ffc97611ad8 error 4 in libmutter-cogl.so[7f3915178000+aa000]
> [   31.300745] Code: 5f c3 0f 1f 40 00 48 8b 47 78 48 8b 40 40 ff e0 66 0f
> 1f 44 00 00 48 8b 47 78 48 8b 40 48 ff e0 66 0f 1f 44 00 00 48 8b 47 78
> <48> 8b 80 88 00 00 00 ff e0 0f 1f 00 48 8b 47 78 48 8b 40 68 ff e0
> [   38.193302] radeon_dp_aux_transfer_native: 116 callbacks suppressed
> [   40.009317] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [   40.009488] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [   40.015114] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [   40.015297] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [   40.028302] gnome-shell[2431]: segfault at 2dadf40 ip 02dadf40
> sp 7ffcd24ea5f8 error 15
> [   40.028306] Code: 20 6e 31 00 00 00 00 00 00 00 00 37 e3 3d 2d 7f 00 00
> 80 f4 e6 3d 2d 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> <00> 00 00 00 00 00 00 00 c1 00 00 00 00 00 00 00 80 e1 d2 03 00 00
> 
> This commit renames drm_get_max_iomem() to drm_need_swiotlb(), adds a
> xen_pv_domain() check to it, and moves the bit shifting comparison that
> always follows its usage into the function (simplifying the drm driver
> code).
> 
> Signed-off-by: Michael D Labriola 
> ---
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  |  2 +-
>  drivers/gpu/drm/drm_memory.c   | 19 ---
>  drivers/gpu/drm/radeon/radeon_device.c |  2 +-
>  include/drm/drm_cache.h|  2 +-
>  6 files changed, 21 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index 910c4ce..6bc0266 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -1029,7 +1029,7 @@ static int gmc_v7_0_sw_init(void *handle)
>   pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
>   pr_warn("amdgpu: No coherent DMA available\n");
>   }
> - adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
> + adev->need_swiotlb = drm_need_swiotlb(dma_bits);
> 
>   r = gmc_v7_0_init_microcode(adev);
>   if (r) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index 747c068..8638adf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -1155,7 +1155,7 @@ static int gmc_v8_0_sw_init(void *handle)
>   pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
>   pr_warn("amdgpu: No coherent DMA available\n");
>   }
> - adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
> + adev->need_swiotlb = drm_need_swiotlb(dma_bits);
> 
>   r = gmc_v8_0_init_microcode(adev);
>   if (r) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> index f35d7a5..4f67093 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> @@ -989,7 +989,7 @@ static int gmc_v9_0_sw_init(void *handle)
>   pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
>   

Re: [Xen-devel] [RFC PATCH v3 13/25] xen: Let buffer_append() return a size_t

[Paul Durrant]

> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> Sent: 20 February 2019 01:02
> To: qemu-de...@nongnu.org; Prasad J Pandit ; Marc-
> André Lureau ; Paolo Bonzini
> 
> Cc: Jason Wang ; Anthony Perard
> ; qemu-...@nongnu.org; Stefan Berger
> ; David Gibson ; Gerd
> Hoffmann ; Zhang Chen ; xen-
> de...@lists.xenproject.org; Cornelia Huck ; Samuel
> Thibault ; Christian Borntraeger
> ; Amit Shah ; Li Zhijian
> ; Corey Minyard ; Michael S.
> Tsirkin ; Paul Durrant ; Halil
> Pasic ; Stefano Stabellini ;
> qemu-s3...@nongnu.org; Pavel Dovgalyuk ;
> Philippe Mathieu-Daudé 
> Subject: [RFC PATCH v3 13/25] xen: Let buffer_append() return a size_t
> 
> To the Xen team: this is not trivial to me to demonstrate
> this assertion can never happen, but then the whole series
> is justified and I can convert qemu_chr_fe_write() to use
> size_t argument.
> Can you help me here?

I'm not particularly familiar with this bit of code but I can try...

> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/char/xen_console.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> index 1a30014a11..5b672a5a24 100644
> --- a/hw/char/xen_console.c
> +++ b/hw/char/xen_console.c
> @@ -92,6 +92,7 @@ static ssize_t buffer_append(struct XenConsole *con)
>  }
> 
>   out:
> +assert(buffer->size >= buffer->consumed);
>  return buffer->size - buffer->consumed;

I think this assertion is reasonable as:

- buffer_advance() appears to hit a termination condition when buffer->consumed 
== buffer->size. (Nothing checks for overflow which is bad, but that fact also 
lends weight to the assertion that consumed > size is a bug).
- if buffer->size ever exceeds buffer->max_capacity then both size and consumed 
are re-calculated such that consumed <= size.

  Paul

>  }
> 
> --
> 2.20.1

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

[Xen-devel] [PATCH v2 11/14] x86/domctl: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to update cpuid info for creating PV guest.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/domctl.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9bf2d08..3a9e290 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -176,6 +176,7 @@ static int update_domain_cpuid_info(struct domain *d,
 break;
 
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 mask &= ((uint64_t)ecx << 32) | edx;
 
 /*
@@ -220,7 +221,8 @@ static int update_domain_cpuid_info(struct domain *d,
 uint32_t eax = ctl->eax;
 uint32_t ebx = p->feat._7b0;
 
-if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
 mask &= ((uint64_t)eax << 32) | ebx;
 
 d->arch.pv.cpuidmasks->_7ab0 = mask;
@@ -281,8 +283,12 @@ static int update_domain_cpuid_info(struct domain *d,
 if ( cpu_has_cmp_legacy )
 ecx |= cpufeat_mask(X86_FEATURE_CMP_LEGACY);
 
-/* If not emulating AMD, clear the duplicated features in e1d. */
-if ( p->x86_vendor != X86_VENDOR_AMD )
+/*
+ * If not emulating AMD and Hygon, clear the duplicated features
+ * in e1d.
+ */
+if ( p->x86_vendor != X86_VENDOR_AMD &&
+ p->x86_vendor != X86_VENDOR_HYGON )
 edx &= ~CPUID_COMMON_1D_FEATURES;
 
 switch ( boot_cpu_data.x86_vendor )
@@ -292,6 +298,7 @@ static int update_domain_cpuid_info(struct domain *d,
 break;
 
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 mask &= ((uint64_t)ecx << 32) | edx;
 
 /*
-- 
2.7.4


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

[Xen-devel] [PATCH v2 13/14] x86/cpuid: Add Hygon Dhyana support

[Pu Wen]

The Hygon Dhyana family 18h processor shares the same cpuid leaves as the
AMD family 17h one. So add Hygon Dhyana support to caculate the cpuid
policies as the AMD CPU does.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/cpuid.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index ab0aab6..f760594 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -240,6 +240,7 @@ static void recalculate_misc(struct cpuid_policy *p)
 break;
 
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 zero_leaves(p->basic.raw, 0x2, 0x3);
 memset(p->cache.raw, 0, sizeof(p->cache.raw));
 zero_leaves(p->basic.raw, 0x9, 0xa);
@@ -390,7 +391,8 @@ static void __init calculate_hvm_max_policy(void)
  * long mode (and init_amd() has cleared it out of host capabilities), but
  * HVM guests are able if running in protected mode.
  */
-if ( (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
+if ( (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+  boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) &&
  raw_cpuid_policy.basic.sep )
 __set_bit(X86_FEATURE_SEP, hvm_featureset);
 
@@ -465,7 +467,8 @@ void recalculate_cpuid_policy(struct domain *d)
 p->basic.max_leaf   = min(p->basic.max_leaf,   max->basic.max_leaf);
 p->feat.max_subleaf = min(p->feat.max_subleaf, max->feat.max_subleaf);
 p->extd.max_leaf= 0x8000 | min(p->extd.max_leaf & 0x,
-   (p->x86_vendor == X86_VENDOR_AMD
+  ((p->x86_vendor == X86_VENDOR_AMD ||
+p->x86_vendor == X86_VENDOR_HYGON)
 ? CPUID_GUEST_NR_EXTD_AMD
 : CPUID_GUEST_NR_EXTD_INTEL) - 1);
 
@@ -507,7 +510,8 @@ void recalculate_cpuid_policy(struct domain *d)
 if ( is_pv_32bit_domain(d) )
 {
 __clear_bit(X86_FEATURE_LM, max_fs);
-if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
 __clear_bit(X86_FEATURE_SYSCALL, max_fs);
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v2 09/14] x86/pv: Add Hygon Dhyana support to emulate MSRs access

[Pu Wen]

The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
counter MSRs, hardware configuration MSR, MMIO configuration base address
MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to the
PV emulation infrastructure by using the code path of AMD.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/pv/emul-priv-op.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 942ece2..1521041 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -911,7 +911,9 @@ static int read_msr(unsigned int reg, uint64_t *val,
 /* fall through */
 case MSR_AMD_FAM15H_EVNTSEL0 ... MSR_AMD_FAM15H_PERFCTR5:
 case MSR_K7_EVNTSEL0 ... MSR_K7_PERFCTR3:
-if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+if ( vpmu_msr ||
+(boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ||
+(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) )
 {
 if ( vpmu_do_rdmsr(reg, val) )
 break;
@@ -993,7 +995,8 @@ static int write_msr(unsigned int reg, uint64_t val,
 case MSR_K8_PSTATE6:
 case MSR_K8_PSTATE7:
 case MSR_K8_HWCR:
-if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
 break;
 if ( likely(!is_cpufreq_controller(currd)) ||
  wrmsr_safe(reg, val) == 0 )
@@ -1014,8 +1017,9 @@ static int write_msr(unsigned int reg, uint64_t val,
 break;
 
 case MSR_FAM10H_MMIO_CONF_BASE:
-if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
- boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
+if ( (boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
+  boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17) &&
+  boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
 break;
 if ( !is_hardware_domain(currd) || !is_pinned_vcpu(curr) )
 return X86EMUL_OKAY;
@@ -1054,7 +1058,8 @@ static int write_msr(unsigned int reg, uint64_t val,
 case MSR_IA32_MPERF:
 case MSR_IA32_APERF:
 if ( (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) &&
- (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) )
+ (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) &&
+ (boot_cpu_data.x86_vendor != X86_VENDOR_HYGON) )
 break;
 if ( likely(!is_cpufreq_controller(currd)) ||
  wrmsr_safe(reg, val) == 0 )
@@ -1087,7 +1092,9 @@ static int write_msr(unsigned int reg, uint64_t val,
 vpmu_msr = true;
 case MSR_AMD_FAM15H_EVNTSEL0 ... MSR_AMD_FAM15H_PERFCTR5:
 case MSR_K7_EVNTSEL0 ... MSR_K7_PERFCTR3:
-if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+if ( vpmu_msr ||
+(boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ||
+(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) )
 {
 if ( (vpmu_mode & XENPMU_MODE_ALL) &&
  !is_hardware_domain(currd) )
-- 
2.7.4


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

[Xen-devel] [PATCH v2 14/14] tools/libxc: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to caculate the cpuid policies for creating PV
or HVM guest by using the code path of AMD.

Signed-off-by: Pu Wen 
Acked-by: Wei Liu 
---
 tools/libxc/xc_cpuid_x86.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 098affe..d0cb9ae 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -234,6 +234,7 @@ struct cpuid_domain_info
 VENDOR_UNKNOWN,
 VENDOR_INTEL,
 VENDOR_AMD,
+VENDOR_HYGON,
 } vendor;
 
 bool hvm;
@@ -304,6 +305,10 @@ static int get_cpuid_domain_info(xc_interface *xch, 
uint32_t domid,
   regs[2] == 0x444d4163U &&
   regs[3] == 0x69746e65U )
 info->vendor = VENDOR_AMD;
+else if ( regs[1] == 0x6f677948U && /* "HygonGenuine" */
+  regs[2] == 0x656e6975U &&
+  regs[3] == 0x6e65476eU )
+info->vendor = VENDOR_HYGON;
 else
 info->vendor = VENDOR_UNKNOWN;
 
@@ -568,7 +573,8 @@ static void xc_cpuid_hvm_policy(const struct 
cpuid_domain_info *info,
 break;
 }
 
-if ( info->vendor == VENDOR_AMD )
+if ( info->vendor == VENDOR_AMD ||
+ info->vendor == VENDOR_HYGON )
 amd_xc_cpuid_policy(info, input, regs);
 else
 intel_xc_cpuid_policy(info, input, regs);
@@ -630,7 +636,8 @@ static void xc_cpuid_pv_policy(const struct 
cpuid_domain_info *info,
 
 case 0x8000:
 {
-unsigned int max = info->vendor == VENDOR_AMD
+unsigned int max = (info->vendor == VENDOR_AMD||
+info->vendor == VENDOR_HYGON)
 ? DEF_MAX_AMDEXT : DEF_MAX_INTELEXT;
 
 if ( regs[0] > max )
@@ -736,7 +743,8 @@ static void sanitise_featureset(struct cpuid_domain_info 
*info)
 if ( !info->pv64 )
 {
 clear_bit(X86_FEATURE_LM, info->featureset);
-if ( info->vendor != VENDOR_AMD )
+if ( info->vendor != VENDOR_AMD &&
+ info->vendor != VENDOR_HYGON )
 clear_bit(X86_FEATURE_SYSCALL, info->featureset);
 }
 
@@ -787,7 +795,7 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid,
 input[0] = 0x8000;
 cpuid(input, regs);
 
-if ( info.vendor == VENDOR_AMD )
+if ( info.vendor == VENDOR_AMD || info.vendor == VENDOR_HYGON )
 ext_max = (regs[0] <= DEF_MAX_AMDEXT) ? regs[0] : DEF_MAX_AMDEXT;
 else
 ext_max = (regs[0] <= DEF_MAX_INTELEXT) ? regs[0] : DEF_MAX_INTELEXT;
-- 
2.7.4


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

[Xen-devel] [PATCH v2 08/14] x86/iommu: Add Hygon Dhyana support

[Pu Wen]

The IOMMU architecture for the Hygon Dhyana CPU is similar to the AMD
family 17h one. So add Hygon Dhyana support to it by sharing the code
path of AMD.

Signed-off-by: Pu Wen 
---
 xen/include/asm-x86/iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 8dc3924..699a8f7 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -74,6 +74,7 @@ static inline int iommu_hardware_setup(void)
 case X86_VENDOR_INTEL:
 return intel_vtd_setup();
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 return amd_iov_detect();
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v2 12/14] x86/traps: Add Hygon Dhyana support

[Pu Wen]

The Hygon Dhyana processor has the methold to get the last exception
source IP from MSR_01DD. So add support for it if the boot param
ler is true.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/traps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 05ddc39..97bf9e2 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1973,6 +1973,9 @@ static unsigned int calc_ler_msr(void)
 return MSR_IA32_LASTINTFROMIP;
 }
 break;
+
+case X86_VENDOR_HYGON:
+return MSR_IA32_LASTINTFROMIP;
 }
 
 return 0;
-- 
2.7.4


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

[Xen-devel] [PATCH v2 07/14] x86/acpi: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to the acpi cpufreq and cpuidle subsystems by
using the code path of AMD.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/acpi/cpu_idle.c | 3 ++-
 xen/arch/x86/acpi/cpufreq/cpufreq.c  | 8 +---
 xen/arch/x86/acpi/cpufreq/powernow.c | 3 ++-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 14b0278..f57825c 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -795,7 +795,8 @@ void acpi_dead_idle(void)
 __mwait(cx->address, 0);
 }
 }
-else if ( current_cpu_data.x86_vendor == X86_VENDOR_AMD &&
+else if ( (current_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+   current_cpu_data.x86_vendor == X86_VENDOR_HYGON) &&
   cx->entry_method == ACPI_CSTATE_EM_SYSIO )
 {
 /* Intel prefers not to use SYSIO */
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c 
b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 844ab85..14c18bd 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -649,7 +649,8 @@ static int __init cpufreq_driver_init(void)
 (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL))
 ret = cpufreq_register_driver(_cpufreq_driver);
 else if ((cpufreq_controller == FREQCTL_xen) &&
-(boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
+(boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON))
 ret = powernow_register_driver();
 
 return ret;
@@ -660,9 +661,10 @@ int cpufreq_cpu_init(unsigned int cpuid)
 {
 int ret;
 
-/* Currently we only handle Intel and AMD processor */
+/* Currently we only handle Intel, AMD and Hygon processor */
 if ( (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) ||
- (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) )
+ (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) ||
+ (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ) )
 ret = cpufreq_add_cpu(cpuid);
 else
 ret = -EFAULT;
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c 
b/xen/arch/x86/acpi/cpufreq/powernow.c
index 025b37d..f245908 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -360,7 +360,8 @@ unsigned int __init powernow_register_driver()
 
 for_each_online_cpu(i) {
 struct cpuinfo_x86 *c = _data[i];
-if (c->x86_vendor != X86_VENDOR_AMD)
+if (c->x86_vendor != X86_VENDOR_AMD &&
+c->x86_vendor != X86_VENDOR_HYGON)
 ret = -ENODEV;
 else
 {
-- 
2.7.4


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

[Xen-devel] [PATCH v2 10/14] x86/domain: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to handle HyperTransport range.

Also loading a nul selector does not clear bases and limits on Hygon
CPUs, so add Hygon Dhyana support to the function preload_segment.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/dom0_build.c | 3 ++-
 xen/arch/x86/domain.c | 9 +
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 2b4d9e9..c0657ee 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -532,7 +532,8 @@ int __init dom0_setup_permissions(struct domain *d)
 paddr_to_pfn(MSI_ADDR_BASE_LO +
  MSI_ADDR_DEST_ID_MASK));
 /* HyperTransport range. */
-if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
 rc |= iomem_deny_access(d, paddr_to_pfn(0xfdULL << 32),
 paddr_to_pfn((1ULL << 40) - 1));
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 32dc4253..319eea1 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1300,13 +1300,14 @@ arch_do_vcpu_op(
 }
 
 /*
- * Loading a nul selector does not clear bases and limits on AMD CPUs. Be on
- * the safe side and re-initialize both to flat segment values before loading
- * a nul selector.
+ * Loading a nul selector does not clear bases and limits on AMD or Hygon
+ * CPUs. Be on the safe side and re-initialize both to flat segment values
+ * before loading a nul selector.
  */
 #define preload_segment(seg, value) do {  \
 if ( !((value) & ~3) &&   \
- boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) \
+(boot_cpu_data.x86_vendor == X86_VENDOR_AMD || \
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) ) \
 asm volatile ( "movl %k0, %%" #seg\
:: "r" (FLAT_USER_DS32) ); \
 } while ( false )
-- 
2.7.4


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

[Xen-devel] [PATCH v2 06/14] x86/apic: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to use modern APIC.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/apic.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 2a24326..004d685 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -92,6 +92,11 @@ static int modern_apic(void)
 if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
 boot_cpu_data.x86 >= 0xf)
 return 1;
+
+/* Hygon systems use modern APIC */
+if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+return 1;
+
 lvr = apic_read(APIC_LVR);
 version = GET_APIC_VERSION(lvr);
 return version >= 0x14;
-- 
2.7.4


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

[Xen-devel] [PATCH v2 05/14] x86/spec_ctrl: Add Hygon Dhyana to the respective mitigation machinery

[Pu Wen]

The Hygon Dhyana CPU has the same speculative execution as AMD family
17h, so share AMD Retpoline and PTI mitigation code with Hygon Dhyana.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/spec_ctrl.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index ad72ecd..38a6ed2 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -306,7 +306,8 @@ static bool __init retpoline_safe(uint64_t caps)
 {
 unsigned int ucode_rev = this_cpu(ucode_cpu_info).cpu_sig.rev;
 
-if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
 return true;
 
 if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
@@ -612,7 +613,8 @@ int8_t __read_mostly opt_xpti_domu = -1;
 
 static __init void xpti_init_default(uint64_t caps)
 {
-if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
 caps = ARCH_CAPABILITIES_RDCL_NO;
 
 if ( caps & ARCH_CAPABILITIES_RDCL_NO )
-- 
2.7.4


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

[Xen-devel] [PATCH v2 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Pu Wen]

The PMU architecture for the Hygon Dhyana CPU is similar to the AMD
family 17h one. So add Hygon Dhyana support in vpmu_arch_initialise
and vpmu_init by using the code path of AMD.

Since current Xen vPMU still not support Zen(0x17), so add both 0x17
and 0x18 support by using the 0x15's case in amd_vpmu_init, for 0x17
and 0x18 have the same performance event select and counter MSRs as
0x15 has.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/cpu/vpmu.c | 2 ++
 xen/arch/x86/cpu/vpmu_amd.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 13da7d0..f679e79 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -459,6 +459,7 @@ static int vpmu_arch_initialise(struct vcpu *v)
 switch ( vendor )
 {
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 ret = svm_vpmu_initialise(v);
 break;
 
@@ -876,6 +877,7 @@ static int __init vpmu_init(void)
 switch ( vendor )
 {
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 if ( amd_vpmu_init() )
vpmu_mode = XENPMU_MODE_OFF;
 break;
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index 5efc39b..c9abe6e 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
 switch ( current_cpu_data.x86 )
 {
 case 0x15:
+case 0x17:
+case 0x18:
 num_counters = F15H_NUM_COUNTERS;
 counters = AMD_F15H_COUNTERS;
 ctrls = AMD_F15H_CTRLS;
-- 
2.7.4


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

[Xen-devel] [PATCH v2 02/14] x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2

[Pu Wen]

The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon
Dhyana support to print the value of TOP_MEM2.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/cpu/mtrr/generic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index 8f9cf1b..94ee7d6 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -217,8 +217,9 @@ static void __init print_mtrr_state(const char *level)
printk("%s  %u disabled\n", level, i);
}
 
-   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD
-   && boot_cpu_data.x86 >= 0xf) {
+   if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
+boot_cpu_data.x86 >= 0xf) ||
+boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
uint64_t syscfg, tom2;
 
rdmsrl(MSR_K8_SYSCFG, syscfg);
-- 
2.7.4


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

[Xen-devel] [PATCH v2 00/14] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

As a new x86 CPU Vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
is a Joint Venture between AMD and Haiguang Information Technology Co.,
Ltd., and aims at providing high performance x86 processor for China
server market.

The first generation Hygon's processor(Dhyana) originates from AMD
technology and shares most of the architecture with AMD's family 17h,
but with different CPU vendor ID("HygonGenuine") and family series
number: 18h (Hygon will negotiate with AMD to make sure that only Hygon
will use family 18h).

To enable support of Xen to Hygon Dhyana CPU, we add a new vendor type
(X86_VENDOR_HYGON, with value of 5), and share most of the codes with
AMD family 17h.

This patch series have been applied and tested successfully on Hygon
Dhyana processor. Also tested on AMD EPYC (family 17h) processor, it
works fine and makes no harm to the existing codes.


v1->v2:
  - Rebased on 4.20.0-rc3 and tested against it.
  - Move opt_cpuid_mask_l7s0_(eax/ebx) to common.c.
  - Insert Hygon cases after AMD ones instead of above.
  - Remove (rd/wr)msr_hygon_safe and use (rd/wr)msr_safe instead.
  - Remove wrmsr_hygon and use wrmsrl instead.
  - Remove the unnecessary change to xstate.
  - Refine some codes and comments.
  - Add Acked-by from Jan Beulich for x86/traps.
  - Add Acked-by from Wei Liu for tools/libxc.


Pu Wen (14):
  x86/cpu: Create Hygon Dhyana architecture support file
  x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2
  x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU
  x86/cpu/mce: Add Hygon Dhyana support to the MCA infrastructure
  x86/spec_ctrl: Add Hygon Dhyana to the respective mitigation machinery
  x86/apic: Add Hygon Dhyana support
  x86/acpi: Add Hygon Dhyana support
  x86/iommu: Add Hygon Dhyana support
  x86/pv: Add Hygon Dhyana support to emulate MSRs access
  x86/domain: Add Hygon Dhyana support
  x86/domctl: Add Hygon Dhyana support
  x86/traps: Add Hygon Dhyana support
  x86/cpuid: Add Hygon Dhyana support
  tools/libxc: Add Hygon Dhyana support

 tools/libxc/xc_cpuid_x86.c |  16 ++-
 xen/arch/x86/acpi/cpu_idle.c   |   3 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c|   8 +-
 xen/arch/x86/acpi/cpufreq/powernow.c   |   3 +-
 xen/arch/x86/apic.c|   5 +
 xen/arch/x86/cpu/Makefile  |   1 +
 xen/arch/x86/cpu/amd.c |   5 -
 xen/arch/x86/cpu/common.c  |   9 +-
 xen/arch/x86/cpu/cpu.h |   2 +
 xen/arch/x86/cpu/hygon.c   | 248 +
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c |   5 +-
 xen/arch/x86/cpu/mcheck/mce.c  |   6 +-
 xen/arch/x86/cpu/mcheck/mce_amd.c  |   5 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c|   3 +-
 xen/arch/x86/cpu/mcheck/vmce.c |   2 +
 xen/arch/x86/cpu/mtrr/generic.c|   5 +-
 xen/arch/x86/cpu/vpmu.c|   2 +
 xen/arch/x86/cpu/vpmu_amd.c|   2 +
 xen/arch/x86/cpuid.c   |  10 +-
 xen/arch/x86/dom0_build.c  |   3 +-
 xen/arch/x86/domain.c  |   9 +-
 xen/arch/x86/domctl.c  |  13 +-
 xen/arch/x86/pv/emul-priv-op.c |  19 ++-
 xen/arch/x86/spec_ctrl.c   |   6 +-
 xen/arch/x86/traps.c   |   3 +
 xen/include/asm-x86/iommu.h|   1 +
 xen/include/asm-x86/x86-vendors.h  |   3 +-
 27 files changed, 354 insertions(+), 43 deletions(-)
 create mode 100644 xen/arch/x86/cpu/hygon.c

-- 
2.7.4


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

[Xen-devel] [PATCH v2 04/14] x86/cpu/mce: Add Hygon Dhyana support to the MCA infrastructure

[Pu Wen]

The machine check architecture for Hygon Dhyana CPU is similar to the
AMD family 17h one. Add vendor checking for Hygon Dhyana to share the
code path of AMD family 17h.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/cpu/common.c  | 3 ++-
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c | 5 +++--
 xen/arch/x86/cpu/mcheck/mce.c  | 6 --
 xen/arch/x86/cpu/mcheck/mce_amd.c  | 5 -
 xen/arch/x86/cpu/mcheck/non-fatal.c| 3 ++-
 xen/arch/x86/cpu/mcheck/vmce.c | 2 ++
 6 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 5bab845..214bdb5 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -350,7 +350,8 @@ static void __init early_cpu_detect(void)
hap_paddr_bits = PADDR_BITS;
}
 
-   if (c->x86_vendor != X86_VENDOR_AMD)
+   if (c->x86_vendor != X86_VENDOR_AMD &&
+   c->x86_vendor != X86_VENDOR_HYGON)
park_offline_cpus = opt_mce;
 
initialize_cpu_data(0);
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c 
b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 222f539..589dac5 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -203,10 +203,11 @@ static void mce_amd_work_fn(void *data)
 
 void __init amd_nonfatal_mcheck_init(struct cpuinfo_x86 *c)
 {
-   if (c->x86_vendor != X86_VENDOR_AMD)
+   if (c->x86_vendor != X86_VENDOR_AMD &&
+   c->x86_vendor != X86_VENDOR_HYGON)
return;
 
-   /* Assume we are on K8 or newer AMD CPU here */
+   /* Assume we are on K8 or newer AMD or Hygon CPU here */
 
/* The threshold bitfields in MSR_IA32_MC4_MISC has
 * been introduced along with the SVME feature bit. */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 30cdb06..0798dea 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -778,6 +778,7 @@ void mcheck_init(struct cpuinfo_x86 *c, bool bsp)
 switch ( c->x86_vendor )
 {
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 inited = amd_mcheck_init(c);
 break;
 
@@ -1172,10 +1173,11 @@ static bool x86_mc_msrinject_verify(struct 
xen_mc_msrinject *mci)
 
 /* MSRs that the HV will take care of */
 case MSR_K8_HWCR:
-if ( c->x86_vendor == X86_VENDOR_AMD )
+if ( c->x86_vendor == X86_VENDOR_AMD ||
+ c->x86_vendor == X86_VENDOR_HYGON )
 reason = "HV will operate HWCR";
 else
-reason = "only supported on AMD";
+reason = "only supported on AMD or Hygon";
 break;
 
 default:
diff --git a/xen/arch/x86/cpu/mcheck/mce_amd.c 
b/xen/arch/x86/cpu/mcheck/mce_amd.c
index d125bc1..040e449 100644
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c
@@ -274,7 +274,10 @@ enum mcheck_type
 amd_mcheck_init(struct cpuinfo_x86 *ci)
 {
 uint32_t i;
-enum mcequirk_amd_flags quirkflag = mcequirk_lookup_amd_quirkdata(ci);
+enum mcequirk_amd_flags quirkflag = 0;
+
+if (ci->x86_vendor != X86_VENDOR_HYGON)
+quirkflag = mcequirk_lookup_amd_quirkdata(ci);
 
 /* Assume that machine check support is available.
  * The minimum provided support is at least the K8. */
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c 
b/xen/arch/x86/cpu/mcheck/non-fatal.c
index d12e8f2..77be418 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -101,7 +101,8 @@ static int __init init_nonfatal_mce_checker(void)
 */
switch (c->x86_vendor) {
case X86_VENDOR_AMD:
-   /* Assume we are on K8 or newer AMD CPU here */
+   case X86_VENDOR_HYGON:
+   /* Assume we are on K8 or newer AMD or Hygon CPU here */
amd_nonfatal_mcheck_init(c);
break;
 
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index f15835e..4f5de07 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -154,6 +154,7 @@ static int bank_mce_rdmsr(const struct vcpu *v, uint32_t 
msr, uint64_t *val)
 break;
 
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 ret = vmce_amd_rdmsr(v, msr, val);
 break;
 
@@ -284,6 +285,7 @@ static int bank_mce_wrmsr(struct vcpu *v, uint32_t msr, 
uint64_t val)
 break;
 
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 ret = vmce_amd_wrmsr(v, msr, val);
 break;
 
-- 
2.7.4


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

[Xen-devel] [PATCH v2 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

Add x86 architecture support for a new processor: Hygon Dhyana Family
18h. Carve out initialization codes from amd.c needed by Dhyana into a
separate file hygon.c by removing unnecessary codes and make Hygon
initialization codes more clear.

To identify Hygon Dhyana CPU, add a new vendor type X86_VENDOR_HYGON
for system recognition.

As opt_cpuid_mask_l7s0_eax and opt_cpuid_mask_l7s0_ebx are used by both
AMD and Hygon, so move them to common.c.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/cpu/Makefile |   1 +
 xen/arch/x86/cpu/amd.c|   5 -
 xen/arch/x86/cpu/common.c |   6 +
 xen/arch/x86/cpu/cpu.h|   2 +
 xen/arch/x86/cpu/hygon.c  | 248 ++
 xen/include/asm-x86/x86-vendors.h |   3 +-
 6 files changed, 259 insertions(+), 6 deletions(-)
 create mode 100644 xen/arch/x86/cpu/hygon.c

diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index 34a01ca..1db7d88 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -8,4 +8,5 @@ obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
 obj-y += shanghai.o
+obj-y += hygon.o
 obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index c790416..4c595cf 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -32,11 +32,6 @@
 static char __initdata opt_famrev[14];
 string_param("cpuid_mask_cpu", opt_famrev);
 
-static unsigned int __initdata opt_cpuid_mask_l7s0_eax = ~0u;
-integer_param("cpuid_mask_l7s0_eax", opt_cpuid_mask_l7s0_eax);
-static unsigned int __initdata opt_cpuid_mask_l7s0_ebx = ~0u;
-integer_param("cpuid_mask_l7s0_ebx", opt_cpuid_mask_l7s0_ebx);
-
 static unsigned int __initdata opt_cpuid_mask_thermal_ecx = ~0u;
 integer_param("cpuid_mask_thermal_ecx", opt_cpuid_mask_thermal_ecx);
 
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index de6c5c9..5bab845 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -36,6 +36,11 @@ integer_param("cpuid_mask_ext_ecx", opt_cpuid_mask_ext_ecx);
 unsigned int opt_cpuid_mask_ext_edx = ~0u;
 integer_param("cpuid_mask_ext_edx", opt_cpuid_mask_ext_edx);
 
+unsigned int  opt_cpuid_mask_l7s0_eax = ~0u;
+integer_param("cpuid_mask_l7s0_eax", opt_cpuid_mask_l7s0_eax);
+unsigned int  opt_cpuid_mask_l7s0_ebx = ~0u;
+integer_param("cpuid_mask_l7s0_ebx", opt_cpuid_mask_l7s0_ebx);
+
 unsigned int __initdata expected_levelling_cap;
 unsigned int __read_mostly levelling_caps;
 
@@ -704,6 +709,7 @@ void __init early_cpu_init(void)
 {
intel_cpu_init();
amd_init_cpu();
+   hygon_init_cpu();
centaur_init_cpu();
shanghai_init_cpu();
early_cpu_detect();
diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h
index 2fcb931..9ea53e5 100644
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -13,11 +13,13 @@ extern bool_t opt_arat;
 extern unsigned int opt_cpuid_mask_ecx, opt_cpuid_mask_edx;
 extern unsigned int opt_cpuid_mask_xsave_eax;
 extern unsigned int opt_cpuid_mask_ext_ecx, opt_cpuid_mask_ext_edx;
+extern unsigned int opt_cpuid_mask_l7s0_eax, opt_cpuid_mask_l7s0_ebx;
 
 extern int get_model_name(struct cpuinfo_x86 *c);
 extern void display_cacheinfo(struct cpuinfo_x86 *c);
 
 int intel_cpu_init(void);
 int amd_init_cpu(void);
+int hygon_init_cpu(void);
 int centaur_init_cpu(void);
 int shanghai_init_cpu(void);
diff --git a/xen/arch/x86/cpu/hygon.c b/xen/arch/x86/cpu/hygon.c
new file mode 100644
index 000..3e79441
--- /dev/null
+++ b/xen/arch/x86/cpu/hygon.c
@@ -0,0 +1,248 @@
+#include 
+#include 
+#include 
+#include 
+
+#include "cpu.h"
+
+/*
+ * Sets caps in expected_levelling_cap, probes for the specified mask MSR, and
+ * set caps in levelling_caps if it is found.  Returns the default value.
+ */
+static uint64_t __init _probe_mask_msr(unsigned int msr, uint64_t caps)
+{
+   uint64_t value;
+
+   expected_levelling_cap |= caps;
+
+   if ((rdmsr_safe(msr, value) == 0) && (wrmsr_safe(msr, value) == 0))
+   levelling_caps |= caps;
+
+   return value;
+}
+
+/* Probe for the existance of the expected masking MSRs. */
+static void __init noinline probe_masking_msrs(void)
+{
+   const struct cpuinfo_x86 *c = _cpu_data;
+
+   /* Work out which masking MSRs we should have. */
+   cpuidmask_defaults._1cd =
+   _probe_mask_msr(MSR_K8_FEATURE_MASK, LCAP_1cd);
+   cpuidmask_defaults.e1cd =
+   _probe_mask_msr(MSR_K8_EXT_FEATURE_MASK, LCAP_e1cd);
+   if (c->cpuid_level >= 7)
+   cpuidmask_defaults._7ab0 =
+   _probe_mask_msr(MSR_AMD_L7S0_FEATURE_MASK, LCAP_7ab0);
+}
+
+/*
+ * Context switch CPUID masking state to the next domain.  Only called if
+ * CPUID Faulting isn't available, but masking MSRs have been detected.  A
+ * parameter of NULL is used to context switch to the default host state (by
+ * the cpu bringup-code, crash path, etc).
+ */
+static void 

Re: [Xen-devel] [PATCH SpectreV1+L1TF v7 4/9] nospec: introduce evaluate_nospec

[Julien Grall]

Hi Norbert,

On 21/02/2019 08:16, Norbert Manthey wrote:
> diff --git a/xen/include/asm-arm/nospec.h b/xen/include/asm-arm/nospec.h
> new file mode 100644
> --- /dev/null
> +++ b/xen/include/asm-arm/nospec.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright 2018 Amazon.com, Inc. or its affiliates. All Rights Reserved. */
> +
> +#ifndef _ASM_ARM_NOSPEC_H
> +#define _ASM_ARM_NOSPEC_H
> +
> +#define evaluate_nospec(condition) (condition)
> +
> +#define block_speculation()

NIT: Could you turn this to a static inline?

With that for the Arm code:

Acked-by: Julien Grall 

Cheers,

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

Re: [Xen-devel] [PATCH v3 11/25] xen: Let xencons_send() take a 'size' argument

[Paul Durrant]

> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> Sent: 20 February 2019 01:02
> To: qemu-de...@nongnu.org; Prasad J Pandit ; Marc-
> André Lureau ; Paolo Bonzini
> 
> Cc: Jason Wang ; Anthony Perard
> ; qemu-...@nongnu.org; Stefan Berger
> ; David Gibson ; Gerd
> Hoffmann ; Zhang Chen ; xen-
> de...@lists.xenproject.org; Cornelia Huck ; Samuel
> Thibault ; Christian Borntraeger
> ; Amit Shah ; Li Zhijian
> ; Corey Minyard ; Michael S.
> Tsirkin ; Paul Durrant ; Halil
> Pasic ; Stefano Stabellini ;
> qemu-s3...@nongnu.org; Pavel Dovgalyuk ;
> Philippe Mathieu-Daudé 
> Subject: [PATCH v3 11/25] xen: Let xencons_send() take a 'size' argument
> 
> The single caller of xencons_send(), con_event() already use the
> difference 'con->buffer.size - con->buffer.consumed'.
> Deduplicate by passing the difference as an argument.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/char/xen_console.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> index 91f34ef06c..083b2c8e2a 100644
> --- a/hw/char/xen_console.c
> +++ b/hw/char/xen_console.c
> @@ -144,11 +144,10 @@ static void xencons_receive(void *opaque, const
> uint8_t *buf, int len)
>  xen_pv_send_notify(>xendev);
>  }
> 
> -static void xencons_send(struct XenConsole *con)
> +static void xencons_send(struct XenConsole *con, ssize_t size)
>  {
> -ssize_t len, size;
> +ssize_t len;
> 
> -size = con->buffer.size - con->buffer.consumed;
>  if (qemu_chr_fe_backend_connected(>chr)) {
>  len = qemu_chr_fe_write(>chr,
>  con->buffer.data + con->buffer.consumed,
> @@ -280,10 +279,13 @@ static void con_disconnect(struct XenLegacyDevice
> *xendev)
>  static void con_event(struct XenLegacyDevice *xendev)
>  {
>  struct XenConsole *con = container_of(xendev, struct XenConsole,
> xendev);
> +ssize_t size;
> 
>  buffer_append(con);
> -if (con->buffer.size - con->buffer.consumed)
> -xencons_send(con);
> +size = con->buffer.size - con->buffer.consumed;
> +if (size) {
> +xencons_send(con, size);
> +}

You introduce this here, only to modify it in patch #12. Why not squash the two 
together?

  Paul

>  }
> 
>  /* 
> */
> --
> 2.20.1

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

[Xen-devel] [freebsd-master test] 133325: all pass - PUSHED

[osstest service owner]

flight 133325 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133325/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 freebsd  fa1581bf5c27168a1678fb252001ffcbc00f3b31
baseline version:
 freebsd  cdb7673abfefda182ace24a3abd1a04d1a16dd79

Last test of basis   133299  2019-02-18 09:19:16 Z3 days
Testing same since   133325  2019-02-20 09:19:24 Z1 days1 attempts


People who touched revisions under test:
  andrew 
  bapt 
  bcran 
  bde 
  br 
  cem 
  cperciva 
  dim 
  ed 
  emaste 
  ganbold 
  glebius 
  ian 
  imp 
  jilles 
  kib 
  markj 
  mckusick 
  ngie 
  pjd 
  sef 
  thj 
  trasz 
  tsoome 
  vmaffione 

jobs:
 build-amd64-freebsd-againpass
 build-amd64-freebsd  pass
 build-amd64-xen-freebsd  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/freebsd.git
   cdb7673abfe..fa1581bf5c2  fa1581bf5c27168a1678fb252001ffcbc00f3b31 -> 
tested/master

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

Re: [Xen-devel] xen/evtchn and forced threaded irq

[Roger Pau Monné]

On Thu, Feb 21, 2019 at 08:38:39AM +, Julien Grall wrote:
> Hi Roger,
> 
> On Thu, 21 Feb 2019, 08:08 Roger Pau Monné,  wrote:
> 
> > FWIW, you can also mask the interrupt while waiting for the thread to
> > execute the interrupt handler. Ie:
> >
> 
> Thank you for providing steps, however where would the masking be done? By
> the irqchip or a custom solution?

I'm not familiar with the irqchip infrastructure in Linux, what I
proposed below is what FreeBSD does when running interrupt handlers in
deferred threads IIRC.

If irqchip has a specific handler to dispatch to a thread, then that's
the place where the masking should happen. Likely, the unmasking
should be done by the irq handling infrastructure after the thread
executing the interrupt handler has finished.

Isn't there a similar way to handle interrupts in threads for Linux?

> 
> > 1. Interrupt injected
> > 2. Execute guest event channel callback
> > 3. Scan for pending interrupts
> > 4. Mask interrupt
> > 5. Clear pending field
> > 6. Queue threaded handler
> > 7. Go to 3 until all interrupts are drained
> > [...]
> > 8. Execute interrupt handler in thread
> > 9. Unmask interrupt
> >
> > That should prevent you from stacking interrupts?
> >
> > Roger.
> >

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

Re: [Xen-devel] xen/evtchn and forced threaded irq

[Juergen Gross]

On 21/02/2019 09:38, Julien Grall wrote:
> Hi Roger,
> 
> On Thu, 21 Feb 2019, 08:08 Roger Pau Monné,  > wrote:
> 
> FWIW, you can also mask the interrupt while waiting for the thread to
> execute the interrupt handler. Ie:
> 
> 
> Thank you for providing steps, however where would the masking be done?
> By the irqchip or a custom solution?

I'd go the irqchip route. This would be the least intrusive change
without the need for handling RT in a special way.


Juergen

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

Re: [Xen-devel] xen/evtchn and forced threaded irq

[Julien Grall]

Hi Roger,

On Thu, 21 Feb 2019, 08:08 Roger Pau Monné,  wrote:

> FWIW, you can also mask the interrupt while waiting for the thread to
> execute the interrupt handler. Ie:
>

Thank you for providing steps, however where would the masking be done? By
the irqchip or a custom solution?


> 1. Interrupt injected
> 2. Execute guest event channel callback
> 3. Scan for pending interrupts
> 4. Mask interrupt
> 5. Clear pending field
> 6. Queue threaded handler
> 7. Go to 3 until all interrupts are drained
> [...]
> 8. Execute interrupt handler in thread
> 9. Unmask interrupt
>
> That should prevent you from stacking interrupts?
>
> Roger.
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel