Re: [Xen-devel] [PATCH v2 05/11] vt-d: propagate IOMMU Device-TLB flush error up to IOMMU unmapping.
On April 19, 2016 2:51pm, Tian, Kevin wrote: > > From: Xu, Quan > > Sent: Monday, April 18, 2016 10:00 PM > > > > While IOMMU Device-TLB flush timed out, xen calls panic() at present. > > However the existing panic() is going to be eliminated, so we must > > propagate the IOMMU Device-TLB flush error up to IOMMU unmapping. > > Thought you don't need replicate the same reason in every patch. > clear enough to just keep last line. > That's good. I also hesitated to add this same reason. I'll drop it in next v3. Quan > > > > Signed-off-by: Quan Xu > > > > CC: Kevin Tian > > CC: Feng Wu > > CC: Jan Beulich > > Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-snapshot test] 44343: tolerable trouble: blocked/broken
flight 44343 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44343/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf-pvops 3 host-install(3) broken like 44321 build-armhf 3 host-install(3) broken like 44321 build-amd64 3 host-install(3) broken like 44321 build-i3863 host-install(3) broken like 44321 build-i386-pvops 3 host-install(3) broken like 44321 build-amd64-pvops 3 host-install(3) broken like 44321 Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-daily-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-daily-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-i386-i386-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-i386-i386-daily-netboot-pvgrub 1 build-check(1)blocked n/a test-amd64-i386-i386-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-daily-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-current-netinst-pygrub 1 build-check(1)blocked n/a test-amd64-amd64-i386-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-daily-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-weekly-netinst-pygrub 1 build-check(1) blocked n/a baseline version: flight 44321 jobs: build-amd64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-daily-netboot-pvgrub blocked test-amd64-i386-i386-daily-netboot-pvgrubblocked test-amd64-i386-amd64-daily-netboot-pygrub blocked test-armhf-armhf-armhf-daily-netboot-pygrub blocked test-amd64-amd64-i386-daily-netboot-pygrub blocked test-amd64-amd64-amd64-current-netinst-pygrubblocked test-amd64-i386-amd64-current-netinst-pygrub blocked test-amd64-amd64-i386-current-netinst-pygrub blocked test-amd64-i386-i386-current-netinst-pygrub blocked test-amd64-amd64-amd64-weekly-netinst-pygrub blocked test-amd64-i386-amd64-weekly-netinst-pygrub blocked test-amd64-amd64-i386-weekly-netinst-pygrub blocked test-amd64-i386-i386-weekly-netinst-pygrub blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv8] x86/ept: defer the invalidation until the p2m lock is released
Hi Wei,
This patch has all the required acks now. Can you consider it for 4.7?
It's a signficant scalability improvement (see the cover letter for
details).
v7 has been in XenServer's upcoming release for a while now so it has
been tested with many guests and many life cycle operations, including
plenty of uses of PoD.
Thanks.
David
On 12/04/2016 17:19, David Vrabel wrote:
> Holding the p2m lock while calling ept_sync_domain() is very expensive
> since it does an on_selected_cpus() call. IPIs on many socket
> machines can be very slow and on_selected_cpus() is serialized.
>
> It is safe to defer the invalidate until the p2m lock is released
> except for two cases:
>
> 1. When freeing a page table page (since partial translations may be
>cached).
> 2. When reclaiming a zero page as part of PoD.
>
> For these cases, add p2m_tlb_flush_sync() calls which will immediately
> perform the invalidate before the page is freed or reclaimed.
>
> Signed-off-by: David Vrabel
> ---
> v8:
> - p2m_tlb_flush_and_unlock() -> p2m_unlock_and_tlb_flush().
> - p2m_unlock_and_tlb_flush() now does the unlock and the p2m
> implementation need only provide a tlb_flush() op.
>
> v7:
> - Add some more p2m_tlb_flush_sync() calls to PoD.
> - More comments.
>
> v6:
> - Move p2m_tlb_flush_sync() to immediately before p2m_free_ptp(). It was
> called all the time otherwise.
>
> v5:
> - add p2m_tlb_flush_sync() and call it before freeing pgae table pages
> and reclaiming zeroed pod pages.
>
> v2:
> - use per-p2m list for deferred pages.
> - update synced_mask while holding write lock.
> ---
> xen/arch/x86/mm/mm-locks.h | 23 +++
> xen/arch/x86/mm/p2m-ept.c | 39 +++
> xen/arch/x86/mm/p2m-pod.c | 4
> xen/arch/x86/mm/p2m.c | 26 ++
> xen/include/asm-x86/p2m.h | 22 ++
> 5 files changed, 98 insertions(+), 16 deletions(-)
>
> diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
> index 8a40986..086c8bb 100644
> --- a/xen/arch/x86/mm/mm-locks.h
> +++ b/xen/arch/x86/mm/mm-locks.h
> @@ -265,14 +265,21 @@ declare_mm_lock(altp2mlist)
> */
>
> declare_mm_rwlock(altp2m);
> -#define p2m_lock(p) \
> -{ \
> -if ( p2m_is_altp2m(p) ) \
> -mm_write_lock(altp2m, &(p)->lock); \
> -else\
> -mm_write_lock(p2m, &(p)->lock); \
> -}
> -#define p2m_unlock(p) mm_write_unlock(&(p)->lock);
> +#define p2m_lock(p) \
> +do {\
> +if ( p2m_is_altp2m(p) ) \
> +mm_write_lock(altp2m, &(p)->lock); \
> +else\
> +mm_write_lock(p2m, &(p)->lock); \
> +(p)->defer_flush++; \
> +} while (0)
> +#define p2m_unlock(p) \
> +do {\
> +if ( --(p)->defer_flush == 0 ) \
> +p2m_unlock_and_tlb_flush(p);\
> +else\
> +mm_write_unlock(&(p)->lock);\
> +} while (0)
> #define gfn_lock(p,g,o) p2m_lock(p)
> #define gfn_unlock(p,g,o) p2m_unlock(p)
> #define p2m_read_lock(p) mm_read_lock(p2m, &(p)->lock)
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index 3cb6868..1ed5b47 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -264,6 +264,7 @@ static void ept_free_entry(struct p2m_domain *p2m,
> ept_entry_t *ept_entry, int l
> unmap_domain_page(epte);
> }
>
> +p2m_tlb_flush_sync(p2m);
> p2m_free_ptp(p2m, mfn_to_page(ept_entry->mfn));
> }
>
> @@ -1096,15 +1097,10 @@ static void __ept_sync_domain(void *info)
> */
> }
>
> -void ept_sync_domain(struct p2m_domain *p2m)
> +static void ept_sync_domain_prepare(struct p2m_domain *p2m)
> {
> struct domain *d = p2m->domain;
> struct ept_data *ept = &p2m->ept;
> -/* Only if using EPT and this domain has some VCPUs to dirty. */
> -if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
> -return;
> -
> -ASSERT(local_irq_is_enabled());
>
> if ( nestedhvm_enabled(d) && !p2m_is_nestedp2m(p2m) )
> p2m_flush_nestedp2m(d);
> @@ -1117,9 +1113,35 @@ void ept_sync_domain(struct p2m_domain *p2m)
> *of an EP4TA reuse is still needed.
> */
> cpumask_setall(ept->invalidate);
> +}
> +
> +static void ept_sync_domain_mask(struct p2m_domain *p2m, const cpumask_t
> *mask)
> +{
> +on_selected_cpus(mask, __ept_sync_domain, p2m, 1);
> +}
> +
> +void ept_sync_domain(struct p2m_domain *p2m)
> +{
> +struct domain *d = p2m->domain;
>
> -on_selected_cpus(d->domain_dirty_cpumask,
> - __ept_sync_domain, p2
[Xen-devel] [qemu-mainline test] 91987: tolerable FAIL - PUSHED
flight 91987 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/91987/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt 9 debian-install fail in 91935 pass in 91987 test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail pass in 91935 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-installfail REGR. vs. 91608 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 91608 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 91608 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuu92b674b62a1aec734280c9019cfb3b3745044b66 baseline version: qemuuc7b45f12828c1ba7105dbc029c63d7de68eaa91c Last test of basis91608 2016-04-16 05:33:07 Z3 days Failing since 91886 2016-04-18 10:02:33 Z0 days3 attempts Testing same since91935 2016-04-18 17:51:02 Z0 days2 attempts People who touched revisions under test: Andreas Färber David Gibson Denis V. Lunev Dr. David Alan Gilbert Eduardo Habkost Eduardo Otubo Eric Blake Fam Zheng James Hogan Jeff Cody Kevin Wolf Laszlo Ersek Mark Cave-Ayland Max Reitz Michael Fritscher Miroslav Rezanina Paolo Bonzini Pavel Butsykin Peter Maydell Sascha Silbe Stefan Hajnoczi Stefan Weil Thomas Huth jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops
[Xen-devel] [libvirt test] 92004: regressions - FAIL
flight 92004 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/92004/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 91479 build-i386-libvirt5 libvirt-build fail REGR. vs. 91479 build-armhf-libvirt 5 libvirt-build fail REGR. vs. 91479 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt aca4d72b2a7f08fa93c29fec10875c1c45886f86 baseline version: libvirt 8b62c65d24bdb20121d3147b4f4dc98bac4f024b Last test of basis91479 2016-04-15 05:33:51 Z4 days Failing since 91597 2016-04-16 04:20:46 Z3 days4 attempts Testing same since92004 2016-04-19 04:26:08 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Cole Robinson Dmitry Andreev Erik Skultety Jason J. Herne Jim Fehlig Jiri Denemark John Ferlan Ján Tomko Martin Kletzander Maxim Nestratov Michal Privoznik Nitesh Konkar Nitesh Konkar Olga Krishtal Peter Krempa Richard Laager Richard W.M. Jones jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-armhf-armhf-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 797 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 01/11] vt-d: fix the IOMMU flush issue
On April 19, 2016 2:33pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > The propagation value from IOMMU flush interfaces may be positive,
> > which indicates callers need to flush cache, not one of faliures.
> >
> > when the propagation value is positive, this patch fixes this flush
> > issue as follows:
> > - call iommu_flush_write_buffer() to flush cache.
> > - return zero.
> >
> > Signed-off-by: Quan Xu
> >
> > CC: Kevin Tian
> > CC: Feng Wu
> > CC: Keir Fraser
> > CC: Jan Beulich
> > CC: Andrew Cooper
> > ---
> > xen/drivers/passthrough/vtd/iommu.c | 94
> > -
> > xen/include/asm-x86/iommu.h | 2 +-
> > 2 files changed, 63 insertions(+), 33 deletions(-)
> >
> > diff --git a/xen/drivers/passthrough/vtd/iommu.c
> > b/xen/drivers/passthrough/vtd/iommu.c
> > index 5ad25dc..50d98ac 100644
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -558,14 +558,16 @@ static void iommu_flush_all(void)
> > }
> > }
> >
> > -static void __intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> > -int dma_old_pte_present, unsigned int page_count)
> > +static int iommu_flush_iotlb(struct domain *d, unsigned long gfn,
>
> any reason for the renaming here?
>
As Jan mentioned,
"this would be a good opportunity to also drop the stray double underscores:
You need to touch all callers anyway."
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02456.html
think twice, I dropped the stray double underscores.
both intel_iommu_iotlb_flush and iommu_iotlb_flush were already in use,
So I tried to rename it to ' iommu_flush_iotlb'.
> > + int dma_old_pte_present,
> > + unsigned int page_count)
> > {
> > struct hvm_iommu *hd = domain_hvm_iommu(d);
> > struct acpi_drhd_unit *drhd;
> > struct iommu *iommu;
> > int flush_dev_iotlb;
> > int iommu_domid;
> > +int rc = 0;
> >
> > /*
> > * No need pcideves_lock here because we have flush @@ -584,29
> > +586,34 @@ static void __intel_iommu_iotlb_flush(struct domain *d,
> > unsigned long gfn,
> > continue;
> >
> > if ( page_count != 1 || gfn == INVALID_GFN )
> > -{
> > -if ( iommu_flush_iotlb_dsi(iommu, iommu_domid,
> > -0, flush_dev_iotlb) )
> > -iommu_flush_write_buffer(iommu);
> > -}
> > +rc = iommu_flush_iotlb_dsi(iommu, iommu_domid,
> > + 0, flush_dev_iotlb);
> > else
> > +rc = iommu_flush_iotlb_psi(iommu, iommu_domid,
> > + (paddr_t)gfn <<
> PAGE_SHIFT_4K,
> > + PAGE_ORDER_4K,
> > + !dma_old_pte_present,
> > + flush_dev_iotlb);
> > +
> > +if ( rc > 0 )
> > {
> > -if ( iommu_flush_iotlb_psi(iommu, iommu_domid,
> > -(paddr_t)gfn << PAGE_SHIFT_4K,
> PAGE_ORDER_4K,
> > -!dma_old_pte_present, flush_dev_iotlb) )
> > -iommu_flush_write_buffer(iommu);
> > -}
> > +iommu_flush_write_buffer(iommu);
> > +rc = 0;
> > +} else if ( rc < 0 )
> > +break;
> > }
> > +
> > +return rc;
> > }
> >
> > static void intel_iommu_iotlb_flush(struct domain *d, unsigned long
> > gfn, unsigned int
> > page_count)
> > {
> > -__intel_iommu_iotlb_flush(d, gfn, 1, page_count);
> > +iommu_flush_iotlb(d, gfn, 1, page_count);
> > }
> >
> > static void intel_iommu_iotlb_flush_all(struct domain *d) {
> > -__intel_iommu_iotlb_flush(d, INVALID_GFN, 0, 0);
> > +iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
> > }
>
> Do you plan to change return value of above 2 functions in another patch, or
> will keep it current form w/o propagation?
>
Change return value of above 2 functions in another patches.
> >
> > /* clear one page's page table */
> > @@ -640,7 +647,7 @@ static void dma_pte_clear_one(struct domain
> *domain, u64 addr)
> > iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
> >
> > if ( !this_cpu(iommu_dont_flush_iotlb) )
> > -__intel_iommu_iotlb_flush(domain, addr >> PAGE_SHIFT_4K, 1, 1);
> > +iommu_flush_iotlb(domain, addr >> PAGE_SHIFT_4K, 1, 1);
> >
> > unmap_vtd_domain_page(page);
> > }
> > @@ -1281,6 +1288,7 @@ int domain_context_mapping_one(
> > u64 maddr, pgd_maddr;
> > u16 seg = iommu->intel->drhd->segment;
> > int agaw;
> > +int rc;
> >
> > ASSERT(pcidevs_locked());
> > spin_lock(&iommu->lock);
> > @@ -1394,13 +1402,19 @@ int domain_context_mapping_one(
> > spin_unlock(&iommu->lock);
> >
> > /* Context entry was previously non-present (with domid 0). */
> > -if ( iommu_flush_co
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> -Original Message- > From: Tian, Kevin [mailto:kevin.t...@intel.com] > Sent: 19 April 2016 05:51 > To: Yu, Zhang; Jan Beulich; Paul Durrant; Nakajima, Jun > Cc: Andrew Cooper; George Dunlap; Lv, Zhiyuan; xen-devel@lists.xen.org; > Keir (Xen.org); Tim (Xen.org) > Subject: RE: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to > map guest ram with p2m_ioreq_server to an ioreq server > > > From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > > Sent: Thursday, April 14, 2016 5:57 PM > > > And with all three bits now possibly being clear, aren't we risking > > > the > > > entries to be mis-treated as not-present ones? > > > > Hah. You got me. Thanks! :) > > Now I realized it would be difficult if we wanna to emulate the read > > operations for HVM. According to Intel mannual, entry->r is to be > > cleared, so should entry->w if we do not want ept misconfig. And > > with both read and write permissions being forbidden, entry->x can > be > > set only on processors with EXECUTE_ONLY capability. > > To avoid any entry to be mis-treated as not-present. We have several > > solutions: > > a> do not support the read emulation for now - we have no such > usage > > case; > > b> add the check of p2m_t against p2m_ioreq_server in > is_epte_present - > > a bit weird to me. > > Which one do you prefer? or any other suggestions? > > >>> > > >>> That question would also need to be asked to others who had > > >>> suggested supporting both. I'd be fine with a, but I also don't view > > >>> b as too awkward. > > >> > > >> According to Intel mannual, an entry is regarded as not present, if > > >> bit0:2 is 0. So adding a p2m type check in is_epte_present() means we > > >> will change its semantics, if this is acceptable(with no hurt to > > >> hypervisor). I'd prefer option b> > > > > > > Perhaps time for the VMX maintainers to chime in - such a change is > acceptable > > > only if it doesn't result in changed hardware behavior. I can't think of > > > any > such off > > > the top of my head, but this really should be confirmed by the > maintainers before > > > deciding to go such a route. > > > > > > > Thanks, Jan. :) > > Jun & Kevin, any suggestions? > > > > I'm a bit worried about this change, since it's a fundamental EPT > interface. Can we avoid supporting read emulation now? > I'm happy to drop the implementation of read emulation for the moment to keep things simple, as long as it is kept in the interface. Paul > Thanks > Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Update SeaBIOS to include 8a0df3
On Mon, Apr 18, 2016 at 09:26:17AM +0100, Doug Goldstein wrote: > On 4/15/16 10:29 AM, Roger Pau Monné wrote: > > On Fri, Apr 15, 2016 at 10:19:49AM +0100, Wei Liu wrote: > >> On Thu, Apr 14, 2016 at 06:51:04PM +0200, Roger Pau Monné wrote: > >>> Hello, > >>> > >>> I would like to request an update of the SeaBIOS repository to include > >>> the > >>> latest commits in the 1.9-stable branch. I'm only interested in commit > >>> 8a0df3, which is basically our current version (rel-1.9.1) plus a build > >>> fix > >>> for FreeBSD (or for objcopy implementations that are strict regarding > >>> alignments). > >>> > >>> Would it be possible to push it to our SeaBIOS and update Config.mk, or > >>> now > >>> is too late? > >>> > >> > >> I can look into that. But I would wait until we get a push to master. > >> That has not happened for a month. > > > > No problem, it's not very important TBH, but it would be a "nice to have". > > > > Roger. > > > > We could also ask Kevin to do a 1.9.2 from the 1.9-stable branch. > There's one more commit on top of the one that Roger asked for in the > 1.9-stable branch. Hello, Kevin is hopefully going to tag 1.9.2 by the end of the week: https://www.coreboot.org/pipermail/seabios/2016-April/010615.html I guess we can pick it up then, if that's fine by everyone. It only contains two bugfixes on top of 1.9.1, so it should be fairly safe to update. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 08/11] IOMMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (leaf ones).
On April 19, 2016 2:58pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> > However the existing panic() is going to be eliminated, so we must
> > propagate the IOMMU Device-TLB flush error up to the
> iommu_iotlb_flush{,_all}.
> >
> > If IOMMU mapping and unmapping failed, the domain (with the exception
> > of the hardware domain) is crashed, treated as a fatal error. Rollback
> > can be lighter weight.
> >
> > This patch fixes the leaf ones.
>
> what about other leaves like AMD/ARM callbacks?
>
Thank you for reminding me of such cases. I really missed them in this v2.
Quan
> >
> > Signed-off-by: Quan Xu
> >
> > CC: Jan Beulich
> > CC: Kevin Tian
> > CC: Feng Wu
> > ---
> > xen/drivers/passthrough/iommu.c | 8 ++--
> > xen/drivers/passthrough/vtd/iommu.c | 8
> > xen/include/xen/iommu.h | 4 ++--
> > 3 files changed, 8 insertions(+), 12 deletions(-)
> >
> > diff --git a/xen/drivers/passthrough/iommu.c
> > b/xen/drivers/passthrough/iommu.c index 9254760..d44fc39 100644
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -308,9 +308,7 @@ int iommu_iotlb_flush(struct domain *d, unsigned
> > long gfn, unsigned int page_cou
> > if ( !iommu_enabled || !hd->platform_ops
> || !hd->platform_ops->iotlb_flush )
> > return 0;
> >
> > -hd->platform_ops->iotlb_flush(d, gfn, page_count);
> > -
> > -return 0;
> > +return hd->platform_ops->iotlb_flush(d, gfn, page_count);
> > }
> >
> > int iommu_iotlb_flush_all(struct domain *d) @@ -320,9 +318,7 @@ int
> > iommu_iotlb_flush_all(struct domain *d)
> > if ( !iommu_enabled || !hd->platform_ops
> || !hd->platform_ops->iotlb_flush_all )
> > return 0;
> >
> > -hd->platform_ops->iotlb_flush_all(d);
> > -
> > -return 0;
> > +return hd->platform_ops->iotlb_flush_all(d);
> > }
> >
> > int __init iommu_setup(void)
> > diff --git a/xen/drivers/passthrough/vtd/iommu.c
> > b/xen/drivers/passthrough/vtd/iommu.c
> > index 5cc70ca..930661a 100644
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -606,14 +606,14 @@ static int iommu_flush_iotlb(struct domain *d,
> > unsigned long gfn,
> > return rc;
> > }
> >
> > -static void intel_iommu_iotlb_flush(struct domain *d, unsigned long
> > gfn, unsigned int
> > page_count)
> > +static int intel_iommu_iotlb_flush(struct domain *d, unsigned long
> > +gfn, unsigned int
> > page_count)
> > {
> > -iommu_flush_iotlb(d, gfn, 1, page_count);
> > +return iommu_flush_iotlb(d, gfn, 1, page_count);
> > }
> >
> > -static void intel_iommu_iotlb_flush_all(struct domain *d)
> > +static int intel_iommu_iotlb_flush_all(struct domain *d)
> > {
> > -iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
> > +return iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
> > }
> >
> > /* clear one page's page table */
> > diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h index
> > ff4608d..ca1c409 100644
> > --- a/xen/include/xen/iommu.h
> > +++ b/xen/include/xen/iommu.h
> > @@ -161,8 +161,8 @@ struct iommu_ops {
> > void (*resume)(void);
> > void (*share_p2m)(struct domain *d);
> > void (*crash_shutdown)(void);
> > -void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int
> page_count);
> > -void (*iotlb_flush_all)(struct domain *d);
> > +int (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int
> page_count);
> > +int (*iotlb_flush_all)(struct domain *d);
> > int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
> > void (*dump_p2m_table)(struct domain *d); };
> > --
> > 1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Hackathon 16] Notes from Security Session
On 4/18/16 12:20 PM, Lars Kurth wrote: > Hi all, > > I took notes as much as I could. CC'ed the people who participated most. If I > missed/misrepresented something, please add to the discussion. I know that > George for example took some extra notes in the one or other area. > > Regards > Lars > > == Topics discussed == > QEMU > De-privilige of QEMU > XSA > x-Splice > x86 Emulator > Enabling XSM By default > > === Slimline QEMU === > > Konrad: Some inroads on making QEMU better > Konrad: QEMU is too big and it is hard to strip down the platform : how can > we chop it up > > Wei: Wei attempted this 2 years ago : Wei defined some Xen stub CPU model, > which was rejected at the time > Stefano: Maybe what we need is different > Stefano: Containers / Intel have similar issues > Stefano: Intel have a very similar problem with ClearContainer > Stefano: Re-implementing ClearContainers with QEMU because of market needs > Stefano: QEMU does have already a no-default option > > Doug: In the QEMU model: you cannot run a board without a CPU > Doug: KConfig may be acceptable, but re4moving boards may not (initially > discussed with Antony L) > > George: Distros don't want to ship two versions of QEMU > George: Compile configurability doesn't help with distros > > Konrad: PVH/HVMLite does not use QEMU (or only as a back) > > Lars: If we had a proposal, working with Intel and the QEMU community, we > could discuss at Xen Summit / KVM Forum is co-located > > James: If we had a future with OVMF, then we probably wouldn't need QEMU (aka > if you want security use PVH with OVMF) > James: Proposal for security conscious applications we could fork and use a > stubbed out version of QEMU > > Options: > - KConfig > - Run-time disablement > - Xen Summit / KVM Forum > - Intel work / collaboration > - PIX3 > 935 > - OVMF > - Remove xl.cfg (stop configs - in fact we probably only can print a warning > "this is not secure and has no security support" or something similar) > > Doug: Issue > - For example Oracle could deal with Config > - BUT, this approach won't work for distros > > ACTION: Konrad is volunteering to drive this discussion > > === De-privilige Qemu === > Konrad: What's the status > Stefano: not done, you need > - QEMU as non-root (that is in 4.7 and QEMU part is there) > - Now you still have a libxc and xenstore interface that needs to be > de-priviliged > - There is a patch for QEMI and xenstore to deal with the libxc part (not > upstreamed) ... pretty big series, but won't make it for 4.7 - QEMU part is > tiny > - Libxc is sizeable (Ian Campbell was working on it), but it is now dormant > : QEMU support is there, but Dom0 interface is missing > - Ideas: Do registration in Dom0 > [George has some additional notes] > > ISSUE: A proposal and a plan, but nobody to do this. Without this what we > have is not useful > Andrew: XenServer still using qemu-trad because of some gaps in emu-upstream > Andrew: XS may end up working on this at some undefined point in the future > > There is a problem with using CD drive's to open ISOs as you need to be > privileged to do this > Andy Cooper: there may be real end-user issues > Stefano: Could change ownership > Doug: Issue was tried to be fixed in libvirt and went nowhere > Andy: Qemu-trad does it wrong (QEMU in libxenlight does not do that) > > ACTION: High;right lack of owner > > Konrad: Seccomp may work > Doug: everything has to be passed as file descriptor > > === Narrower XSA Coverage === > Jan: XSA 77 (whitelisted a set of dom control and sys control) which are > supposedly ... http://xenbits.xen.org/xsa/advisory-77.html > See http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt (Security > Status of dom0 disaggregation) > Jan: Who runs this in production: running part of toolstack not in Dom0 - > OpenXT wants to do this > Jan: The observation is that we went to far with the XSA 77 => if we had a > shorter whitelist, and reduce whitelist > Jan: If there was agreement, then the security team > would not handle issues in these areas as XSA's > > Ross Phillipson: Typic ally we have only higher level stuff in a different > xl, but lower level stuff runs on Dom0. So there should be no issue > > George: QEMU stub domains should have security support > George: There are a whole set of other things, which we don't know whether > they are used > George: Do we want to security support of disaggregated tools-stub > > Agreed: Propose patch to change > http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt on the list > Jan: We can only discuss in public if no issues are pending > Cc: Christopher Clark , Ross Philipson > , Daniel Smith > CC the folks on this thread or ope...@googlegroups.com (OpenXT mailing list) > > === x86 Emulation de-privilige === > Anthony is working on it > Stefano: I think you had some measurements > Anthony: Measurements were not very good > Andrew: If you are introspecting, you sacrifice 70%
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
On 4/18/2016 11:57 PM, Paul Durrant wrote: -Original Message- From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 14 April 2016 11:45 To: George Dunlap; Paul Durrant; xen-devel@lists.xen.org Cc: Jan Beulich; Kevin Tian; Andrew Cooper; Lv, Zhiyuan; Tim (Xen.org); jun.nakaj...@intel.com Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server On 4/11/2016 7:15 PM, Yu, Zhang wrote: On 4/8/2016 7:01 PM, George Dunlap wrote: On 08/04/16 11:10, Yu, Zhang wrote: [snip] BTW, I noticed your reply has not be CCed to mailing list, and I also wonder if we should raise this last question in community? Oops -- that was a mistake on my part. :-) I appreciate the discretion; just so you know in the future, if I'm purposely changing the CC list (removing xen-devel and/or adding extra people), I'll almost always say so at the top of the mail. And then of course there's the p2m_ioreq_server -> p2m_ram_logdirty transition -- I assume that live migration is incompatible with this functionality? Is there anything that prevents a live migration from being started when there are outstanding p2m_ioreq_server entries? Another good question, and the answer is unfortunately yes. :-) If live migration happens during the normal emulation process, entries marked with p2m_ioreq_server will be changed to p2m_log_dirty in resolve_misconfig(), and later write operations will change them to p2m_ram_rw, thereafter these pages can not be forwarded to device model. From this point of view, this functionality is incompatible with live migration. But for XenGT, I think this is acceptable, because, if live migration is to be supported in the future, intervention from backend device model will be necessary. At that time, we can guarantee from the device model side that there's no outdated p2m_ioreq_server entries, hence no need to reset the p2m type back to p2m_ram_rw(and do not include p2m_ioreq_server in the P2M_CHANGEABLE_TYPES). By "outdated", I mean when an ioreq server is detached from p2m_ioreq_server, or before an ioreq server is attached to this type, entries marked with p2m_ioreq_server should be regarded as outdated. Is this acceptible to you? Any suggestions? So the question is, as of this series, what happens if someone tries to initiate a live migration while there are outstanding p2m_ioreq_server entries? If the answer is "the ioreq server suddenly loses all control of the memory", that's something that needs to be changed. Sorry, for this patch series, I'm afraid the above description is the answer. Besides, I find it's hard to change current code to both support the deferred resetting of p2m_ioreq_server and the live migration at the same time. One reason is that a page with p2m_ioreq_server behaves differently in different situations. My assumption of XenGT is that, for live migration to work, the device model should guarantee there's no outstanding p2m_ioreq_server pages in hypervisor(no need to use the deferred recalculation), and it is our device model who should be responsible for the copying of the write protected guest pages later. And another solution I can think of: when unmapping the ioreq server, we walk the p2m table and reset entries with p2m_ioreq_server back directly, instead of deferring the reset. And of course, this means performance impact. But since the mapping and unmapping of an ioreq server is not a frequent one, the performance penalty may be acceptable. How do you think about this approach? George, sorry to bother you. Any comments on above option? :) Another choice might be to let live migration fail if there's outstanding p2m_ioreq_server entries. But I'm not quite inclined to do so, because: 1> I'd still like to keep live migration feature for XenGT. 2> Not easy to know if there's outstanding p2m_ioreq_server entries. I mean, since p2m type change is not only triggered by hypercall, to keep a counter for remaining p2m_ioreq_server entries means a lot code changes; Besides, I wonder whether the requirement to reset the p2m_ioreq_server is indispensable, could we let the device model side to be responsible for this? The worst case I can imagine for device model failing to do so is that operations of a gfn might be delivered to a wrong device model. I'm not clear what kind of damage would this cause to the hypervisor or other VM. Does any other maintainers have any suggestions? Note that it is a requirement that an ioreq server be disabled before VM suspend. That means ioreq server pages essentially have to go back to ram_rw semantics. Paul OK. So it should be hypervisor's responsibility to do the resetting. Now we probably have 2 choices: 1> we reset the p2m type synchronously when ioreq server unmapping happens, instead of deferring to the misconfig handling part. This means performance impact to traverse the p2m table. Or 2> we just disallow live migration when p2
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
On 4/19/2016 12:50 PM, Tian, Kevin wrote: From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: Thursday, April 14, 2016 5:57 PM And with all three bits now possibly being clear, aren't we risking the entries to be mis-treated as not-present ones? Hah. You got me. Thanks! :) Now I realized it would be difficult if we wanna to emulate the read operations for HVM. According to Intel mannual, entry->r is to be cleared, so should entry->w if we do not want ept misconfig. And with both read and write permissions being forbidden, entry->x can be set only on processors with EXECUTE_ONLY capability. To avoid any entry to be mis-treated as not-present. We have several solutions: a> do not support the read emulation for now - we have no such usage case; b> add the check of p2m_t against p2m_ioreq_server in is_epte_present - a bit weird to me. Which one do you prefer? or any other suggestions? That question would also need to be asked to others who had suggested supporting both. I'd be fine with a, but I also don't view b as too awkward. According to Intel mannual, an entry is regarded as not present, if bit0:2 is 0. So adding a p2m type check in is_epte_present() means we will change its semantics, if this is acceptable(with no hurt to hypervisor). I'd prefer option b> Perhaps time for the VMX maintainers to chime in - such a change is acceptable only if it doesn't result in changed hardware behavior. I can't think of any such off the top of my head, but this really should be confirmed by the maintainers before deciding to go such a route. Thanks, Jan. :) Jun & Kevin, any suggestions? I'm a bit worried about this change, since it's a fundamental EPT interface. Can we avoid supporting read emulation now? Thanks for your reply, Kevin. For XenGT, either waY would be fine. But I do not think changing is_epte_present will introduce any bug. Paul, do you have any preference? Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> -Original Message- [snip] > >> Does any other maintainers have any suggestions? > > > > Note that it is a requirement that an ioreq server be disabled before VM > suspend. That means ioreq server pages essentially have to go back to > ram_rw semantics. > > > >Paul > > > > OK. So it should be hypervisor's responsibility to do the resetting. > Now we probably have 2 choices: > 1> we reset the p2m type synchronously when ioreq server unmapping > happens, instead of deferring to the misconfig handling part. This > means performance impact to traverse the p2m table. > Do we need to reset at all. The p2m type does need to be transferred, it will just be unclaimed on the far end (i.e. the pages are treated as r/w ram) until the emulator starts up there. If that cannot be done without creating yet another p2m type to handle logdirty (which seems a suboptimal way of dealing with it) then I think migration needs to be disallowed on any domain than contains any ioreq_server type pages at this stage. Paul > Or > 2> we just disallow live migration when p2m->ioreq.server is not NULL. > This is not quite accurate, because having p2m->ioreq.server mapped > to p2m_ioreq_server does not necessarily means there would be such > outstanding entries. To be more accurate, we can add some other rough > check, e.g. both check if p2m->ioreq.server against NULL and check if > the hvmop_set_mem_type has ever been triggered once for the > p2m_ioreq_server type. > > Both choice seems suboptimal for me. And I wonder if we have any > better solutions? > > Thanks > Yu > > >> Thanks in advance! :) > If the answer is, "everything just works", that's perfect. > > If the answer is, "Before logdirty mode is set, the ioreq server has the > opportunity to detach, removing the p2m_ioreq_server entries, and > operating without that functionality", that's good too. > > If the answer is, "the live migration request fails and the guest > continues to run", that's also acceptable. If you want this series to > be checked in today (the last day for 4.7), this is probably your best > bet. > > -George > > > > >>> > >> > >> Regards > >> Yu > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> -Original Message- > From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: 19 April 2016 10:15 > To: Kevin Tian; Jan Beulich; Paul Durrant; Nakajima, Jun > Cc: Keir (Xen.org); George Dunlap; Andrew Cooper; Tim (Xen.org); xen- > de...@lists.xen.org; Lv, Zhiyuan > Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to > map guest ram with p2m_ioreq_server to an ioreq server > > > > On 4/19/2016 12:50 PM, Tian, Kevin wrote: > >> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > >> Sent: Thursday, April 14, 2016 5:57 PM > >>> And with all three bits now possibly being clear, aren't we risking > the > >>> entries to be mis-treated as not-present ones? > >> > >> Hah. You got me. Thanks! :) > >> Now I realized it would be difficult if we wanna to emulate the read > >> operations for HVM. According to Intel mannual, entry->r is to be > >> cleared, so should entry->w if we do not want ept misconfig. And > >> with both read and write permissions being forbidden, entry->x can > be > >> set only on processors with EXECUTE_ONLY capability. > >> To avoid any entry to be mis-treated as not-present. We have > several > >> solutions: > >> a> do not support the read emulation for now - we have no such > usage > >> case; > >> b> add the check of p2m_t against p2m_ioreq_server in > is_epte_present - > >> a bit weird to me. > >> Which one do you prefer? or any other suggestions? > > > > That question would also need to be asked to others who had > > suggested supporting both. I'd be fine with a, but I also don't view > > b as too awkward. > > According to Intel mannual, an entry is regarded as not present, if > bit0:2 is 0. So adding a p2m type check in is_epte_present() means we > will change its semantics, if this is acceptable(with no hurt to > hypervisor). I'd prefer option b> > >>> > >>> Perhaps time for the VMX maintainers to chime in - such a change is > acceptable > >>> only if it doesn't result in changed hardware behavior. I can't think of > >>> any > such off > >>> the top of my head, but this really should be confirmed by the > maintainers before > >>> deciding to go such a route. > >>> > >> > >> Thanks, Jan. :) > >> Jun & Kevin, any suggestions? > >> > > > > I'm a bit worried about this change, since it's a fundamental EPT > > interface. Can we avoid supporting read emulation now? > > > > Thanks for your reply, Kevin. > For XenGT, either waY would be fine. But I do not think changing > is_epte_present will introduce any bug. > > Paul, do you have any preference? > Unless the code is nailed down in the next couple of days then I don't think any implementation is going to make it into 4.7 so I'd prefer to go with the simplest option, and not supporting read emulation makes things a lot simpler. Paul > Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
On 4/19/2016 12:37 PM, Tian, Kevin wrote: From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: Thursday, April 14, 2016 6:45 PM On 4/11/2016 7:15 PM, Yu, Zhang wrote: On 4/8/2016 7:01 PM, George Dunlap wrote: On 08/04/16 11:10, Yu, Zhang wrote: [snip] BTW, I noticed your reply has not be CCed to mailing list, and I also wonder if we should raise this last question in community? Oops -- that was a mistake on my part. :-) I appreciate the discretion; just so you know in the future, if I'm purposely changing the CC list (removing xen-devel and/or adding extra people), I'll almost always say so at the top of the mail. And then of course there's the p2m_ioreq_server -> p2m_ram_logdirty transition -- I assume that live migration is incompatible with this functionality? Is there anything that prevents a live migration from being started when there are outstanding p2m_ioreq_server entries? Another good question, and the answer is unfortunately yes. :-) If live migration happens during the normal emulation process, entries marked with p2m_ioreq_server will be changed to p2m_log_dirty in resolve_misconfig(), and later write operations will change them to p2m_ram_rw, thereafter these pages can not be forwarded to device model. From this point of view, this functionality is incompatible with live migration. But for XenGT, I think this is acceptable, because, if live migration is to be supported in the future, intervention from backend device model will be necessary. At that time, we can guarantee from the device model side that there's no outdated p2m_ioreq_server entries, hence no need to reset the p2m type back to p2m_ram_rw(and do not include p2m_ioreq_server in the P2M_CHANGEABLE_TYPES). By "outdated", I mean when an ioreq server is detached from p2m_ioreq_server, or before an ioreq server is attached to this type, entries marked with p2m_ioreq_server should be regarded as outdated. Is this acceptible to you? Any suggestions? So the question is, as of this series, what happens if someone tries to initiate a live migration while there are outstanding p2m_ioreq_server entries? If the answer is "the ioreq server suddenly loses all control of the memory", that's something that needs to be changed. Sorry, for this patch series, I'm afraid the above description is the answer. Besides, I find it's hard to change current code to both support the deferred resetting of p2m_ioreq_server and the live migration at the same time. One reason is that a page with p2m_ioreq_server behaves differently in different situations. My assumption of XenGT is that, for live migration to work, the device model should guarantee there's no outstanding p2m_ioreq_server pages in hypervisor(no need to use the deferred recalculation), and it is our device model who should be responsible for the copying of the write protected guest pages later. And another solution I can think of: when unmapping the ioreq server, we walk the p2m table and reset entries with p2m_ioreq_server back directly, instead of deferring the reset. And of course, this means performance impact. But since the mapping and unmapping of an ioreq server is not a frequent one, the performance penalty may be acceptable. How do you think about this approach? George, sorry to bother you. Any comments on above option? :) Another choice might be to let live migration fail if there's outstanding p2m_ioreq_server entries. But I'm not quite inclined to do so, because: 1> I'd still like to keep live migration feature for XenGT. 2> Not easy to know if there's outstanding p2m_ioreq_server entries. I mean, since p2m type change is not only triggered by hypercall, to keep a counter for remaining p2m_ioreq_server entries means a lot code changes; Besides, I wonder whether the requirement to reset the p2m_ioreq_server is indispensable, could we let the device model side to be responsible for this? The worst case I can imagine for device model failing to do so is that operations of a gfn might be delivered to a wrong device model. I'm not clear what kind of damage would this cause to the hypervisor or other VM. Does any other maintainers have any suggestions? Thanks in advance! :) I'm not sure how above is working. In pre-copy phase (where logdirty is concerned), the device model is still actively serving requests from guest, including initiating new write-protection requests. How can you guarantee draining of outstanding p2m_ioreq_server entries w/o actually freezing device model (while freezing device model means guest driver might be blocked with random errors)? You are right, and I'm not suggesting to clear the p2m_ioreq_server entries when live migration happens. My suggestion is that either we guarantee there is no outstanding p2m_ioreq_server entries right after the ioreq server is unbounded, or do not support live migration for now. :) B.R. Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org ht
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
On 4/19/2016 4:46 PM, Paul Durrant wrote: -Original Message- From: Tian, Kevin [mailto:kevin.t...@intel.com] Sent: 19 April 2016 05:51 To: Yu, Zhang; Jan Beulich; Paul Durrant; Nakajima, Jun Cc: Andrew Cooper; George Dunlap; Lv, Zhiyuan; xen-devel@lists.xen.org; Keir (Xen.org); Tim (Xen.org) Subject: RE: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: Thursday, April 14, 2016 5:57 PM And with all three bits now possibly being clear, aren't we risking the entries to be mis-treated as not-present ones? Hah. You got me. Thanks! :) Now I realized it would be difficult if we wanna to emulate the read operations for HVM. According to Intel mannual, entry->r is to be cleared, so should entry->w if we do not want ept misconfig. And with both read and write permissions being forbidden, entry->x can be set only on processors with EXECUTE_ONLY capability. To avoid any entry to be mis-treated as not-present. We have several solutions: a> do not support the read emulation for now - we have no such usage case; b> add the check of p2m_t against p2m_ioreq_server in is_epte_present - a bit weird to me. Which one do you prefer? or any other suggestions? That question would also need to be asked to others who had suggested supporting both. I'd be fine with a, but I also don't view b as too awkward. According to Intel mannual, an entry is regarded as not present, if bit0:2 is 0. So adding a p2m type check in is_epte_present() means we will change its semantics, if this is acceptable(with no hurt to hypervisor). I'd prefer option b> Perhaps time for the VMX maintainers to chime in - such a change is acceptable only if it doesn't result in changed hardware behavior. I can't think of any such off the top of my head, but this really should be confirmed by the maintainers before deciding to go such a route. Thanks, Jan. :) Jun & Kevin, any suggestions? I'm a bit worried about this change, since it's a fundamental EPT interface. Can we avoid supporting read emulation now? I'm happy to drop the implementation of read emulation for the moment to keep things simple, as long as it is kept in the interface. Thanks, Paul. So what's the benefit to keep the read in the interface, if we can not support its emulation? It could be easier to change the is_epte_present definition than to remove the read emulation code, but either way would not be difficult. Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> -Original Message- > From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: 19 April 2016 10:27 > To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun > Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen- > de...@lists.xen.org; Lv, Zhiyuan > Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to > map guest ram with p2m_ioreq_server to an ioreq server > > > > On 4/19/2016 4:46 PM, Paul Durrant wrote: > >> -Original Message- > >> From: Tian, Kevin [mailto:kevin.t...@intel.com] > >> Sent: 19 April 2016 05:51 > >> To: Yu, Zhang; Jan Beulich; Paul Durrant; Nakajima, Jun > >> Cc: Andrew Cooper; George Dunlap; Lv, Zhiyuan; xen- > de...@lists.xen.org; > >> Keir (Xen.org); Tim (Xen.org) > >> Subject: RE: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to > >> map guest ram with p2m_ioreq_server to an ioreq server > >> > >>> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > >>> Sent: Thursday, April 14, 2016 5:57 PM > And with all three bits now possibly being clear, aren't we risking > the > entries to be mis-treated as not-present ones? > >>> > >>> Hah. You got me. Thanks! :) > >>> Now I realized it would be difficult if we wanna to emulate the read > >>> operations for HVM. According to Intel mannual, entry->r is to be > >>> cleared, so should entry->w if we do not want ept misconfig. And > >>> with both read and write permissions being forbidden, entry->x > can > >> be > >>> set only on processors with EXECUTE_ONLY capability. > >>> To avoid any entry to be mis-treated as not-present. We have > several > >>> solutions: > >>> a> do not support the read emulation for now - we have no such > >> usage > >>> case; > >>> b> add the check of p2m_t against p2m_ioreq_server in > >> is_epte_present - > >>> a bit weird to me. > >>> Which one do you prefer? or any other suggestions? > >> > >> That question would also need to be asked to others who had > >> suggested supporting both. I'd be fine with a, but I also don't view > >> b as too awkward. > > > > According to Intel mannual, an entry is regarded as not present, if > > bit0:2 is 0. So adding a p2m type check in is_epte_present() means we > > will change its semantics, if this is acceptable(with no hurt to > > hypervisor). I'd prefer option b> > > Perhaps time for the VMX maintainers to chime in - such a change is > >> acceptable > only if it doesn't result in changed hardware behavior. I can't think of > any > >> such off > the top of my head, but this really should be confirmed by the > >> maintainers before > deciding to go such a route. > > >>> > >>> Thanks, Jan. :) > >>> Jun & Kevin, any suggestions? > >>> > >> > >> I'm a bit worried about this change, since it's a fundamental EPT > >> interface. Can we avoid supporting read emulation now? > >> > > > > I'm happy to drop the implementation of read emulation for the moment > to keep things simple, as long as it is kept in the interface. > > > > Thanks, Paul. > So what's the benefit to keep the read in the interface, if we can > not support its emulation? > Well, if it's in the interface then support can be added in future. If it's not in the interface then it needs to be added later and that makes things more awkward compatibility-wise. Paul > It could be easier to change the is_epte_present definition than > to remove the read emulation code, but either way would not be > difficult. > > Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
On 4/19/2016 5:21 PM, Paul Durrant wrote: -Original Message- [snip] Does any other maintainers have any suggestions? Note that it is a requirement that an ioreq server be disabled before VM suspend. That means ioreq server pages essentially have to go back to ram_rw semantics. Paul OK. So it should be hypervisor's responsibility to do the resetting. Now we probably have 2 choices: 1> we reset the p2m type synchronously when ioreq server unmapping happens, instead of deferring to the misconfig handling part. This means performance impact to traverse the p2m table. Do we need to reset at all. The p2m type does need to be transferred, it will just be unclaimed on the far end (i.e. the pages are treated as r/w ram) until the emulator starts up there. If that cannot be done without creating yet another p2m type to handle logdirty (which seems a suboptimal way of dealing with it) then I think migration needs to be disallowed on any domain than contains any ioreq_server type pages at this stage. Paul Yes. We need - either the device model or hypervisor should grantee there's no p2m_ioreq_server pages left after an ioreq server is unmapped from this type (which is write protected in such senario), otherwise its emulation might be forwarded to other unexpected device models which claims the p2m_ioreq_server later. So I guess approach 2> is your suggestion now. Besides, previously, Jan also questioned the necessity of resetting the p2m type when an ioreq server is mapping to the p2m_ioreq_server. His argument is that we should only allow such p2m transition after an ioreq server has already mapped to this p2m_ioreq_server. I think his point sounds also reasonable. Thanks Yu Or 2> we just disallow live migration when p2m->ioreq.server is not NULL. This is not quite accurate, because having p2m->ioreq.server mapped to p2m_ioreq_server does not necessarily means there would be such outstanding entries. To be more accurate, we can add some other rough check, e.g. both check if p2m->ioreq.server against NULL and check if the hvmop_set_mem_type has ever been triggered once for the p2m_ioreq_server type. Both choice seems suboptimal for me. And I wonder if we have any better solutions? Thanks Yu Thanks in advance! :) If the answer is, "everything just works", that's perfect. If the answer is, "Before logdirty mode is set, the ioreq server has the opportunity to detach, removing the p2m_ioreq_server entries, and operating without that functionality", that's good too. If the answer is, "the live migration request fails and the guest continues to run", that's also acceptable. If you want this series to be checked in today (the last day for 4.7), this is probably your best bet. -George Regards Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
On 4/19/2016 5:40 PM, Paul Durrant wrote: -Original Message- From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 19 April 2016 10:27 To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen- de...@lists.xen.org; Lv, Zhiyuan Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server On 4/19/2016 4:46 PM, Paul Durrant wrote: -Original Message- From: Tian, Kevin [mailto:kevin.t...@intel.com] Sent: 19 April 2016 05:51 To: Yu, Zhang; Jan Beulich; Paul Durrant; Nakajima, Jun Cc: Andrew Cooper; George Dunlap; Lv, Zhiyuan; xen- de...@lists.xen.org; Keir (Xen.org); Tim (Xen.org) Subject: RE: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: Thursday, April 14, 2016 5:57 PM And with all three bits now possibly being clear, aren't we risking the entries to be mis-treated as not-present ones? Hah. You got me. Thanks! :) Now I realized it would be difficult if we wanna to emulate the read operations for HVM. According to Intel mannual, entry->r is to be cleared, so should entry->w if we do not want ept misconfig. And with both read and write permissions being forbidden, entry->x can be set only on processors with EXECUTE_ONLY capability. To avoid any entry to be mis-treated as not-present. We have several solutions: a> do not support the read emulation for now - we have no such usage case; b> add the check of p2m_t against p2m_ioreq_server in is_epte_present - a bit weird to me. Which one do you prefer? or any other suggestions? That question would also need to be asked to others who had suggested supporting both. I'd be fine with a, but I also don't view b as too awkward. According to Intel mannual, an entry is regarded as not present, if bit0:2 is 0. So adding a p2m type check in is_epte_present() means we will change its semantics, if this is acceptable(with no hurt to hypervisor). I'd prefer option b> Perhaps time for the VMX maintainers to chime in - such a change is acceptable only if it doesn't result in changed hardware behavior. I can't think of any such off the top of my head, but this really should be confirmed by the maintainers before deciding to go such a route. Thanks, Jan. :) Jun & Kevin, any suggestions? I'm a bit worried about this change, since it's a fundamental EPT interface. Can we avoid supporting read emulation now? I'm happy to drop the implementation of read emulation for the moment to keep things simple, as long as it is kept in the interface. Thanks, Paul. So what's the benefit to keep the read in the interface, if we can not support its emulation? Well, if it's in the interface then support can be added in future. If it's not in the interface then it needs to be added later and that makes things more awkward compatibility-wise. Paul But if we need to support read emulation in the future, we'll have to clear bit0:2 in ept pte, which is the same situation we are facing now. So why do we not support it now? Sorry for seeming so stubborn, I just want to have some more convincing explanations. :) Yu It could be easier to change the is_epte_present definition than to remove the read emulation code, but either way would not be difficult. Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Hackathon 16] Notes from Security Session
On 19/04/16 10:02, Doug Goldstein wrote: On 4/18/16 12:20 PM, Lars Kurth wrote: Hi all, I took notes as much as I could. CC'ed the people who participated most. If I missed/misrepresented something, please add to the discussion. I know that George for example took some extra notes in the one or other area. Regards Lars == Topics discussed == QEMU De-privilige of QEMU XSA x-Splice x86 Emulator Enabling XSM By default === Slimline QEMU === Konrad: Some inroads on making QEMU better Konrad: QEMU is too big and it is hard to strip down the platform : how can we chop it up Wei: Wei attempted this 2 years ago : Wei defined some Xen stub CPU model, which was rejected at the time Stefano: Maybe what we need is different Stefano: Containers / Intel have similar issues Stefano: Intel have a very similar problem with ClearContainer Stefano: Re-implementing ClearContainers with QEMU because of market needs Stefano: QEMU does have already a no-default option Doug: In the QEMU model: you cannot run a board without a CPU Doug: KConfig may be acceptable, but re4moving boards may not (initially discussed with Antony L) George: Distros don't want to ship two versions of QEMU George: Compile configurability doesn't help with distros Konrad: PVH/HVMLite does not use QEMU (or only as a back) Lars: If we had a proposal, working with Intel and the QEMU community, we could discuss at Xen Summit / KVM Forum is co-located James: If we had a future with OVMF, then we probably wouldn't need QEMU (aka if you want security use PVH with OVMF) James: Proposal for security conscious applications we could fork and use a stubbed out version of QEMU Options: - KConfig - Run-time disablement - Xen Summit / KVM Forum - Intel work / collaboration - PIX3 > 935 - OVMF - Remove xl.cfg (stop configs - in fact we probably only can print a warning "this is not secure and has no security support" or something similar) Doug: Issue - For example Oracle could deal with Config - BUT, this approach won't work for distros ACTION: Konrad is volunteering to drive this discussion === De-privilige Qemu === Konrad: What's the status Stefano: not done, you need - QEMU as non-root (that is in 4.7 and QEMU part is there) - Now you still have a libxc and xenstore interface that needs to be de-priviliged - There is a patch for QEMI and xenstore to deal with the libxc part (not upstreamed) ... pretty big series, but won't make it for 4.7 - QEMU part is tiny - Libxc is sizeable (Ian Campbell was working on it), but it is now dormant : QEMU support is there, but Dom0 interface is missing - Ideas: Do registration in Dom0 [George has some additional notes] ISSUE: A proposal and a plan, but nobody to do this. Without this what we have is not useful Andrew: XenServer still using qemu-trad because of some gaps in emu-upstream Andrew: XS may end up working on this at some undefined point in the future There is a problem with using CD drive's to open ISOs as you need to be privileged to do this Andy Cooper: there may be real end-user issues Stefano: Could change ownership Doug: Issue was tried to be fixed in libvirt and went nowhere Andy: Qemu-trad does it wrong (QEMU in libxenlight does not do that) ACTION: High;right lack of owner Konrad: Seccomp may work Doug: everything has to be passed as file descriptor === Narrower XSA Coverage === Jan: XSA 77 (whitelisted a set of dom control and sys control) which are supposedly ... http://xenbits.xen.org/xsa/advisory-77.html See http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt (Security Status of dom0 disaggregation) Jan: Who runs this in production: running part of toolstack not in Dom0 - OpenXT wants to do this Jan: The observation is that we went to far with the XSA 77 => if we had a shorter whitelist, and reduce whitelist Jan: If there was agreement, then the security team would not handle issues in these areas as XSA's Ross Phillipson: Typic ally we have only higher level stuff in a different xl, but lower level stuff runs on Dom0. So there should be no issue George: QEMU stub domains should have security support George: There are a whole set of other things, which we don't know whether they are used George: Do we want to security support of disaggregated tools-stub Agreed: Propose patch to change http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt on the list Jan: We can only discuss in public if no issues are pending Cc: Christopher Clark , Ross Philipson , Daniel Smith CC the folks on this thread or ope...@googlegroups.com (OpenXT mailing list) === x86 Emulation de-privilige === Anthony is working on it Stefano: I think you had some measurements Anthony: Measurements were not very good Andrew: If you are introspecting, you sacrifice 70% performance Andrew: Patches were very complicated Andrew: Re-writing the emulator would only fix the outbound path Stefano: Risk would probably go from High/Critical to Low in terms of impact but not remove the is
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> -Original Message- > From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: 19 April 2016 10:49 > To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun > Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen- > de...@lists.xen.org; Lv, Zhiyuan > Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to > map guest ram with p2m_ioreq_server to an ioreq server > > > > On 4/19/2016 5:40 PM, Paul Durrant wrote: > >> -Original Message- > >> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > >> Sent: 19 April 2016 10:27 > >> To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun > >> Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen- > >> de...@lists.xen.org; Lv, Zhiyuan > >> Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to > >> map guest ram with p2m_ioreq_server to an ioreq server > >> > >> > >> > >> On 4/19/2016 4:46 PM, Paul Durrant wrote: > -Original Message- > From: Tian, Kevin [mailto:kevin.t...@intel.com] > Sent: 19 April 2016 05:51 > To: Yu, Zhang; Jan Beulich; Paul Durrant; Nakajima, Jun > Cc: Andrew Cooper; George Dunlap; Lv, Zhiyuan; xen- > >> de...@lists.xen.org; > Keir (Xen.org); Tim (Xen.org) > Subject: RE: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP > to > map guest ram with p2m_ioreq_server to an ioreq server > > > From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > > Sent: Thursday, April 14, 2016 5:57 PM > >> And with all three bits now possibly being clear, aren't we > risking > >> the > >> entries to be mis-treated as not-present ones? > > > > Hah. You got me. Thanks! :) > > Now I realized it would be difficult if we wanna to emulate the > read > > operations for HVM. According to Intel mannual, entry->r is to > be > > cleared, so should entry->w if we do not want ept misconfig. > And > > with both read and write permissions being forbidden, entry->x > >> can > be > > set only on processors with EXECUTE_ONLY capability. > > To avoid any entry to be mis-treated as not-present. We have > >> several > > solutions: > > a> do not support the read emulation for now - we have no such > usage > > case; > > b> add the check of p2m_t against p2m_ioreq_server in > is_epte_present - > > a bit weird to me. > > Which one do you prefer? or any other suggestions? > > That question would also need to be asked to others who had > suggested supporting both. I'd be fine with a, but I also don't view > b as too awkward. > >>> > >>> According to Intel mannual, an entry is regarded as not present, if > >>> bit0:2 is 0. So adding a p2m type check in is_epte_present() means > we > >>> will change its semantics, if this is acceptable(with no hurt to > >>> hypervisor). I'd prefer option b> > >> > >> Perhaps time for the VMX maintainers to chime in - such a change is > acceptable > >> only if it doesn't result in changed hardware behavior. I can't think > >> of > >> any > such off > >> the top of my head, but this really should be confirmed by the > maintainers before > >> deciding to go such a route. > >> > > > > Thanks, Jan. :) > > Jun & Kevin, any suggestions? > > > > I'm a bit worried about this change, since it's a fundamental EPT > interface. Can we avoid supporting read emulation now? > > >>> > >>> I'm happy to drop the implementation of read emulation for the > moment > >> to keep things simple, as long as it is kept in the interface. > >>> > >> > >> Thanks, Paul. > >> So what's the benefit to keep the read in the interface, if we can > >> not support its emulation? > >> > > > > Well, if it's in the interface then support can be added in future. If it's > > not in > the interface then it needs to be added later and that makes things more > awkward compatibility-wise. > > > >Paul > > > > But if we need to support read emulation in the future, we'll have to > clear bit0:2 in ept pte, which is the same situation we are facing > now. So why do we not support it now? > > Sorry for seeming so stubborn, I just want to have some more convincing > explanations. :) > That's an argument you need to have with Kevin. If he thinks the risk of making the change now is small then go ahead. All I'm saying is that 4.7 is about to go out of the door so whatever happens now needs to be as low risk and as minimally disruptive as possible. Paul > Yu > > >> It could be easier to change the is_epte_present definition than > >> to remove the read emulation code, but either way would not be > >> difficult. > >> > >> Yu > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > __
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
On 4/19/2016 6:01 PM, Paul Durrant wrote: -Original Message- From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 19 April 2016 10:49 To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen- de...@lists.xen.org; Lv, Zhiyuan Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server On 4/19/2016 5:40 PM, Paul Durrant wrote: -Original Message- From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 19 April 2016 10:27 To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen- de...@lists.xen.org; Lv, Zhiyuan Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server On 4/19/2016 4:46 PM, Paul Durrant wrote: -Original Message- From: Tian, Kevin [mailto:kevin.t...@intel.com] Sent: 19 April 2016 05:51 To: Yu, Zhang; Jan Beulich; Paul Durrant; Nakajima, Jun Cc: Andrew Cooper; George Dunlap; Lv, Zhiyuan; xen- de...@lists.xen.org; Keir (Xen.org); Tim (Xen.org) Subject: RE: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: Thursday, April 14, 2016 5:57 PM And with all three bits now possibly being clear, aren't we risking the entries to be mis-treated as not-present ones? Hah. You got me. Thanks! :) Now I realized it would be difficult if we wanna to emulate the read operations for HVM. According to Intel mannual, entry->r is to be cleared, so should entry->w if we do not want ept misconfig. And with both read and write permissions being forbidden, entry->x can be set only on processors with EXECUTE_ONLY capability. To avoid any entry to be mis-treated as not-present. We have several solutions: a> do not support the read emulation for now - we have no such usage case; b> add the check of p2m_t against p2m_ioreq_server in is_epte_present - a bit weird to me. Which one do you prefer? or any other suggestions? That question would also need to be asked to others who had suggested supporting both. I'd be fine with a, but I also don't view b as too awkward. According to Intel mannual, an entry is regarded as not present, if bit0:2 is 0. So adding a p2m type check in is_epte_present() means we will change its semantics, if this is acceptable(with no hurt to hypervisor). I'd prefer option b> Perhaps time for the VMX maintainers to chime in - such a change is acceptable only if it doesn't result in changed hardware behavior. I can't think of any such off the top of my head, but this really should be confirmed by the maintainers before deciding to go such a route. Thanks, Jan. :) Jun & Kevin, any suggestions? I'm a bit worried about this change, since it's a fundamental EPT interface. Can we avoid supporting read emulation now? I'm happy to drop the implementation of read emulation for the moment to keep things simple, as long as it is kept in the interface. Thanks, Paul. So what's the benefit to keep the read in the interface, if we can not support its emulation? Well, if it's in the interface then support can be added in future. If it's not in the interface then it needs to be added later and that makes things more awkward compatibility-wise. Paul But if we need to support read emulation in the future, we'll have to clear bit0:2 in ept pte, which is the same situation we are facing now. So why do we not support it now? Sorry for seeming so stubborn, I just want to have some more convincing explanations. :) That's an argument you need to have with Kevin. If he thinks the risk of making the change now is small then go ahead. All I'm saying is that 4.7 is about to go out of the door so whatever happens now needs to be as low risk and as minimally disruptive as possible. Got it. Thank you, Paul. :) Yu Paul Yu It could be easier to change the is_epte_present definition than to remove the read emulation code, but either way would not be difficult. Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> -Original Message- > From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: 19 April 2016 10:44 > To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org > Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; > jun.nakaj...@intel.com > Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to > map guest ram with p2m_ioreq_server to an ioreq server > > > > On 4/19/2016 5:21 PM, Paul Durrant wrote: > >> -Original Message- > > [snip] > Does any other maintainers have any suggestions? > >>> > >>> Note that it is a requirement that an ioreq server be disabled before VM > >> suspend. That means ioreq server pages essentially have to go back to > >> ram_rw semantics. > >>> > >>> Paul > >>> > >> > >> OK. So it should be hypervisor's responsibility to do the resetting. > >> Now we probably have 2 choices: > >> 1> we reset the p2m type synchronously when ioreq server unmapping > >> happens, instead of deferring to the misconfig handling part. This > >> means performance impact to traverse the p2m table. > >> > > > > Do we need to reset at all. The p2m type does need to be transferred, it > will just be unclaimed on the far end (i.e. the pages are treated as r/w ram) > until the emulator starts up there. If that cannot be done without creating > yet another p2m type to handle logdirty (which seems a suboptimal way of > dealing with it) then I think migration needs to be disallowed on any domain > than contains any ioreq_server type pages at this stage. > > > >Paul > > > > Yes. We need - either the device model or hypervisor should grantee > there's no p2m_ioreq_server pages left after an ioreq server is unmapped > from this type (which is write protected in such senario), otherwise > its emulation might be forwarded to other unexpected device models which > claims the p2m_ioreq_server later. That should be for the device model to guarantee IMO. If the 'wrong' emulator claims the ioreq server type then I don't think that's Xen's problem. > > So I guess approach 2> is your suggestion now. > > Besides, previously, Jan also questioned the necessity of resetting the > p2m type when an ioreq server is mapping to the p2m_ioreq_server. His > argument is that we should only allow such p2m transition after an > ioreq server has already mapped to this p2m_ioreq_server. I think his > point sounds also reasonable. > I was kind of hoping to avoid that ordering dependency but if it makes things simpler then so be it. Paul > Thanks > Yu > > >> Or > >> 2> we just disallow live migration when p2m->ioreq.server is not NULL. > >> This is not quite accurate, because having p2m->ioreq.server mapped > >> to p2m_ioreq_server does not necessarily means there would be such > >> outstanding entries. To be more accurate, we can add some other rough > >> check, e.g. both check if p2m->ioreq.server against NULL and check if > >> the hvmop_set_mem_type has ever been triggered once for the > >> p2m_ioreq_server type. > >> > >> Both choice seems suboptimal for me. And I wonder if we have any > >> better solutions? > >> > >> Thanks > >> Yu > >> > Thanks in advance! :) > >> If the answer is, "everything just works", that's perfect. > >> > >> If the answer is, "Before logdirty mode is set, the ioreq server has > the > >> opportunity to detach, removing the p2m_ioreq_server entries, and > >> operating without that functionality", that's good too. > >> > >> If the answer is, "the live migration request fails and the guest > >> continues to run", that's also acceptable. If you want this series to > >> be checked in today (the last day for 4.7), this is probably your best > >> bet. > >> > >> -George > >> > >> > >> > > > > Regards > Yu > >>> ___ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xen.org > >>> http://lists.xen.org/xen-devel > >>> ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8.1 04/27] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op
On Mon, Apr 18, 2016 at 10:33:46AM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk 04/18/16 9:50 AM >>>
> >On Sun, Apr 17, 2016 at 02:05:10AM -0600, Jan Beulich wrote:
> >> >>> Konrad Rzeszutek Wilk 04/15/16 4:29 AM >>>
> >> >On Thu, Apr 14, 2016 at 10:36:46AM -0600, Jan Beulich wrote:
> >> >> >>> Konrad Rzeszutek Wilk 04/14/16 12:05 AM >>>
> >> >> > +spin_lock(&payload_lock);
> >> >> > +
> >> >> > +found = find_payload(n);
> >> >> > +if ( IS_ERR(found) )
> >> >> > +{
> >> >> > +rc = PTR_ERR(found);
> >> >> > +goto out;
> >> >> > +}
> >> >> > +else if ( found )
> >> >> > +{
> >> >> > +rc = -EEXIST;
> >> >> > +goto out;
> >> >> > +}
> >> >> > +
> >> >> > +data = xzalloc(struct payload);
> >> >>
> >> >> I generally advocate for not doing allocations with locks held, and I
> >> >> don't think
> >> >> it would severely complicate the code here doing so.
> >> >
> >> >I can certainly unlock and then lock again (when adding
> >> >it to the list).
> >>
> >> That would create a race again afaict. Instead what I have been trying to
> >> hint
> >> at is that the allocation should be done before taking the lock, freeing
> >> the object
> >> again if in the end it turned out it's not going to be needed. Hence the
> >> referral to
> >
> >What if I get -ENOMEM and that the user supplied an payload we already
> >have? In that case I would return -ENOMEM while I would expect us to
> >return -EEXIST.
> >
> >Unless I add some extra checks to continue on?
>
> Or unless you didn't check the allocation result right after the allocation
> call,
> but only where you check it now.
Which is OK for data = xzalloc(struct payload);
That is not much data.
The issue is later (the 'Implement payload loading') is the allocation
of the raw_data which wants memory of size by ELF file.
This can be say 100kB or such.
>
> >Also one could do a bit of memory DoS (perhaps by mistake) by continously
> >uploading the same and same payload and us first allocating the memory,
> >and then doing the check for the payload existence (which would then
> >free the memory). Since the allocation is outside the lock we can
> >eat a bit of memory.
>
> Why that? You'd free the memory right away on the error path.
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Please Welcome our New Committer and Security Team members
Dear Community members, you may remember the following e-mail called "Call for nominations for new Hypervisor subproject maintainers and committers" (also see http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg03459.html) I am now pleased to confirm the following people as == New Committers == - Andrew Cooper - George Dunlap - Stefano Stabellini - Wei Liu == New Security Team Members == - Andrew Cooper - George Dunlap Best Regards Lars Kurth Xen Project Community Manager Chairman of Xen Project Advisory Board ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 91992: regressions - FAIL
flight 91992 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91992/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 0b42d7d8a34a99a02becf4dece78481d3cd2b2fc baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 133 days Failing since 65593 2015-12-08 23:44:51 Z 132 days 159 attempts Testing same since91992 2016-04-19 02:15:32 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19657 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [Hackathon 16] Notes from "Clarifying Maintainership" discussion
= Topics Discussed = - Clarifying ACKing rules and conventions - ACK on Xen and Linux have different meaning : or do they? - Patches sent by a maintainer (with no ACK from another maintainer) - Explain tooling / working patterns which make it easier for contributors see whether a patch made it in - Rest MAINTAINERS - Encouraging More Reviewers - Coding checking tools == Maintainership Discussion == Jan: I am confused what the meaning of a MAINTAINER is The MAINTAINERS file does not clearly specifics of how the file works For example, if I write a file for shadow code, I can interpret the maintainer file - such that only Tim can ACK it - such that x86 may ACK it - such that arch 86/mm may ACK it Some of this needs to be spelled out Also the stricter view (aka there is no flexibility and ACKs always need to be achieved), leads to delays George: Is doing more reviews, than in the past because he is now maintainer So, thus being clearer as to who has to do what, means people are more motivated to review Julien: Sometimes the Maintainers file isn't granular enough (e.g. on ARM code sometimes existing maintainers do not have a board to verify a piece of code) Stefano: Sometimes we may not need, but need somebody who tests and verifies the board during the release cycle and can be CC'ed if there is an issue on an unusual board Andy: more patches than not on x86, require 3 or more ACKs (it is thus moderately difficult to do changes which require less than 3 people maintainers to get engaged) George: Is this a problem? David: Do we need to formalise or can we rely more on trust, e.g. if for example something in MM code looks trivial, we could let x86 maintainers in a more relaxed interpretation). But for more intrusive things we we would always refer to a specialist. We would allow a higher level maintainer to be sufficient. George: We could follow a lazy consensus model, e.g. if there wasn't a response in a week / 2 weeks Andy: We had a clear example with APIC when the sub maintainer was away on holidays and we had a critical issue Andy: The default state of the tree should be working, because if it isn't development stops. Thus we do Lars: How do other communities deal with this? Stefano: In Linux, there is a person for the whole thing, then one for the subset. Default is that person for the subset ACKs the subset and the super maintainer can override. E.g. Sarah > Greg > Linux (if the change breaks you can skip an chain element) Andy: You can do this in Linux by collecting ACKs David: This happens in parallel Andy: Do we have a problem? Way forward: * Checking something in without a subsystem maintainers ACK should be exceptional * BUT, we should have a way forward in exceptional cases (e.g. non-response by sub maintainer, people being on holidays, active delegation, ...) Konrad: ACK on Xen and Linux have different meaning Stefano: No it is the same Stefano: Linux => Reviewed-by implies ACK-ed by, ACK-ed by could mean that maintainer trusts Jan: Normally don't ACK patches I didn't review Jan: If there is a submaintainer, I don't need to ACK ** Seems we have a way forward ** Lars: Who is going to make a concrete proposal to the list ACTION: maybe add a paragraph in the maintainers file explaining (George volunteered) Konrad: What if a maintainer sends out a patch and it didn't get an ACK by another maintainer Stefano/Andy/George: Give it a week, a committer should be able to check it in Lars: comes down to the exceptional thing Julien: It is not easy to see whether a patch made it in - there is no easy way to find it out Jan: For the ARM side it is difficult right now Jan: Once you realise that a series is ready to go in and CC one or two committers Lars: The dashboard allows you to track through searches Andy: There is a mailing list (see http://lists.xenproject.org/archives/html/xen-changelog) Andy: Takes the RSS feed ACTION: Lars to bring up with Birin Stefano: should we have people who own or have an interest in special ARM boards with contact addresses Andy: This is exactly what a feature in-tree doc would work and we could link to it in the Wiki Konrad: is there a dynamic ETB which supports lots of boards Julian/Andre: No Open Questions / requires Isn * Can an ACK be removed after the code has been changed More reviewers: - What does a review really mean? - It's a way to build trust - David: wait for something which is worthwhile and by pointing it out you build trust - Would it reduce the workload - Maybe not initially: but it's a long-time game - David: I trust people more who do significant contributions than pure reviewer Do we have guidelines on REST maintainers Jan: All the committers should be REST maintainers Julien: Script to get CC's isn't working (REST maintainers part isn't working) Julien: That needs to be fixed Coding checking tools Andy: Did take a look at - (clang-format) from LLVM Andy: Also seems to be happy to upstream Xe
[Xen-devel] [Hackathon] Restartable driver domains and restartable dom0 notes
Restartable driver domains and dom0 --- Jeurgen: See XenSummit presentation. - Xenstore Domain (bits missing in libxl) - Looking at driver domains next. One domain per backend or several backends in one domain. Drivers crash -> restart driver domains while guests running. Issues: - Guest configuration has both backend (e.g., which disk) and frontend parameters (e.g., which domain has the backend). - Frontend needs to reconnect to new backend in new backend. Suggestions: - Hack: Split configuration -> backend configuration to backend domain configuration. - Juergen suggests using XenStore (or other extermal database) to convey configuration information -- libxl writes this based on frontend guest configuration. - Must be in XenStore (or external) because toolstack domain may be restarted. But in "/toolstack/" top-level node. 1. Backend driver started, which backends to start (if needed), any devices assigned. 2. libxl reads guest config, writes to persistent store configuration of backend. 3. libxl reads persistent store, writes backend nodes to current driver domain instance (does this on driver domain restart). * Restart dom0. Move drivers into dom0 for resource usage => need to restart dom0. - performance problems with lots of vcpus. - SATA needs to be in dom0 -- shared by dom0 and guests (similar for other devices). - Can restart any backends in dom0. Juergens suggestions: 1. dom0 when it starts, "kexec" load's another image (kernel, initrd, DT, etc.). 2. hypervisor jumps to loaded image when dom0 starts, providing same resources (device, interrupts) that the old domain had. 3. New dom0 restarts any backends. 4. Reads persistent store, starts any backend instances as needed. Security concerns on loaded image. Is it trusted? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation
On 04/18/2016 07:45 PM, Jan Beulich wrote:
Razvan Cojocaru 04/18/16 2:40 PM >>>
>> On 04/14/2016 07:08 PM, Jan Beulich wrote:
>> Razvan Cojocaru 04/14/16 5:45 PM >>>
On 04/14/2016 06:40 PM, Jan Beulich wrote:
> To be honest, just having remembered that we do the write back for locked
> instructions using CMPXCHG, I'd first of all like to see a proper
> description
> of "the _whole_ issue".
I believe at least part of the issue has to do with the comment on line
1013 from xen/arch/x86/hvm/emulate.c:
>>> >994 static int hvmemul_cmpxchg(
>>> >995 enum x86_segment seg,
>>> >996 unsigned long offset,
>>> >997 void *p_old,
>>> >998 void *p_new,
>>> >999 unsigned int bytes,
1000 struct x86_emulate_ctxt *ctxt)
1001 {
1002 struct hvm_emulate_ctxt *hvmemul_ctxt =
1003 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
1004
1005 if ( unlikely(hvmemul_ctxt->set_context) )
1006 {
1007 int rc = set_context_data(p_new, bytes);
1008
1009 if ( rc != X86EMUL_OKAY )
1010 return rc;
1011 }
1012
1013 /* Fix this in case the guest is really relying on r-m-w
atomicity. */
1014 return hvmemul_write(seg, offset, p_new, bytes, ctxt);
1015 }
>>>
>>> Ah, so _that's_ where the problem wants to be fixed then (leaving - afaict -
>>> PV emulation paths completely unaffected).
>>
>> That's what I had hoped too, an early version of this patch simply used
>> a spinlock that locked / unlock on entry / exit of hvmemul_cmpxchg().
>> Even with this patch, I've just tried it again with all ops->smp_lock()
>> / ops->smp_unlock() calls commented out in x86_emulate(), and
>> hvmemul_cmpxchg() modified as follows:
>>
> >994 static int hvmemul_cmpxchg(
> >995 enum x86_segment seg,
> >996 unsigned long offset,
> >997 void *p_old,
> >998 void *p_new,
> >999 unsigned int bytes,
>> 1000 struct x86_emulate_ctxt *ctxt)
>> 1001 {
>> 1002 struct hvm_emulate_ctxt *hvmemul_ctxt =
>> 1003 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>> 1004 int rc;
>> 1005
>> 1006 emulate_smp_lock(1);
>> 1007
>> 1008 if ( unlikely(hvmemul_ctxt->set_context) )
>> 1009 {
>> 1010 int rc = set_context_data(p_new, bytes);
>> 1011
>> 1012 if ( rc != X86EMUL_OKAY )
>> 1013 return rc;
>> 1014 }
>> 1015
>> 1016 /* Fix this in case the guest is really relying on r-m-w
>> atomicity. */
>> 1017 rc = hvmemul_write(seg, offset, p_new, bytes, ctxt);
>> 1018
>> 1019 emulate_smp_unlock(1);
>> 1020
>> 1021 return rc;
>> 1022 }
>>
>> Unfortunately, with just this the guest still hangs, while with read and
>> write locking in x86_emulate() it does not.
>
> That's unexpected at least at the first glance, but justifying some variant of
> the patch you have submitted would require understanding why the above
> change isn't enough and can't be suitably extended to be sufficient.
I think this might be because the LOCK prefix should guarantee that the
instruction that follows it has exclusive use of shared memory (for both
reads and writes) but I might be misreading the docs:
(From the Intel SDM) "Causes the processor’s LOCK# signal to be asserted
during execution of the accompanying instruction (turns the instruction
into an atomic instruction). In a multiprocessor environment, the LOCK#
signal ensures that the processor has exclusive use of any shared memory
while the signal is asserted."
Using a spin lock (or the rwlock in the manner described above) in
hvmemul_cmpxchg() only prevents two LOCKed instructions from running at
the same time, but presumably even non-LOCKed instructions just reading
that memory area should be prevented from running until the LOCKed
instruction is done (hence the guest starting up with the rwlock in
x86_emulate() but not with it locked only in hvmemul_cmpxchg()).
Hopefully I haven't misunderstood the issue.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 91991: tolerable FAIL
flight 91991 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/91991/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail pass in 91846 Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 91846 build-i386-rumpuserxen6 xen-buildfail like 91846 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 91846 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 91846 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 91846 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 91846 test-amd64-amd64-xl-rtds 9 debian-install fail like 91846 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass version targeted for testing: xen f3a7ca02400d1c416e97451b4aebfaf608fc8192 baseline version: xen f3a7ca02400d1c416e97451b4aebfaf608fc8192 Last test of basis91991 2016-04-19 01:59:33 Z0 days Testing same since0 1970-01-01 00:00:00 Z 16910 days0 attempts jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
On 4/19/2016 12:58 AM, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
Beulich
Sent: 18 April 2016 17:47
To: Paul Durrant
Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
Dunlap; xen-devel@lists.xen.org; yu.c.zh...@linux.intel.com;
zhiyuan...@intel.com; jun.nakaj...@intel.com
Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename
p2m_mmio_write_dm to p2m_ioreq_server
Paul Durrant 04/18/16 6:45 PM >>>
The original patch was posted before the cut-off IIRC so I'm not sure
of the policy regarding freeze-exceptions.
It was submitted before the feature freeze, yes, but didn't make it in by
code freeze. So it's my understanding that an exception would be needed.
Ok. Thanks for the clarification. IMO getting this in is worth the freeze
exception... it's a shame p2m_mmio_write_dm made it into 4.6.1. It needs to go
before it proliferates any further.
Thanks, Paul.
So I suppose the only place we need change for this patch is
for hvmmem_type_t, which should be defined like this?
typedef enum {
HVMMEM_ram_rw, /* Normal read/write guest RAM */
HVMMEM_ram_ro, /* Read-only; writes are discarded */
HVMMEM_mmio_dm,/* Reads and write go to the device model */
#if __XEN_INTERFACE_VERSION__ >= 0x00040700
HVMMEM_ioreq_server
#else
HVMMEM_mmio_write_dm
#endif
} hvmmem_type_t;
Besides, does 4.7 still accept freeze exception? It would be great
if we can get an approval for this.
Thanks
Yu
Paul
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 April 2016 12:03
> To: Paul Durrant; Jan Beulich; Wei Liu
> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
> Dunlap; xen-devel@lists.xen.org; zhiyuan...@intel.com;
> jun.nakaj...@intel.com
> Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename
> p2m_mmio_write_dm to p2m_ioreq_server
>
>
>
> On 4/19/2016 12:58 AM, Paul Durrant wrote:
> >> -Original Message-
> >> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Jan
> >> Beulich
> >> Sent: 18 April 2016 17:47
> >> To: Paul Durrant
> >> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
> >> Dunlap; xen-devel@lists.xen.org; yu.c.zh...@linux.intel.com;
> >> zhiyuan...@intel.com; jun.nakaj...@intel.com
> >> Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename
> >> p2m_mmio_write_dm to p2m_ioreq_server
> >>
> > Paul Durrant 04/18/16 6:45 PM >>>
> >>> The original patch was posted before the cut-off IIRC so I'm not sure
> >>> of the policy regarding freeze-exceptions.
> >>
> >>It was submitted before the feature freeze, yes, but didn't make it in
> >> by
> >> code freeze. So it's my understanding that an exception would be
> needed.
> >>
> >
> > Ok. Thanks for the clarification. IMO getting this in is worth the freeze
> exception... it's a shame p2m_mmio_write_dm made it into 4.6.1. It needs to
> go before it proliferates any further.
> >
>
> Thanks, Paul.
>
> So I suppose the only place we need change for this patch is
> for hvmmem_type_t, which should be defined like this?
>
> typedef enum {
> HVMMEM_ram_rw, /* Normal read/write guest RAM */
> HVMMEM_ram_ro, /* Read-only; writes are discarded */
> HVMMEM_mmio_dm,/* Reads and write go to the device model */
> #if __XEN_INTERFACE_VERSION__ >= 0x00040700
> HVMMEM_ioreq_server
> #else
> HVMMEM_mmio_write_dm
> #endif
> } hvmmem_type_t;
>
> Besides, does 4.7 still accept freeze exception? It would be great
> if we can get an approval for this.
I talked to Wei earlier and he is happy to give a freeze exception to this
change.
Paul
>
> Thanks
> Yu
>
> >Paul
> >
> >> Jan
> >>
> >>
> >> ___
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
On 4/19/2016 6:05 PM, Paul Durrant wrote: -Original Message- From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 19 April 2016 10:44 To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; jun.nakaj...@intel.com Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server On 4/19/2016 5:21 PM, Paul Durrant wrote: -Original Message- [snip] Does any other maintainers have any suggestions? Note that it is a requirement that an ioreq server be disabled before VM suspend. That means ioreq server pages essentially have to go back to ram_rw semantics. Paul OK. So it should be hypervisor's responsibility to do the resetting. Now we probably have 2 choices: 1> we reset the p2m type synchronously when ioreq server unmapping happens, instead of deferring to the misconfig handling part. This means performance impact to traverse the p2m table. Do we need to reset at all. The p2m type does need to be transferred, it will just be unclaimed on the far end (i.e. the pages are treated as r/w ram) until the emulator starts up there. If that cannot be done without creating yet another p2m type to handle logdirty (which seems a suboptimal way of dealing with it) then I think migration needs to be disallowed on any domain than contains any ioreq_server type pages at this stage. Paul Yes. We need - either the device model or hypervisor should grantee there's no p2m_ioreq_server pages left after an ioreq server is unmapped from this type (which is write protected in such senario), otherwise its emulation might be forwarded to other unexpected device models which claims the p2m_ioreq_server later. That should be for the device model to guarantee IMO. If the 'wrong' emulator claims the ioreq server type then I don't think that's Xen's problem. Thanks, Paul. So what about the VM suspend case you mentioned above? Will that trigger the unmapping of ioreq server? Could the device model also take the role to change the p2m type back in such case? It would be much simpler if hypervisor side does not need to provide the p2m resetting logic, and we can support live migration at the same time then. :) B.R. Yu So I guess approach 2> is your suggestion now. Besides, previously, Jan also questioned the necessity of resetting the p2m type when an ioreq server is mapping to the p2m_ioreq_server. His argument is that we should only allow such p2m transition after an ioreq server has already mapped to this p2m_ioreq_server. I think his point sounds also reasonable. I was kind of hoping to avoid that ordering dependency but if it makes things simpler then so be it. Paul Thanks Yu Or 2> we just disallow live migration when p2m->ioreq.server is not NULL. This is not quite accurate, because having p2m->ioreq.server mapped to p2m_ioreq_server does not necessarily means there would be such outstanding entries. To be more accurate, we can add some other rough check, e.g. both check if p2m->ioreq.server against NULL and check if the hvmop_set_mem_type has ever been triggered once for the p2m_ioreq_server type. Both choice seems suboptimal for me. And I wonder if we have any better solutions? Thanks Yu Thanks in advance! :) If the answer is, "everything just works", that's perfect. If the answer is, "Before logdirty mode is set, the ioreq server has the opportunity to detach, removing the p2m_ioreq_server entries, and operating without that functionality", that's good too. If the answer is, "the live migration request fails and the guest continues to run", that's also acceptable. If you want this series to be checked in today (the last day for 4.7), this is probably your best bet. -George Regards Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
On 4/19/2016 7:15 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 12:03
To: Paul Durrant; Jan Beulich; Wei Liu
Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
Dunlap; xen-devel@lists.xen.org; zhiyuan...@intel.com;
jun.nakaj...@intel.com
Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename
p2m_mmio_write_dm to p2m_ioreq_server
On 4/19/2016 12:58 AM, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
Jan
Beulich
Sent: 18 April 2016 17:47
To: Paul Durrant
Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
Dunlap; xen-devel@lists.xen.org; yu.c.zh...@linux.intel.com;
zhiyuan...@intel.com; jun.nakaj...@intel.com
Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename
p2m_mmio_write_dm to p2m_ioreq_server
Paul Durrant 04/18/16 6:45 PM >>>
The original patch was posted before the cut-off IIRC so I'm not sure
of the policy regarding freeze-exceptions.
It was submitted before the feature freeze, yes, but didn't make it in by
code freeze. So it's my understanding that an exception would be
needed.
Ok. Thanks for the clarification. IMO getting this in is worth the freeze
exception... it's a shame p2m_mmio_write_dm made it into 4.6.1. It needs to
go before it proliferates any further.
Thanks, Paul.
So I suppose the only place we need change for this patch is
for hvmmem_type_t, which should be defined like this?
typedef enum {
HVMMEM_ram_rw, /* Normal read/write guest RAM */
HVMMEM_ram_ro, /* Read-only; writes are discarded */
HVMMEM_mmio_dm,/* Reads and write go to the device model */
#if __XEN_INTERFACE_VERSION__ >= 0x00040700
HVMMEM_ioreq_server
#else
HVMMEM_mmio_write_dm
#endif
} hvmmem_type_t;
Besides, does 4.7 still accept freeze exception? It would be great
if we can get an approval for this.
I talked to Wei earlier and he is happy to give a freeze exception to this
change.
Great! I really obliged. :)
BTW, Does some form of application need to be submitted? I'm not
familiar with the procedure.
Yu
Paul
Thanks
Yu
Paul
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> -Original Message- > From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: 19 April 2016 12:18 > To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org > Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; > jun.nakaj...@intel.com > Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to > map guest ram with p2m_ioreq_server to an ioreq server > > > > On 4/19/2016 6:05 PM, Paul Durrant wrote: > >> -Original Message- > >> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > >> Sent: 19 April 2016 10:44 > >> To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org > >> Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; > >> jun.nakaj...@intel.com > >> Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to > >> map guest ram with p2m_ioreq_server to an ioreq server > >> > >> > >> > >> On 4/19/2016 5:21 PM, Paul Durrant wrote: > -Original Message- > >>> [snip] > >> Does any other maintainers have any suggestions? > > > > Note that it is a requirement that an ioreq server be disabled before > VM > suspend. That means ioreq server pages essentially have to go back to > ram_rw semantics. > > > > Paul > > > > OK. So it should be hypervisor's responsibility to do the resetting. > Now we probably have 2 choices: > 1> we reset the p2m type synchronously when ioreq server unmapping > happens, instead of deferring to the misconfig handling part. This > means performance impact to traverse the p2m table. > > >>> > >>> Do we need to reset at all. The p2m type does need to be transferred, it > >> will just be unclaimed on the far end (i.e. the pages are treated as r/w > ram) > >> until the emulator starts up there. If that cannot be done without creating > >> yet another p2m type to handle logdirty (which seems a suboptimal way > of > >> dealing with it) then I think migration needs to be disallowed on any > domain > >> than contains any ioreq_server type pages at this stage. > >>> > >>> Paul > >>> > >> > >> Yes. We need - either the device model or hypervisor should grantee > >> there's no p2m_ioreq_server pages left after an ioreq server is > unmapped > >> from this type (which is write protected in such senario), otherwise > >> its emulation might be forwarded to other unexpected device models > which > >> claims the p2m_ioreq_server later. > > > > That should be for the device model to guarantee IMO. If the 'wrong' > emulator claims the ioreq server type then I don't think that's Xen's problem. > > > > Thanks, Paul. > > So what about the VM suspend case you mentioned above? Will that trigger > the unmapping of ioreq server? Could the device model also take the role > to change the p2m type back in such case? Yes. The device model has to be told by the toolstack that the VM is suspending, otherwise it can't disable the ioreq server which puts the shared ioreq pages back into the guest p2m. If that's not done then the pages will be leaked. > > It would be much simpler if hypervisor side does not need to provide > the p2m resetting logic, and we can support live migration at the same > time then. :) > That really should not be hypervisor's job. Paul > > B.R. > Yu > > >> > >> So I guess approach 2> is your suggestion now. > >> > >> Besides, previously, Jan also questioned the necessity of resetting the > >> p2m type when an ioreq server is mapping to the p2m_ioreq_server. His > >> argument is that we should only allow such p2m transition after an > >> ioreq server has already mapped to this p2m_ioreq_server. I think his > >> point sounds also reasonable. > >> > > > > I was kind of hoping to avoid that ordering dependency but if it makes > things simpler then so be it. > > > >Paul > > > >> Thanks > >> Yu > >> > Or > 2> we just disallow live migration when p2m->ioreq.server is not NULL. > This is not quite accurate, because having p2m->ioreq.server mapped > to p2m_ioreq_server does not necessarily means there would be such > outstanding entries. To be more accurate, we can add some other > rough > check, e.g. both check if p2m->ioreq.server against NULL and check if > the hvmop_set_mem_type has ever been triggered once for the > p2m_ioreq_server type. > > Both choice seems suboptimal for me. And I wonder if we have any > better solutions? > > Thanks > Yu > > >> Thanks in advance! :) > If the answer is, "everything just works", that's perfect. > > If the answer is, "Before logdirty mode is set, the ioreq server has > >> the > opportunity to detach, removing the p2m_ioreq_server entries, > and > operating without that functionality", that's good too. > > If the answer is, "the live migration request fails and the guest > continues to run", that's also acceptable. If y
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 April 2016 12:39
> To: Paul Durrant; Jan Beulich; Wei Liu
> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
> Dunlap; xen-devel@lists.xen.org; zhiyuan...@intel.com;
> jun.nakaj...@intel.com
> Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename
> p2m_mmio_write_dm to p2m_ioreq_server
>
>
>
> On 4/19/2016 7:15 PM, Paul Durrant wrote:
> >> -Original Message-
> >> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> >> Sent: 19 April 2016 12:03
> >> To: Paul Durrant; Jan Beulich; Wei Liu
> >> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
> >> Dunlap; xen-devel@lists.xen.org; zhiyuan...@intel.com;
> >> jun.nakaj...@intel.com
> >> Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename
> >> p2m_mmio_write_dm to p2m_ioreq_server
> >>
> >>
> >>
> >> On 4/19/2016 12:58 AM, Paul Durrant wrote:
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf
> Of
> >> Jan
> Beulich
> Sent: 18 April 2016 17:47
> To: Paul Durrant
> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
> Dunlap; xen-devel@lists.xen.org; yu.c.zh...@linux.intel.com;
> zhiyuan...@intel.com; jun.nakaj...@intel.com
> Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename
> p2m_mmio_write_dm to p2m_ioreq_server
>
> >>> Paul Durrant 04/18/16 6:45 PM >>>
> > The original patch was posted before the cut-off IIRC so I'm not sure
> > of the policy regarding freeze-exceptions.
>
> It was submitted before the feature freeze, yes, but didn't make it
> in
> by
> code freeze. So it's my understanding that an exception would be
> >> needed.
>
> >>>
> >>> Ok. Thanks for the clarification. IMO getting this in is worth the freeze
> >> exception... it's a shame p2m_mmio_write_dm made it into 4.6.1. It
> needs to
> >> go before it proliferates any further.
> >>>
> >>
> >> Thanks, Paul.
> >>
> >> So I suppose the only place we need change for this patch is
> >> for hvmmem_type_t, which should be defined like this?
> >>
> >> typedef enum {
> >> HVMMEM_ram_rw, /* Normal read/write guest RAM */
> >> HVMMEM_ram_ro, /* Read-only; writes are discarded */
> >> HVMMEM_mmio_dm,/* Reads and write go to the device model
> */
> >> #if __XEN_INTERFACE_VERSION__ >= 0x00040700
> >> HVMMEM_ioreq_server
> >> #else
> >> HVMMEM_mmio_write_dm
> >> #endif
> >> } hvmmem_type_t;
> >>
> >> Besides, does 4.7 still accept freeze exception? It would be great
> >> if we can get an approval for this.
> >
> > I talked to Wei earlier and he is happy to give a freeze exception to this
> change.
> >
>
> Great! I really obliged. :)
> BTW, Does some form of application need to be submitted? I'm not
> familiar with the procedure.
Nor am I. I would expect that you should submit the patch with something like
"PATCH for 4.7" in the subject.
Paul
>
> Yu
> >Paul
> >
> >>
> >> Thanks
> >> Yu
> >>
> >>> Paul
> >>>
> Jan
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> >>> ___
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xen.org
> >>> http://lists.xen.org/xen-devel
> >>>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
On 4/19/2016 7:47 PM, Paul Durrant wrote: -Original Message- From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 19 April 2016 12:18 To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; jun.nakaj...@intel.com Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server On 4/19/2016 6:05 PM, Paul Durrant wrote: -Original Message- From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 19 April 2016 10:44 To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; jun.nakaj...@intel.com Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server On 4/19/2016 5:21 PM, Paul Durrant wrote: -Original Message- [snip] Does any other maintainers have any suggestions? Note that it is a requirement that an ioreq server be disabled before VM suspend. That means ioreq server pages essentially have to go back to ram_rw semantics. Paul OK. So it should be hypervisor's responsibility to do the resetting. Now we probably have 2 choices: 1> we reset the p2m type synchronously when ioreq server unmapping happens, instead of deferring to the misconfig handling part. This means performance impact to traverse the p2m table. Do we need to reset at all. The p2m type does need to be transferred, it will just be unclaimed on the far end (i.e. the pages are treated as r/w ram) until the emulator starts up there. If that cannot be done without creating yet another p2m type to handle logdirty (which seems a suboptimal way of dealing with it) then I think migration needs to be disallowed on any domain than contains any ioreq_server type pages at this stage. Paul Yes. We need - either the device model or hypervisor should grantee there's no p2m_ioreq_server pages left after an ioreq server is unmapped from this type (which is write protected in such senario), otherwise its emulation might be forwarded to other unexpected device models which claims the p2m_ioreq_server later. That should be for the device model to guarantee IMO. If the 'wrong' emulator claims the ioreq server type then I don't think that's Xen's problem. Thanks, Paul. So what about the VM suspend case you mentioned above? Will that trigger the unmapping of ioreq server? Could the device model also take the role to change the p2m type back in such case? Yes. The device model has to be told by the toolstack that the VM is suspending, otherwise it can't disable the ioreq server which puts the shared ioreq pages back into the guest p2m. If that's not done then the pages will be leaked. It would be much simpler if hypervisor side does not need to provide the p2m resetting logic, and we can support live migration at the same time then. :) That really should not be hypervisor's job. Paul Oh. So let's just remove the p2m type recalculation code from this patch, no need to call p2m_change_entry_type_global, and no need to worry about the log dirty part. George, do you think this acceptable? BTW, if no need to call p2m_change_entry_type_global, which is not used for shadow mode, we can keep this p2m type in shadow code, right? Thanks Yu B.R. Yu So I guess approach 2> is your suggestion now. Besides, previously, Jan also questioned the necessity of resetting the p2m type when an ioreq server is mapping to the p2m_ioreq_server. His argument is that we should only allow such p2m transition after an ioreq server has already mapped to this p2m_ioreq_server. I think his point sounds also reasonable. I was kind of hoping to avoid that ordering dependency but if it makes things simpler then so be it. Paul Thanks Yu Or 2> we just disallow live migration when p2m->ioreq.server is not NULL. This is not quite accurate, because having p2m->ioreq.server mapped to p2m_ioreq_server does not necessarily means there would be such outstanding entries. To be more accurate, we can add some other rough check, e.g. both check if p2m->ioreq.server against NULL and check if the hvmop_set_mem_type has ever been triggered once for the p2m_ioreq_server type. Both choice seems suboptimal for me. And I wonder if we have any better solutions? Thanks Yu Thanks in advance! :) If the answer is, "everything just works", that's perfect. If the answer is, "Before logdirty mode is set, the ioreq server has the opportunity to detach, removing the p2m_ioreq_server entries, and operating without that functionality", that's good too. If the answer is, "the live migration request fails and the guest continues to run", that's also acceptable. If you want this series to be checked in today (the last day for 4.7), this is probably your best bet. -George Regards Yu
Re: [Xen-devel] [PATCH v5] xen/arm64: check XSM Magic from the second unknown module.
Hi Wei Liu On 15 April 2016 at 17:47, Wei Liu wrote: > On Wed, Apr 13, 2016 at 05:45:27PM +0800, Fu Wei wrote: >> Hi Julien, >> >> On 8 April 2016 at 23:19, Julien Grall wrote: >> > Hi Wei, >> > >> > On 08/04/16 15:58, Wei Liu wrote: >> >> >> >> On Fri, Apr 08, 2016 at 03:51:22PM +0100, Julien Grall wrote: >> >>> >> >>> Hi Fu Wei, >> >>> >> >>> On 05/04/16 17:46, fu@linaro.org wrote: >> >> From: Fu Wei >> >> This patch adds a has_xsm_magic helper function for detecting XSM >> >>> >> >>> >from the second unknown module. >> >> >> If Xen can't get the kind of module from compatible, we guess the kind >> of >> these unknowns respectively: >> (1) The first unknown must be kernel. >> (2) Detect the XSM Magic from the 2nd unknown: >> a. If it's XSM, set the kind as XSM, and that also means we >> won't load ramdisk; >> b. if it's not XSM, set the kind as ramdisk. >> So if user want to load ramdisk, it must be the 2nd unknown. >> >>> >> >>> >> >>> The documentation in docs/misc/arm/device-tree/booting.txt needs to be >> >>> update. >> >>> >> >>> Otherwise, the rest of the patch looks good to me. >> >>> >> >>> Regards, >> >>> >> >> >> >> Is this targeting 4.7? Today is the last day for committing stuff. The >> >> doc can come in later. >> > >> > >> > Yes, it's targeting 4.7. Fu Wei, can you send a follow-up for the doc? >> > >> >> yes, of course, I will do ASAP. >> > > Yes please. Note that the anticipated release date would be the > beginning of June, so you have five weeks to do that. I have posted the doc patch: http://lists.xen.org/archives/html/xen-devel/2016-04/msg02070.html could some one review it ?? > > Wei. -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 04/14] firmware/makefile: install BIOS blob ...
On Mon, 18 Apr 2016, Doug Goldstein wrote: > On 3/14/16 5:55 PM, Anthony PERARD wrote: > > ... into the firmware directory, along with hvmloader. > > > > Signed-off-by: Anthony PERARD > > --- > > Change in V4: > > - remove install of acpi dsdt table > > > > Change in V3: > > - do not check if ROMs file exist before installing, they should exist > > - change rules for dsdt_anycpu_qemu_xen.c in oder to generate both .c and > > .aml files without changing temporarly the other dsdt_*.c rules. > > --- > > tools/firmware/Makefile | 13 + > > 1 file changed, 13 insertions(+) > > > > diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile > > index 6cc86ce..6a37758 100644 > > --- a/tools/firmware/Makefile > > +++ b/tools/firmware/Makefile > > @@ -19,6 +19,9 @@ SUBDIRS-y += hvmloader > > > > LD32BIT-$(CONFIG_FreeBSD) := LD32BIT_FLAG=-melf_i386_fbsd > > > > +SEABIOS_ROM := seabios-dir/out/bios.bin > > +OVMF_ROM := ovmf-dir/ovmf.bin > > + > > ovmf-dir: > > GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) > > $(OVMF_UPSTREAM_REVISION) ovmf-dir > > cp ovmf-makefile ovmf-dir/Makefile; > > @@ -45,6 +48,16 @@ endif > > install: all > > [ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR) > > [ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR) > > +ifeq ($(CONFIG_SEABIOS),y) > > +ifeq ($(SEABIOS_PATH),) > > + $(INSTALL_DATA) $(SEABIOS_ROM) $(INST_DIR)/seabios.bin > > +endif > > +endif > > +ifeq ($(CONFIG_OVMF),y) > > +ifeq ($(OVMF_PATH),) > > + $(INSTALL_DATA) $(OVMF_ROM) $(INST_DIR)/ovmf.bin > > +endif > > +endif > > > > .PHONY: clean > > clean: subdirs-clean > > > > So I'm going to toss this out there but what if we don't install these > at all? We talked about reducing the scope that the Xen Security team > had to maintain. What if we just state that SeaBIOS and/or OVMF are > dependencies? All the downstream distros don't use the pre-built > binaries from Xen and build it themselves. For plain Xen users we just > add that to the list of dependencies. > > I think SeaBIOS and OVMF are a lot more low risk than something like > QEMU since they have a very clear target so they're a lot more likely to > remain stable. SeaBIOS also has a fairly low level of churn, especially > on stable branches. Just to add to your argument, Raisin already supports both SeaBIOS and OVMF. That's another way for users to build them if they want to. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 92003: regressions - FAIL
flight 92003 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/92003/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 60684 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 60684 test-amd64-amd64-libvirt 14 guest-saverestore fail REGR. vs. 60684 test-amd64-amd64-xl 14 guest-saverestore fail REGR. vs. 60684 test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 60684 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail REGR. vs. 60684 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 60684 test-amd64-amd64-i386-pvgrub 21 leak-check/check fail REGR. vs. 60684 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684 test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 60684 test-amd64-i386-xl-xsm 15 guest-localmigrate fail blocked in 60684 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 60684 test-amd64-i386-libvirt 14 guest-saverestorefail like 60684 test-amd64-i386-xl 14 guest-saverestorefail like 60684 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 60684 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 60684 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: linux24d7e5edddbdd6b4c1a726df4e0497c26bc6b7d7 baseline version: linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0 Last test of basis60684 2015-08-13 04:21:46 Z 250 days Failing since 60712 2015-08-15 18:33:48 Z 247 days 189 attempts Testing same since92003 2016-04-19 04:28:35 Z0 days1 attempts 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 build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-lib
Re: [Xen-devel] [PATCH v2 04/11] grant_table: avoid unnecessary work during grant table unmapping
On April 19, 2016 2:46pm, Tian, Kevin wrote: > > From: Quan Xu > > Sent: Monday, April 18, 2016 10:00 PM > > > > While grant table is unmapping, the domain (with the exception of the > > unmapping -> unmapped. > A slightly different take, IMO the hypercall is not returned, so it is DOING. > > hardware domain) may be crashed due to IOMMU mapping and unmapping > > failures, and then it is unnecessary to flush specified CPUs' TLBs. > > Above description is not complete. You said "with the exception of the > hardware domain". Then people will ask whether 'unnecessary' > is also true for hardware domain (if not restriction for hardware domain to > invoke those interfaces). > Make sense. Could I only drop '(with the exception of the hardware domain)'? > > > > Signed-off-by: Quan Xu > > > > CC: Ian Jackson > > CC: Jan Beulich > > CC: Keir Fraser > > CC: Tim Deegan > > --- > > xen/common/grant_table.c | 10 ++ > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c index > > 8b22299..1801fe9 100644 > > --- a/xen/common/grant_table.c > > +++ b/xen/common/grant_table.c > > @@ -1366,8 +1366,9 @@ gnttab_unmap_grant_ref( > > > > return 0; > > > > -fault: > > -gnttab_flush_tlb(current->domain); > > + fault: > > +if ( current->domain->is_shut_down ) > > +gnttab_flush_tlb(current->domain); > > > > for ( i = 0; i < partial_done; i++ ) > > __gnttab_unmap_common_complete(&(common[i])); > > @@ -1429,8 +1430,9 @@ gnttab_unmap_and_replace( > > > > return 0; > > > > -fault: > > -gnttab_flush_tlb(current->domain); > > + fault: > > +if ( current->domain->is_shut_down ) > > +gnttab_flush_tlb(current->domain); > > > > for ( i = 0; i < partial_done; i++ ) > > __gnttab_unmap_common_complete(&(common[i])); > > -- > > 1.9.1 > > > > > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 44344: regressions - FAIL
This run is configured for baseline tests only. flight 44344 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44344/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-i386-pvgrub 10 guest-start fail REGR. vs. 44340 test-amd64-amd64-qemuu-nested-intel 14 capture-logs/l1(14) fail REGR. vs. 44340 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 44340 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: qemuu92b674b62a1aec734280c9019cfb3b3745044b66 baseline version: qemuuc7b45f12828c1ba7105dbc029c63d7de68eaa91c Last test of basis44340 2016-04-17 02:01:58 Z2 days Testing same since44344 2016-04-19 07:49:00 Z0 days1 attempts People who touched revisions under test: Andreas Färber David Gibson Denis V. Lunev Dr. David Alan Gilbert Eduardo Habkost Eduardo Otubo Eric Blake Fam Zheng James Hogan Jeff Cody Kevin Wolf Laszlo Ersek Mark Cave-Ayland Max Reitz Michael Fritscher Miroslav Rezanina Paolo Bonzini Pavel Butsykin Peter Maydell Sascha Silbe Stefan Hajnoczi Stefan Weil Thomas Huth jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops
Re: [Xen-devel] ARMv8: New board bring up hangs in kernel start?
On 18.04.2016 10:17, Julien Grall wrote: On 16/04/2016 18:39, Dirk Behme wrote: Hi Julien, Hi Dirk, On 06.04.2016 12:48, Julien Grall wrote: On 04/04/2016 16:44, Dirk Behme wrote: Hi Julien, I'm using https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/renesas/r8a7795.dtsi#n134 The special thing here is that it has the offsets 0x1, 0x2, 0x4 and 0x6. Instead of the standard ones 0x1000, 0x2000, 0x4000 and 0x6000. Those offsets are normal, this platform seems to have a GIC using 64KB-aligned region rather than the classic 4KB-aligned one. Now, just by try & error, using [1] makes things working. I'm not sure why this changes anything, though: * To my understanding, the GIC register ranges are max 0x1000. So I'd think that the 0x2000 should be sufficient to map all necessary registers. * I haven't observed any MMU fault. So it didn't look like any non-mapped register was accessed without this change. Xen is checking if the platform is using an aliased GIC when the CPU interface size is 128KB (see gicv2_is_aliased and commit 21550029f709072aacf3b90edd574e7d3021b400). If you see "GICv2: Adjusting CPU interface base to..." then your GIC is aliased. In any case, the device-tree does not correctly describe the hardware on your platform. Can you send a patch to fix the upstream device-tree? Done: http://article.gmane.org/gmane.linux.kernel.renesas-soc/2951 Thanks! Dirk ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5] xen/arm64: check XSM Magic from the second unknown module.
On Tue, Apr 19, 2016 at 08:32:17PM +0800, Fu Wei wrote: > Hi Wei Liu > > On 15 April 2016 at 17:47, Wei Liu wrote: > > On Wed, Apr 13, 2016 at 05:45:27PM +0800, Fu Wei wrote: > >> Hi Julien, > >> > >> On 8 April 2016 at 23:19, Julien Grall wrote: > >> > Hi Wei, > >> > > >> > On 08/04/16 15:58, Wei Liu wrote: > >> >> > >> >> On Fri, Apr 08, 2016 at 03:51:22PM +0100, Julien Grall wrote: > >> >>> > >> >>> Hi Fu Wei, > >> >>> > >> >>> On 05/04/16 17:46, fu@linaro.org wrote: > >> > >> From: Fu Wei > >> > >> This patch adds a has_xsm_magic helper function for detecting XSM > >> >>> > >> >>> >from the second unknown module. > >> > >> > >> If Xen can't get the kind of module from compatible, we guess the kind > >> of > >> these unknowns respectively: > >> (1) The first unknown must be kernel. > >> (2) Detect the XSM Magic from the 2nd unknown: > >> a. If it's XSM, set the kind as XSM, and that also means we > >> won't load ramdisk; > >> b. if it's not XSM, set the kind as ramdisk. > >> So if user want to load ramdisk, it must be the 2nd unknown. > >> >>> > >> >>> > >> >>> The documentation in docs/misc/arm/device-tree/booting.txt needs to be > >> >>> update. > >> >>> > >> >>> Otherwise, the rest of the patch looks good to me. > >> >>> > >> >>> Regards, > >> >>> > >> >> > >> >> Is this targeting 4.7? Today is the last day for committing stuff. The > >> >> doc can come in later. > >> > > >> > > >> > Yes, it's targeting 4.7. Fu Wei, can you send a follow-up for the doc? > >> > > >> > >> yes, of course, I will do ASAP. > >> > > > > Yes please. Note that the anticipated release date would be the > > beginning of June, so you have five weeks to do that. > > I have posted the doc patch: > http://lists.xen.org/archives/html/xen-devel/2016-04/msg02070.html > Strange, I don't seem to have that in my inbox or xen-devel archive. > could some one review it ?? I will leave that to Julien and Stefano, but if it takes too long I will look at it myself. Thanks for writing the patch. Wei. > > > > > Wei. > > > > -- > Best regards, > > Fu Wei > Software Engineer > Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch > Ph: +86 21 61221326(direct) > Ph: +86 186 2020 4684 (mobile) > Room 1512, Regus One Corporate Avenue,Level 15, > One Corporate Avenue,222 Hubin Road,Huangpu District, > Shanghai,China 200021 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] tools: detect appropriate debug optimization level
When building debug use -Og as the optimization level if its available, otherwise retain the use of -O0. -Og has been added by GCC to enable all optimizations that to not affect debugging while retaining full debugability. Signed-off-by: Doug Goldstein --- tools/Rules.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/Rules.mk b/tools/Rules.mk index 9ef0b47..4162bd9 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -137,7 +137,8 @@ SHLIB_libxenvchan = $(SHDEPS_libxenvchan) -Wl,-rpath-link=$(XEN_LIBVCHAN) ifeq ($(debug),y) # Disable optimizations and enable debugging information for macros -CFLAGS += -O0 -g3 +CFLAGS += $(call cc-option,$(CC),-Og,-O0) +CFLAGS += -g3 # But allow an override to -O0 in case Python enforces -D_FORTIFY_SOURCE=. PY_CFLAGS += $(PY_NOOPT_CFLAGS) endif -- 2.7.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation
>>> Razvan Cojocaru 04/19/16 1:01 PM >>> >I think this might be because the LOCK prefix should guarantee that the >instruction that follows it has exclusive use of shared memory (for both >reads and writes) but I might be misreading the docs: LOCK definitely has no effect on other than the instruction it gets applied to. Jan >(From the Intel SDM) "Causes the processor’s LOCK# signal to be asserted >during execution of the accompanying instruction (turns the instruction >into an atomic instruction). In a multiprocessor environment, the LOCK# >signal ensures that the processor has exclusive use of any shared memory >while the signal is asserted." > >Using a spin lock (or the rwlock in the manner described above) in >hvmemul_cmpxchg() only prevents two LOCKed instructions from running at >the same time, but presumably even non-LOCKed instructions just reading >that memory area should be prevented from running until the LOCKed >instruction is done (hence the guest starting up with the rwlock in >x86_emulate() but not with it locked only in hvmemul_cmpxchg()). > >Hopefully I haven't misunderstood the issue. > > >Thanks, >Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
>>> "Yu, Zhang" 04/19/16 1:46 PM >>> >On 4/19/2016 7:15 PM, Paul Durrant wrote: >> I talked to Wei earlier and he is happy to give a freeze exception to this >> change. > >Great! I really obliged. :) >BTW, Does some form of application need to be submitted? I'm not >familiar with the procedure. To add some clarification (hopefully; Wei, please correct me if I'm wrong): The exception so far was granted only for this one patch, not the entire series. Hence it would help if in the re-submission (with the I think single pending change needed to this particular patch) you'd put this first in the series (or submit it on its own). And make sure you Cc Wei in addition to any of the people you're normally expected to Cc. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 92027: regressions - FAIL
flight 92027 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/92027/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 74e8963c9b661eaa4e828b0ad2d8925e1622ac49 baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 133 days Failing since 65593 2015-12-08 23:44:51 Z 132 days 160 attempts Testing same since92027 2016-04-19 10:14:44 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19764 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] tools/libxc: Correct use of X86_XSS_MASK in guest xstate generation
c/s 75f9455e "tools/libxc: Calculate xstate cpuid leaf from guest information"
incorrectly inverted the shift and mask when using X86_XSS_MASK. Luckily, the
mask is currently zero, avoiding incorrect calculations.
While adjusting this, use an explcit uint32_t cast rather than masking against
0x.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Jan Beulich
Submitted-from: A punt, on the Cam, during the the hackathon, because.
---
tools/libxc/xc_cpuid_x86.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 6d14904..84f4e08 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -460,7 +460,7 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
{
case 0:
/* EAX: low 32bits of xfeature_enabled_mask */
-regs[0] = guest_xfeature_mask & 0x;
+regs[0] = (uint32_t)guest_xfeature_mask;
/* EDX: high 32bits of xfeature_enabled_mask */
regs[3] = guest_xfeature_mask >> 32;
/* ECX: max size required by all HW features */
@@ -487,8 +487,8 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
if ( test_bit(X86_FEATURE_XSAVES, info->featureset) )
{
-regs[2] = guest_xfeature_mask & X86_XSS_MASK & 0x;
-regs[3] = (guest_xfeature_mask >> 32) & X86_XSS_MASK;
+regs[2] = (uint32_t)(guest_xfeature_mask & X86_XSS_MASK);
+regs[3] = (guest_xfeature_mask & X86_XSS_MASK) >> 32;
}
else
regs[2] = regs[3] = 0;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools/libxc: Correct use of X86_XSS_MASK in guest xstate generation
On Tue, Apr 19, 2016 at 06:27:05PM +0100, Andrew Cooper wrote:
> c/s 75f9455e "tools/libxc: Calculate xstate cpuid leaf from guest information"
> incorrectly inverted the shift and mask when using X86_XSS_MASK. Luckily, the
> mask is currently zero, avoiding incorrect calculations.
>
> While adjusting this, use an explcit uint32_t cast rather than masking against
> 0x.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Ian Jackson
> CC: Wei Liu
> CC: Jan Beulich
>
> Submitted-from: A punt, on the Cam, during the the hackathon, because.
Acked-by: Wei Liu
Release-acked-by: Wei Liu
On a punt, too, because
> ---
> tools/libxc/xc_cpuid_x86.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index 6d14904..84f4e08 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -460,7 +460,7 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
> {
> case 0:
> /* EAX: low 32bits of xfeature_enabled_mask */
> -regs[0] = guest_xfeature_mask & 0x;
> +regs[0] = (uint32_t)guest_xfeature_mask;
> /* EDX: high 32bits of xfeature_enabled_mask */
> regs[3] = guest_xfeature_mask >> 32;
> /* ECX: max size required by all HW features */
> @@ -487,8 +487,8 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
>
> if ( test_bit(X86_FEATURE_XSAVES, info->featureset) )
> {
> -regs[2] = guest_xfeature_mask & X86_XSS_MASK & 0x;
> -regs[3] = (guest_xfeature_mask >> 32) & X86_XSS_MASK;
> +regs[2] = (uint32_t)(guest_xfeature_mask & X86_XSS_MASK);
> +regs[3] = (guest_xfeature_mask & X86_XSS_MASK) >> 32;
> }
> else
> regs[2] = regs[3] = 0;
> --
> 1.9.1
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8.1 13/27] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>--- a/xen/arch/arm/Makefile
>+++ b/xen/arch/arm/Makefile
>@@ -57,6 +57,8 @@ ifeq ($(CONFIG_ARM_64),y)
>ln -sf $(notdir $@) ../../$(notdir $@).efi
>endif
>
>+tests:
I think this should be phony just like ...
>--- a/xen/arch/x86/Makefile
>+++ b/xen/arch/x86/Makefile
>@@ -76,6 +76,9 @@ $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
>./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x10 \
>`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
>
>+.PHONY: tests
>+tests:
>+ $(MAKE) -f $(BASEDIR)/Rules.mk -C test xsplice
... this one.
>--- /dev/null
>+++ b/xen/arch/x86/test/Makefile
>@@ -0,0 +1,44 @@
>+include $(XEN_ROOT)/Config.mk
>+
>+CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
>+CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
>+
>+.PHONY: default
>+
>+XSPLICE := xen_hello_world.xsplice
>+
>+default: xsplice
>+
>+install: xsplice
>+ $(INSTALL_DATA) $(XSPLICE) $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE)
>+uninstall:
>+ rm -f $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE)
>+
>+.PHONY: clean
>+clean::
>+ rm -f *.o .*.o.d $(XSPLICE) config.h
>+
>+#
>+# To compute these values we need the binary files: xen-syms
>+# and xen_hello_world_func.o to be already compiled.
>+#
>+# We can be assured that xen-syms is already built as we are
>+# the last entry in the build target.
Stale comment afaict.
>+.PHONY: xsplice
>+xsplice: config.h
>+ # Need to have these done in sequential order
>+ $(MAKE) -f $(BASEDIR)/Rules.mk xen_hello_world_func.o
>+ $(MAKE) -f $(BASEDIR)/Rules.mk xen_hello_world.o
Why do these two need doing in order? And why can't $(XSPLICE) not just depend
on its to object files, without needing explict make invocation to generate
them?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 92005: regressions - FAIL
flight 92005 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/92005/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10fail REGR. vs. 59254 test-amd64-amd64-xl 14 guest-saverestore fail REGR. vs. 59254 test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10 fail REGR. vs. 59254 test-amd64-i386-xl 15 guest-localmigratefail REGR. vs. 59254 test-amd64-i386-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 59254 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 14 guest-saverestore fail REGR. vs. 59254 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-armhf-armhf-xl-vhd 9 debian-di-install fail baseline untested test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestore
[Xen-devel] [qemu-mainline test] 92026: regressions - FAIL
flight 92026 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/92026/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 91987 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 91987 test-amd64-amd64-xl-rtds 9 debian-install fail like 91987 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 91987 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuua087cc589d3581a89fdb8c09324941512b5ef300 baseline version: qemuu92b674b62a1aec734280c9019cfb3b3745044b66 Last test of basis91987 2016-04-19 01:20:58 Z0 days Testing same since92026 2016-04-19 10:01:36 Z0 days1 attempts People who touched revisions under test: Eduardo Habkost Peter Maydell Radim KrÄmáŠjobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-a
[Xen-devel] [ovmf test] 92057: regressions - FAIL
flight 92057 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/92057/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 90bb4c577d055e7ac6f0488b21885f65617eec82 baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 133 days Failing since 65593 2015-12-08 23:44:51 Z 132 days 161 attempts Testing same since92057 2016-04-19 17:44:41 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Volker Rümelin Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19874 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8.1 14/27] xsplice, symbols: Implement symbol name resolution on address.
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>--- a/xen/arch/x86/test/xen_hello_world.c
>+++ b/xen/arch/x86/test/xen_hello_world.c
>@@ -10,11 +10,14 @@
>static char hello_world_patch_this_fnc[] = "xen_extra_version";
>extern const char *xen_hello_world(void);
>
>+/* External symbol. */
>+extern const char *xen_extra_version(void);
To give a good example, I think this would better include the respective
header.
>struct xsplice_patch_func __section(".xsplice.funcs") xsplice_xen_hello_world
>= {
>.version = XSPLICE_PAYLOAD_VERSION,
>.name = hello_world_patch_this_fnc,
>.new_addr = (unsigned long)(xen_hello_world),
>-.old_addr = OLD_CODE,
>+.old_addr = (unsigned long)(xen_extra_version),
Pointless parentheses (also btw on the new_addr initializer, which would be
nice to get fixed in the earlier patch).
>+unsigned long symbols_lookup_by_name(const char *symname)
>+{
>+char name[KSYM_NAME_LEN + 1] = { 0 };
I continue to think that this initializer is pointless. And if this or a
variant filling
just the first byte was needed, then please be consistent with the rest of the
function and either use '\0' here or plain 0 in the other two relevant places.
>+uint32_t symnum = 0;
>+char type;
>+uint64_t addr = 0;
Same here.
>+int rc;
>+
>+if ( symname == '\0' )
DYM *symname?
>@@ -51,6 +52,9 @@ struct payload {
>struct list_head applied_list; /* Linked to 'applied_list'. */
>struct xsplice_patch_func_internal *funcs;/* The array of functions
to patch. */
>unsigned int nfuncs; /* Nr of functions to patch. */
>+struct xsplice_symbol *symtab; /* All symbols. */
>+char *strtab;/* Pointer to .strtab. */
At least the latter of the two I'm convinced can be const.
>+unsigned long xsplice_symbols_lookup_by_name(const char *symname)
>+{
>+struct payload *data;
const
>+ASSERT(spin_is_locked(&payload_lock));
>+list_for_each_entry ( data, &payload_list, list )
>+{
>+unsigned int i;
>+
>+for ( i = 0; i < data->nsyms; i++ )
>+{
>+if ( !data->symtab[i].new_symbol )
>+continue;
Do you need symbols other than those marked "new_symbol" past the loading
of the module? If not, wouldn't it be worthwhile to shrink the symbol table to
just
those, likely speeding up the lookup?
>@@ -379,11 +405,129 @@ static int prepare_payload(struct payload *payload,
>for ( j = 0; j < ARRAY_SIZE(f->u.pad); j++ )
>if ( f->u.pad[j] )
>return -EINVAL;
>+
>+/* Lookup function's old address if not already resolved. */
>+if ( !f->old_addr )
>+{
>+f->old_addr = (void *)symbols_lookup_by_name(f->name);
>+if ( !f->old_addr )
>+{
>+f->old_addr = (void *)xsplice_symbols_lookup_by_name(f->name);
The two casts make me wonder whether the two functions shouldn't return
void *, and then whether struct xsplice_symbol's value field shouldn't then
perhaps be void * too.
>+if ( !f->old_addr )
>+{
>+dprintk(XENLOG_ERR, XSPLICE "%s: Could not resolve old
>address of %s\n",
>+elf->name, f->name);
>+return -ENOENT;
>+}
>+}
>+dprintk(XENLOG_DEBUG, XSPLICE "%s: Resolved old address %s =>
>%p\n",
>+elf->name, f->name, f->old_addr);
>+}
>}
>
>return 0;
>}
So one thing I'm realizing only now: Is there no support for using
+
to fill ->old_addr?
>+static bool_t is_payload_symbol(const struct xsplice_elf *elf,
>+const struct xsplice_elf_sym *sym)
>+{
>+if ( sym->sym->st_shndx == SHN_UNDEF ||
>+ sym->sym->st_shndx >= elf->hdr->e_shnum )
>+return 0;
>+
>+return (elf->sec[sym->sym->st_shndx].sec->sh_flags & SHF_ALLOC) &&
>+(ELF64_ST_TYPE(sym->sym->st_info) == STT_OBJECT ||
>+ ELF64_ST_TYPE(sym->sym->st_info) == STT_FUNC);
I don't recall having seen a reply to the question on not allowing STT_NOTYPE
here.
>+static int build_symbol_table(struct payload *payload,
>+ const struct xsplice_elf *elf)
>+{
>+unsigned int i, j, nsyms = 0;
>+size_t strtab_len = 0;
>+struct xsplice_symbol *symtab;
>+char *strtab;
>+
>+ASSERT(payload->nfuncs);
>+
>+/* Recall that section @0 is always NULL. */
>+for ( i = 1; i < elf->nsym; i++ )
>+{
>+if ( is_payload_symbol(elf, elf->sym + i) )
>+{
>+nsyms++;
>+strtab_len += strlen(elf->sym[i].name) + 1;
>+}
>+}
>+
>+symtab = xmalloc_array(struct xsplice_symbol, nsyms);
>+strtab = xmalloc_array(char, strtab_len);
>+
>+if ( !strtab || !symtab )
>+{
>+xfree(strtab);
>+xfree(symtab);
>+return -ENOMEM;
>+}
>+
>+nsyms = 0;
Re: [Xen-devel] [PATCH v8.1 15/27] xsplice, symbols: Implement fast symbol names -> virtual addresses lookup
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>> >NEW CODE: > >To make that work we add three tables: Why three? Two (or a single one with element pairs) ought to be sufficient: Afaict you could just have (symbol-address,symbol-offset) pairs which you then sort and search by name (using symbols_expand_symbol() on symbol-offset, which in turn you store using the result of get_symbol_offset() during setup of the table). >1) symbols_addresses_index_sorted[0..symbols_num_syms]. The values are >indicies into symbols_addresses array. This is a 1-1 table: > >symbols_addresses_index_sorted: >.long 6315 >.long 6097 > >To get the address of a symbol at offset 0 in symbols_name_sorted >(see below) we look in symbols_addresses_index_sorted[0] to get >6315 and then look in symbols_addresses_index[6315] to find it. > >2) The symbols_names_sorted stream - same format as symbols_names but >constructued by sorting the [filename#] by , >then [filename#] and lastly type. Recall that symbol_names is sorted >based on addresses of the symbols. Why would you treat the # prefix specially? The full thing is the symbol you should care about imo. >3) To make it simpler to search we also add an symbols_markers_sorted >array (of size symbols_num_syms/255). >Searching for symbols is simplified as we can do a binary search >on symbol_names_sorted (and using symbols_markers_sorted). Since the >symbols are sorted it takes on average 13 calls to symbols_expand_symbol. > >Doing small tests (search for five different symbols) using the old >and new mechanism show 2ms vs 0ms improvement. What does "2m vs 0ms" improvement mean here? If you mean to say that on some symbols there's no gain at all, then I'd question whether millisecond granularity is enough to see an improvement. With the basic data question above I'm not going to look at the actual code for now; I'll leave this until either I understand why the suggested variant can't work, or until a future version implementing that one. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [seabios test] 92036: tolerable FAIL - PUSHED
flight 92036 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92036/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 88172
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 88172
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
version targeted for testing:
seabios 79bafa1f4037f371b2f03c54647565c9537cc0c2
baseline version:
seabios 6b76e69332719c4c2fb5c47e04cc629ad5dd9b71
Last test of basis88172 2016-03-31 18:02:47 Z 19 days
Testing same since92036 2016-04-19 12:44:29 Z0 days1 attempts
People who touched revisions under test:
Kevin O'Connor
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-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-qemuu-nested-amdfail
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=seabios
+ revision=79bafa1f4037f371b2f03c54647565c9537cc0c2
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push seabios
79bafa1f4037f371b2f03c54647565c9537cc0c2
+ branch=seabios
+ revision=79bafa1f4037f371b2f03c54647565c9537cc0c2
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upst
Re: [Xen-devel] [PATCH v8.1 16/27] x86, xsplice: Print payload's symbol name and payload name in backtraces
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>@@ -331,16 +332,23 @@ static char *pointer(char *str, char *end, const char
>**fmt_ptr,
>{
>unsigned long sym_size, sym_offset;
>char namebuf[KSYM_NAME_LEN+1];
>+bool_t payload = 0;
I don't see the point of this variable. You can simply do ...
>/* Advance parents fmt string, as we have consumed 's' or 'S' */
>++*fmt_ptr;
>
>s = symbols_lookup((unsigned long)arg, &sym_size, &sym_offset,
namebuf);
>-
>-/* If the symbol is not found, fall back to printing the address */
>+/* If the symbol is not found, fall back to printing the address. */
... (perhaps omitting this unrelated style correction) ...
>if ( !s )
>break;
>
>+/*
>+ * namebuf contents and s for core hypervisor are same but for xSplice
>+ * payloads they differ (namebuf contains the name of the payload).
>+ */
>+if ( namebuf != s )
... this comparison ...
>@@ -354,6 +362,13 @@ static char *pointer(char *str, char *end, const char
>**fmt_ptr,
>str = number(str, end, sym_size, 16, -1, -1, SPECIAL);
>}
>
>+if ( payload )
... here.
>+static const char *xsplice_symbols_lookup(unsigned long addr,
>+ unsigned long *symbolsize,
>+ unsigned long *offset,
>+ char *namebuf)
>+{
>+struct payload *data;
const
>+unsigned int i;
>+int best;
>+
>+/*
>+ * No locking since this list is only ever changed during apply or revert
>+ * context.
>+ */
>+list_for_each_entry ( data, &applied_list, applied_list )
>+{
>+if ( (void *)addr < data->text_addr &&
>+ (void *)addr >= (data->text_addr + data->pages * PAGE_SIZE) )
>+continue;
>+
>+best = -1;
>+
>+for ( i = 0; i < data->nsyms; i++ )
>+{
>+if ( data->symtab[i].value <= addr &&
>+ (best == -1 ||
>+ data->symtab[best].value < data->symtab[i].value) )
>+best = i;
Considering this, "best" would probably also better be unsigned int, and
you could then set and compare it to data->nsyms or UINT_MAX.
>+}
>+
>+if ( best == -1 )
>+return NULL;
>+
>+if ( symbolsize )
>+*symbolsize = data->symtab[best].size;
Ah, here is where you need the size.
>@@ -425,6 +475,13 @@ static int prepare_payload(struct payload *payload,
>}
>}
>
>+/* Setup the virtual region with proper data. */
>+region = &payload->region;
>+
>+region->symbols_lookup = xsplice_symbols_lookup;
>+region->start = (unsigned long)payload->text_addr;
>+region->end = (unsigned long)(payload->text_addr + payload->text_size);
Again makes questionable whether region's start and end fields wouldn't better
be
const void *.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8.1 17/27] xsplice: Add support for bug frames.
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>+bool_t is_patch(const void *ptr)
>+{
>+struct payload *data;
You guess it: const.
>+/*
>+ * No locking since this list is only ever changed during apply or revert
>+ * context.
>+ */
What if you crash while applying or reverting a patch? Is the list update at
least done such that the (then nested) traversal remains safe?
>@@ -482,6 +508,30 @@ static int prepare_payload(struct payload *payload,
>region->start = (unsigned long)payload->text_addr;
>region->end = (unsigned long)(payload->text_addr + payload->text_size);
>
>+/* Optional sections. */
>+for ( i = 0; i < BUGFRAME_NR; i++ )
>+{
>+char str[14];
>+
>+snprintf(str, sizeof(str), ".bug_frames.%u", i);
>+sec = xsplice_elf_sec_by_name(elf, str);
>+if ( !sec )
>+continue;
>+
>+if ( sec->sec->sh_size &&
>+ (sec->sec->sh_size % sizeof(*region->frame[i].bugs)) )
The left side of the && seems pointless.
>+{
>+dprintk(XENLOG_ERR, XSPLICE "%s: Wrong size of .bug_frames.%u!\n",
>+elf->name, i);
>+return -EINVAL;
>+}
>+
>+region->frame[i].bugs = sec->load_addr;
>+if ( sec->sec->sh_size)
>+region->frame[i].n_bugs = sec->sec->sh_size /
>+ sizeof(*region->frame[i].bugs);
As does the conditional here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8.1 18/27] xsplice: Add support for exception tables.
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>@@ -48,19 +49,23 @@ static void __init swap_ex(void *a, void *b, int size)
>}
>#endif
>
>-void __init sort_exception_tables(void)
>+void __INIT sort_exception_table(struct exception_table_entry *start,
>+ struct exception_table_entry *stop)
The latter can (and hence should) be const.
>--- a/xen/arch/x86/test/xen_hello_world_func.c
>+++ b/xen/arch/x86/test/xen_hello_world_func.c
>@@ -5,9 +5,20 @@
>
>#include
>
>+static unsigned long *non_canonical_addr = (unsigned long
>*)(0xdeadULL);
Stray parentheses.
>--- a/xen/include/xen/xsplice.h
>+++ b/xen/include/xen/xsplice.h
>@@ -43,6 +43,15 @@ struct xsplice_patch_func_internal {
>} u;
>};
>
>+/*
>+ * We use alternative and exception table code - which by default are __init
>+ * only, however we need them during runtime. These macros allows us to build
>+ * the image with these functions built-in. (See the #else below).
>+ */
>+#define __INITCONST
>+#define __INITDATA
>+#define __INIT
I'm generally opposed to new symbols with double underscores in front of
them. Maybe (considering the non-xSplice case) in this case they're warranted,
but I'd prefer something along the lines of Linux'es __init_or_module (without
the double underscores then of course).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools/xenstat: handle network interface name in uppercase.
Could anyone have a look at this patch?
Thanks,
Zhigang
On 03/11/2016 03:18 PM, Zhigang Wang wrote:
> xentop will segmentation fault in this case:
>
> # ip link set eth1 down
> # ip link set eth1 name ETH
> # xentop
>
> This patch will let xentop to handle all uppercase network interface name.
>
> Signed-off-by: Zhigang Wang
> ---
> tools/xenstat/libxenstat/src/xenstat_linux.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/tools/xenstat/libxenstat/src/xenstat_linux.c
> b/tools/xenstat/libxenstat/src/xenstat_linux.c
> index 931b24e..d33eca1 100644
> --- a/tools/xenstat/libxenstat/src/xenstat_linux.c
> +++ b/tools/xenstat/libxenstat/src/xenstat_linux.c
> @@ -101,6 +101,7 @@ int parseNetDevLine(char *line, char *iface, unsigned
> long long *rxBytes, unsign
> /* Temporary/helper variables */
> int ret;
> char *tmp;
> + char *tmp2;
> int i = 0, x = 0, col = 0;
> regex_t r;
> regmatch_t matches[19];
> @@ -221,8 +222,11 @@ int parseNetDevLine(char *line, char *iface, unsigned
> long long *rxBytes, unsign
> }
> else
> /* There were errors when parsing this directly
> in RE. strpbrk() helps */
> - if (iface != NULL)
> - strcpy(iface, strpbrk(tmp,
> "abcdefghijklmnopqrstvuwxyz0123456789"));
> + if (iface != NULL) {
> + tmp2 = strpbrk(tmp,
> "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789");
> + if (tmp2 != NULL)
> + strcpy(iface, tmp2);
> + }
>
> memset(tmp, 0, matches[i].rm_eo -
> matches[i].rm_so);
> }
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 92074: regressions - FAIL
flight 92074 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/92074/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 90bb4c577d055e7ac6f0488b21885f65617eec82 baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 133 days Failing since 65593 2015-12-08 23:44:51 Z 132 days 162 attempts Testing same since92057 2016-04-19 17:44:41 Z0 days2 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Volker Rümelin Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19874 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 92071: tolerable FAIL - PUSHED
flight 92071 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/92071/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 91987 test-amd64-amd64-xl-rtds 9 debian-install fail like 91987 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 91987 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuu1f7685fafa6ba1354731a59822e5cc43323d6989 baseline version: qemuu92b674b62a1aec734280c9019cfb3b3745044b66 Last test of basis91987 2016-04-19 01:20:58 Z0 days Failing since 92026 2016-04-19 10:01:36 Z0 days2 attempts Testing same since92071 2016-04-19 19:41:51 Z0 days1 attempts People who touched revisions under test: Aurelien Jarno David Gibson Eduardo Habkost Gabriel Somlo Gerd Hoffmann Markus Armbruster Michael S. Tsirkin Peter Maydell Radim KrÄmáŠjobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-
[Xen-devel] [seabios baseline-only test] 44345: tolerable FAIL
This run is configured for baseline tests only. flight 44345 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44345/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 44287 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 44287 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44287 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: seabios 79bafa1f4037f371b2f03c54647565c9537cc0c2 baseline version: seabios 6b76e69332719c4c2fb5c47e04cc629ad5dd9b71 Last test of basis44287 2016-04-01 20:20:07 Z 18 days Testing same since44345 2016-04-19 20:20:45 Z0 days1 attempts People who touched revisions under test: Kevin O'Connor 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 79bafa1f4037f371b2f03c54647565c9537cc0c2 Author: Kevin O'Connor Date: Tue Apr 5 13:04:07 2016 -0400 scsi: Launch a thread when scanning for drives in the scsi drivers Signed-off-by: Kevin O'Connor commit b35ea54a7586bbfb004ebf4c928d9b18b8a974fa Author: Kevin O'Connor Date: Fri Apr 1 20:05:45 2016 -0400 virtio: Use threads when scanning for virtio devices Signed-off-by: Kevin O'Connor commit d449a117a501ecf95e36a11526140ffc91073f56 Author: Kevin O'Connor Date: Fri Apr 1 15:45:29 2016 -0400 shadow: Batch PCI config writes Enabling and disabling shadow ram on QEMU is slow. Batch the PCI writes to reduce the number of memory changes QEMU must implement. Signed-off-by: Kevin O'Connor commit 9d691acee08bf6c5ef7ffc99ad6010f6ec1a0adc Author: Kevin O'Connor Date: Fri Apr 1 14:23:36 2016 -0400 optionroms: Drop support for CONFIG_OPTIONROMS_DEPLOYED No modern software uses this option and it complicates the code. Signed-off-by: Kevin O'Connor commit 8ef686f6709329edbe9d433ec46410a764348bf8 Author: Kevin O'Connor Date: Thu Mar 31 14:29:07 2016 -0400 disk: Avoid stack_hop() path if already on the extra stack If CONFIG_ENTRY_EXTRASTACK is set (enabled by default) then the 16bit disk interface code is already running on the extra stack and it is not necessary to support stack switching on each disk request. Signed-off-by: Kevin O'Connor commit 193632b63fda830694ffa47df21308c1d0c36acd Author: K
[Xen-devel] [ovmf test] 92097: regressions - FAIL
flight 92097 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/92097/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 90bb4c577d055e7ac6f0488b21885f65617eec82 baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 133 days Failing since 65593 2015-12-08 23:44:51 Z 133 days 163 attempts Testing same since92057 2016-04-19 17:44:41 Z0 days3 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Volker Rümelin Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19874 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 92111: regressions - FAIL
flight 92111 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/92111/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 6b17c11b6f45b4196adb8a9fcbdba5576a0d872b baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 133 days Failing since 65593 2015-12-08 23:44:51 Z 133 days 164 attempts Testing same since92111 2016-04-20 01:52:37 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Volker Rümelin Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19925 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 03/11] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
On April 19, 2016 2:44pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > If IOMMU mapping and unmapping failed, the domain (with the exception
> > of the hardware domain) is crashed, treated as a fatal error. Rollback
> > can be lighter weight.
>
> What do you mean by 'lighter weight"? Please clarify it.
>
> >
> > For the hardware domain, we do things on a best effort basis. When
> > rollback is not feasible (in early initialization phase or trade-off
> > of complexity), at least, unmap upon maps error or then throw out error
> message.
>
> remove 'or'. Based on next sentence, is above specific for IOMMU mapping?
>
> >
> > IOMMU unmapping should perhaps continue despite an error, in an
> > attempt to do best effort cleanup.
> >
Could I enhance the commit log as below:
"""
If IOMMU mapping and unmapping failed, the domain (with the exception of the
hardware domain) is crashed,
treated as a fatal error. Rollback can be lighter weight (at least errors need
to be propagated).
IOMMU mapping breaks for an error, unmapping upon maps, throwing out error
message and then reporting
the error up the call trees. When rollback is not feasible (in early
initialization phase or trade-off of complexity)
for the hardware domain, we do things on a best effort basis, only throwing out
error message.
IOMMU unmapping should perhaps continue despite an error, in an attempt to do
best effort cleanup.
"""
I am still not sure whether we really need throw out error message for each
IOMMU mapping or not.
If yes, I will throw out error message for each IOMMU mapping in next v3.
> > Signed-off-by: Quan Xu
> >
> > CC: Keir Fraser
> > CC: Jan Beulich
> > CC: Andrew Cooper
> > CC: Jun Nakajima
> > CC: Kevin Tian
> > CC: George Dunlap
> > ---
> > xen/arch/x86/mm.c | 13 -
> > xen/arch/x86/mm/p2m-ept.c | 25 ++---
> > xen/arch/x86/mm/p2m-pt.c| 22 ++
> > xen/arch/x86/mm/p2m.c | 11 +--
> > xen/drivers/passthrough/iommu.c | 14 +-
> > 5 files changed, 70 insertions(+), 15 deletions(-)
> >
> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index
> > c997b53..5c4fb58 100644
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info
> > *page, unsigned long type,
> > int preemptible) {
> > unsigned long nx, x, y = page->u.inuse.type_info;
> > -int rc = 0;
> > +int rc = 0, ret = 0;
> >
> > ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
> >
> > @@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info
> > *page, unsigned long type,
> > if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
> > {
> > if ( (x & PGT_type_mask) == PGT_writable_page )
> > -iommu_unmap_page(d, mfn_to_gmfn(d,
> page_to_mfn(page)));
> > +ret = iommu_unmap_page(d, mfn_to_gmfn(d,
> > + page_to_mfn(page)));
> > else if ( type == PGT_writable_page )
> > -iommu_map_page(d, mfn_to_gmfn(d,
> page_to_mfn(page)),
> > - page_to_mfn(page),
> > -
> IOMMUF_readable|IOMMUF_writable);
> > +ret = iommu_map_page(d, mfn_to_gmfn(d,
> page_to_mfn(page)),
> > + page_to_mfn(page),
> > +
> > + IOMMUF_readable|IOMMUF_writable);
> > }
> > }
> >
> > @@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info
> > *page, unsigned long type,
> > if ( (x & PGT_partial) && !(nx & PGT_partial) )
> > put_page(page);
> >
> > +if ( unlikely(ret) )
> > +rc = ret;
> > +
> > return rc;
> > }
> >
> > diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> > index 3cb6868..22c8d17 100644
> > --- a/xen/arch/x86/mm/p2m-ept.c
> > +++ b/xen/arch/x86/mm/p2m-ept.c
> > @@ -665,7 +665,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned
> > long gfn, mfn_t mfn,
> > ept_entry_t *table, *ept_entry = NULL;
> > unsigned long gfn_remainder = gfn;
> > unsigned int i, target = order / EPT_TABLE_ORDER;
> > -int ret, rc = 0;
> > +int ret, err = 0, rc = 0;
> > bool_t direct_mmio = (p2mt == p2m_mmio_direct);
> > uint8_t ipat = 0;
> > bool_t need_modify_vtd_table = 1; @@ -830,10 +830,26 @@ out:
> > {
> > if ( iommu_flags )
> > for ( i = 0; i < (1 << order); i++ )
> > -iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
> iommu_flags);
> > +{
> > +ret = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
> > + iommu_flags);
> > +
> > +if ( unlikely(ret) )
> > +{
> > +while (i)
> > +iommu_unmap_page(d, gfn + --i);
>
> How about below?
>
> while (i-- >= 0)
> iommu_unmap_page(d,
Re: [Xen-devel] [PATCH v2 04/11] grant_table: avoid unnecessary work during grant table unmapping
> From: Xu, Quan > Sent: Tuesday, April 19, 2016 9:28 PM > > On April 19, 2016 2:46pm, Tian, Kevin wrote: > > > From: Quan Xu > > > Sent: Monday, April 18, 2016 10:00 PM > > > > > > While grant table is unmapping, the domain (with the exception of the > > > > unmapping -> unmapped. > > > > A slightly different take, IMO the hypercall is not returned, so it is DOING. More accurately you might want to say "When a granted page is being unmapped". > > > > > hardware domain) may be crashed due to IOMMU mapping and unmapping > > > failures, and then it is unnecessary to flush specified CPUs' TLBs. > > > > Above description is not complete. You said "with the exception of the > > hardware domain". Then people will ask whether 'unnecessary' > > is also true for hardware domain (if not restriction for hardware domain to > > invoke those interfaces). > > > > Make sense. > Could I only drop '(with the exception of the hardware domain)'? > Still didn't get the rationale here. After another look at the patch, actually I'm even not sure how the change is related to the purpose of this patch series. Also the change is opposite to your comment - you limit flush to crashed domain instead: > > -fault: > > -gnttab_flush_tlb(current->domain); > > + fault: > > +if ( current->domain->is_shut_down ) > > +gnttab_flush_tlb(current->domain); Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 03/11] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
> From: Xu, Quan
> Sent: Wednesday, April 20, 2016 1:27 PM
>
> On April 19, 2016 2:44pm, Tian, Kevin wrote:
> > > From: Xu, Quan
> > > Sent: Monday, April 18, 2016 10:00 PM
> > >
> > > If IOMMU mapping and unmapping failed, the domain (with the exception
> > > of the hardware domain) is crashed, treated as a fatal error. Rollback
> > > can be lighter weight.
> >
> > What do you mean by 'lighter weight"? Please clarify it.
> >
> > >
> > > For the hardware domain, we do things on a best effort basis. When
> > > rollback is not feasible (in early initialization phase or trade-off
> > > of complexity), at least, unmap upon maps error or then throw out error
> > message.
> >
> > remove 'or'. Based on next sentence, is above specific for IOMMU mapping?
> >
> > >
> > > IOMMU unmapping should perhaps continue despite an error, in an
> > > attempt to do best effort cleanup.
> > >
>
>
>
> Could I enhance the commit log as below:
> """
> If IOMMU mapping and unmapping failed, the domain (with the exception of the
> hardware
> domain) is crashed,
> treated as a fatal error. Rollback can be lighter weight (at least errors
> need to be
> propagated).
Still not clear about 'lighter weight'. Then what is the 'heavier weight' side
then?
Isn't "at least errors need to be propagated" exactly what 'rollback' means?
>
> IOMMU mapping breaks for an error, unmapping upon maps, throwing out error
> message
> and then reporting
> the error up the call trees. When rollback is not feasible (in early
> initialization phase or
> trade-off of complexity)
> for the hardware domain, we do things on a best effort basis, only throwing
> out error
> message.
If above elaborates what earlier 'lighter weight" means, then please just
say a best-effort rollack.
>
> IOMMU unmapping should perhaps continue despite an error, in an attempt to do
> best
> effort cleanup.
> """
>
>
> I am still not sure whether we really need throw out error message for each
> IOMMU
> mapping or not.
> If yes, I will throw out error message for each IOMMU mapping in next v3.
I'm not sure about your question here. Have to judge based on specific case.
> > > {
> > > if ( iommu_flags )
> > > for ( i = 0; i < (1 << order); i++ )
> > > -iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
> > iommu_flags);
> > > +{
> > > +ret = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
> > > + iommu_flags);
> > > +
> > > +if ( unlikely(ret) )
> > > +{
> > > +while (i)
> > > +iommu_unmap_page(d, gfn + --i);
> >
> > How about below?
> >
> > while (i-- >= 0)
> > iommu_unmap_page(d, gfn + i);
> >
>
> this modification is based on discussion rooted at
> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01779.html
> wait for Jan's decision.
Either way is OK. 'gfn + --I' just looks not very readable to me.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 03/11] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
>>> "Xu, Quan" 04/20/16 7:29 AM >>>
>I am still not sure whether we really need throw out error message for each
>IOMMU mapping or not.
>If yes, I will throw out error message for each IOMMU mapping in next v3.
Ideally not, if it's a batch that it failing, The question just is whether at
the point you
issue the error message you can know another got already emitted. In no case
must this lead to spamming of the console originating from an unprivileged
domain.
>> > +if ( unlikely(ret) )
>> > +{
>> > +while (i)
>> > +iommu_unmap_page(d, gfn + --i);
>>
>> How about below?
>>
>> while (i-- >= 0)
>> iommu_unmap_page(d, gfn + i);
>
>this modification is based on discussion rooted at
>http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01779.html
>wait for Jan's decision.
But did you really _follow_ that discussion? The adjustment done by that patch
was specifically not deemed good, so the shape Kevin suggests is in line with
the outcome of that discussion (except that I'd suggest omitting the ">= 0", the
more that i at least ought to be unsigned here).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 92126: regressions - FAIL
flight 92126 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/92126/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 91479 build-i386-libvirt5 libvirt-build fail REGR. vs. 91479 build-armhf-libvirt 5 libvirt-build fail REGR. vs. 91479 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt 0d1579572a864c33621da4d01408f8bcb6de5d4a baseline version: libvirt 8b62c65d24bdb20121d3147b4f4dc98bac4f024b Last test of basis91479 2016-04-15 05:33:51 Z5 days Failing since 91597 2016-04-16 04:20:46 Z4 days5 attempts Testing same since92126 2016-04-20 04:23:42 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Cole Robinson Dmitry Andreev Erik Skultety Jason J. Herne Jim Fehlig Jiri Denemark John Ferlan Ján Tomko Laine Stump Martin Kletzander Maxim Nestratov Michal Privoznik Mikhail Feoktistov Nikolay Shirokovskiy Nitesh Konkar Nitesh Konkar Olga Krishtal Peter Krempa Richard Laager Richard W.M. Jones jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-armhf-armhf-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 949 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 44346: regressions - FAIL
ention FW CFG's primary user is QEMU, which uses it to expose configuration information (in the widest sense) to Firmware. Thus the name FW CFG. FW CFG can also be used by others for their own purposes. QEMU is merely acting as transport then. Names starting with opt/ are reserved for such uses. There is no provision, however, to guide safe sharing among different such users. Fix that, loosely following QMP precedence: names should start with opt/RFQDN/, where RFQDN is a reverse fully qualified domain name you control. Based on a more ambitious patch from Michael Tsirkin. Cc: Gerd Hoffmann Cc: Gabriel L. Somlo Cc: Laszlo Ersek Cc: Michael S. Tsirkin Signed-off-by: Markus Armbruster Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Acked-by: Gabriel Somlo Reviewed-by: Laszlo Ersek commit ef5d5641f5f35f64a7f150bb3593dae0c08f236d Merge: bb97bfd a49923d Author: Peter Maydell Date: Tue Apr 19 12:10:30 2016 +0100 Merge remote-tracking branch 'remotes/kraxel/tags/pull-usb-20160419-1' into staging ehci: fix (s)iTD looping issue (CVE-2015-8558) in a different way. # gpg: Signature made Tue 19 Apr 2016 07:22:22 BST using RSA key ID D3E87138 # gpg: Good signature from "Gerd Hoffmann (work) " # gpg: aka "Gerd Hoffmann " # gpg: aka "Gerd Hoffmann (private) " * remotes/kraxel/tags/pull-usb-20160419-1: Revert "ehci: make idt processing more robust" ehci: apply limit to iTD/sidt descriptors Signed-off-by: Peter Maydell commit bb97bfd90194eb3c6995b446643af4818a142805 Merge: 5eb0b19 ed3d807 Author: Peter Maydell Date: Tue Apr 19 11:15:32 2016 +0100 Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.6-20160419' into staging ppc patch queueu for 2016-04-19 A single fix for a regression since 2.5. This should be the last ppc pull request for 2.6. # gpg: Signature made Tue 19 Apr 2016 02:48:30 BST using RSA key ID 20D9B392 # gpg: Good signature from "David Gibson " # gpg: aka "David Gibson (Red Hat) " # gpg: aka "David Gibson (ozlabs.org) " # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.6-20160419: cuda: fix off-by-one error in SET_TIME command Signed-off-by: Peter Maydell commit 5eb0b194e9b01ba0f3613e6ddc2cb9f63ce96ae5 Author: Michael S. Tsirkin Date: Mon Apr 18 13:07:35 2016 +0300 cadence_uart: bounds check write offset cadence_uart_init() initializes an I/O memory region of size 0x1000 bytes. However in uart_write(), the 'offset' parameter (offset within region) is divided by 4 and then used to index the array 'r' of size CADENCE_UART_R_MAX which is much smaller: (0x48/4). If 'offset>>=2' exceeds CADENCE_UART_R_MAX, this will cause an out-of-bounds memory write where the offset and the value are controlled by guest. This will corrupt QEMU memory, in most situations this causes the vm to crash. Fix by checking the offset against the array size. Cc: qemu-sta...@nongnu.org Reported-by: æ强 Signed-off-by: Michael S. Tsirkin Reviewed-by: Alistair Francis Message-id: 20160418100735.ga...@redhat.com Signed-off-by: Peter Maydell commit a087cc589d3581a89fdb8c09324941512b5ef300 Merge: 92b674b 9997cf7 Author: Peter Maydell Date: Tue Apr 19 10:11:17 2016 +0100 Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging X86 fix for 2.6.0-rc3 # gpg: Signature made Mon 18 Apr 2016 20:02:15 BST using RSA key ID 984DC5A6 # gpg: Good signature from "Eduardo Habkost " * remotes/ehabkost/tags/x86-pull-request: target-i386: Set AMD alias bits after filtering CPUID data Signed-off-by: Peter Maydell commit a49923d2837d20510d645d3758f1ad87c32d0730 Author: Gerd Hoffmann Date: Mon Apr 18 09:20:54 2016 +0200 Revert "ehci: make idt processing more robust" This reverts commit 156a2e4dbffa85997636a7a39ef12da6f1b40254. Breaks FreeBSD. Signed-off-by: Gerd Hoffmann commit 1ae3f2f178087711f9591350abad133525ba93f2 Author: Gerd Hoffmann Date: Mon Apr 18 09:11:38 2016 +0200 ehci: apply limit to iTD/sidt descriptors Commit "156a2e4 ehci: make idt processing more robust" tries to avoid a DoS by the guest (create a circular iTD queue and let qemu ehci emulation run in circles
Re: [Xen-devel] [PATCH v2 03/11] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
On April 20, 2016 2:12pm, wrote:
> >>> "Xu, Quan" 04/20/16 7:29 AM >>>
> Ideally not, if it's a batch that it failing, The question just is whether at
> the point
> you issue the error message you can know another got already emitted. In no
> case must this lead to spamming of the console originating from an
> unprivileged
> domain.
>
> >> > +if ( unlikely(ret) )
> >> > +{
> >> > +while (i)
> >> > +iommu_unmap_page(d, gfn + --i);
> >>
> >> How about below?
> >>
> >> while (i-- >= 0)
> >>iommu_unmap_page(d, gfn + i);
> >
> >this modification is based on discussion rooted at
> >http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01779.ht
> >ml
> >wait for Jan's decision.
>
> But did you really _follow_ that discussion? The adjustment done by that patch
> was specifically not deemed good, so the shape Kevin suggests is in line with
> the
> outcome of that discussion (except that I'd suggest omitting the ">= 0", the
> more that i at least ought to be unsigned here).
>
Based on your suggestions, I will fix it as below:
+while ( i-- )
+iommu_unmap_page(d, gfn + i);
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8.1 19/27] xsplice: Add support for alternatives
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>--- a/xen/arch/x86/Makefile
>+++ b/xen/arch/x86/Makefile
>@@ -6,7 +6,11 @@ subdir-y += mm
>subdir-$(CONFIG_XENOPROF) += oprofile
>subdir-y += x86_64
>
>+ifdef CONFIG_XSPLICE
>+obj-y += alternative.o
>+else
>obj-bin-y += alternative.init.o
>+endif
For now this is okay, but please try to use the list model in favor of ifdef-s
in
the future, whenever possible.
>#ifdef K8_NOP1
>-static const unsigned char k8nops[] __initconst = {
>+static const unsigned char k8nops[] __INITCONST = {
>K8_NOP1,
>K8_NOP2,
>K8_NOP3,
>@@ -52,7 +53,7 @@ static const unsigned char * const k8_nops[ASM_NOP_MAX+1]
>__initconstrel = {
The context here suggests you didn't complete your conversion work: The
__initconstrel hardly can remain unchanged if the objects are now being
referenced by objects in non-init sections.
>@@ -125,9 +126,10 @@ static void __init add_nops(void *insns, unsigned int len)
>* instructions. And on the local CPU you need to be protected again NMI or
MCE
>* handlers seeing an inconsistent instruction while you patch.
>*
>- * This routine is called with local interrupt disabled.
>+ * You should run this with interrupts disabled or on code that has never
>+ * been executed.
The second half is misleading - there's no such requirement for early boot
patching. The requirement is that the code must not currently be executing
(which at that time is guaranteed by there only being a single CPU, which
is in a well defined region of code).
>@@ -12,6 +15,8 @@ const char *xen_hello_world(void)
>{
>unsigned long tmp;
>int rc;
>+
>+alternative(ASM_NOP1, ASM_NOP1, X86_FEATURE_LM);
So to cover the issue pointed out above you should be patching a longer
instruction with a shorter one here.
>--- a/xen/common/xsplice.c
>+++ b/xen/common/xsplice.c
>@@ -533,6 +533,39 @@ static int prepare_payload(struct payload *payload,
>}
>
>#ifndef CONFIG_ARM
>+sec = xsplice_elf_sec_by_name(elf, ".altinstructions");
>+if ( sec )
>+{
>+struct alt_instr *a, *start, *end;
>+
>+if ( !sec->sec->sh_size ||
Once again I don't see what harm a zero size section would do.
>+ (sec->sec->sh_size % sizeof(*a)) )
>+{
>+dprintk(XENLOG_ERR, XSPLICE "%s: Wrong size of .alt_instr
>(exp:%lu vs %lu)!\n",
>+elf->name, sizeof(*a),
sizeof() wants to be formatted with %zu and ...
>+sec->sec->sh_size);
... didn't you add an ELF-specific format macro for cases like this?
Also if you printed the message outside of the conditional, expected and actual
values would likely disagree anyway (as soon as there are multiple entries), so
some editing of the text would be nice too.
>+return -EINVAL;
>+}
>+
>+start = sec->load_addr;
>+end = sec->load_addr + sec->sec->sh_size;
>+
>+for ( a = start; a < end; a++ )
>+{
>+unsigned long instr = (unsigned long)(&a->instr_offset +
>a->instr_offset);
>+unsigned long replacement = (unsigned long)(&a->repl_offset +
>a->repl_offset);
>+
>+if ( (instr < region->start && instr >= region->end) ||
>+ (replacement < region->start && replacement >= region->end) )
>+{
>+dprintk(XENLOG_ERR, XSPLICE "%s Alt patching outside payload:
>0x%lx!\n",
%#lx please
>@@ -555,6 +588,7 @@ static int prepare_payload(struct payload *payload,
>region->ex = s;
>region->ex_end = e;
>}
>+
>#endif
Stray addition of a blank line.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
