[Xen-devel] [xen-unstable-smoke test] 103385: regressions - FAIL
flight 103385 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103385/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen ca01e5821245ff547fecdf091c29f45e5aba58cf baseline version: xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5 Last test of basis 103284 2016-12-13 19:03:56 Z1 days Failing since103292 2016-12-13 22:19:08 Z1 days 12 attempts Testing same since 103364 2016-12-14 22:02:45 Z0 days4 attempts People who touched revisions under test: Andrew Cooper Cédric Bosdonnat Ian Jackson Jan Beulich Juergen Gross Konrad Rzeszutek Wilk Ross Lagerwall Stefano Stabellini Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt 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 407 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 103312: regressions - FAIL
flight 103312 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103312/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 9 xen-boot/src_hostfail REGR. vs. 101675 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 101675 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-amd64-pvgrub 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail REGR. vs. 101675 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 101675 test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101675 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101675 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101675 build-i386-pvops 5 kernel-build fail in 102732 REGR. vs. 101675 build-armhf-libvirt 4 host-build-prep fail in 102875 REGR. vs. 101675 Tests which are failing intermittently (not blocking): test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 102732 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 102732 test-amd64-amd64-xl-xsm 6 xen-boot fail pass in 102732 test-amd64-amd64-i386-pvgrub 6 xen-boot fail pass in 102754 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 102823 test-amd64-amd64-libvirt 6 xen-boot fail pass in 102823 test-amd64-amd64-xl-credit2 6 xen-boot fail pass in 102875 test-amd64-i386-xl-raw6 xen-boot fail pass in 102875 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail pass in 102974 test-amd64-i386-freebsd10-i386 6 xen-boot fail pass in 103169 test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail pass in 103169 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail in 102823 like 101675 test-armhf-armhf-xl-vhd 9 debian-di-install fail in 103169 like 101662 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 101662 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 101675 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 101675 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 101675 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101675 test-amd64-amd64-xl-rtds 9 debian-install fail like 101675 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101675 Tests which did not succeed, but are not blocking: test-amd64-i386-freebsd10-i386 1 build-check(1) blocked in 102732 n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 102732 n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 102732 n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked in 102732 n/a test-amd64-i386-freebsd10-amd64 1 build-check(1)blocked in 102732 n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl1 build-check(1) blocked in 102732 n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-xsm1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1)blocked in 102732 n/a test-amd64-i386-xl-raw1 build-check(1) blocked in 102732 n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked in 102732 n/a test-amd64-i386-libvirt
[Xen-devel] [XEN VMID PATCH 1/2] xen/arm: Move p2m_vmid_allocator_init() inside setup_virt_paging()
Since VMIDs are related to 2nd stage address translation, it makes more sense
to move the call to p2m_vmid_allocator_init(), which initializes the vmid
allocation bitmap, inside setup_virt_paging(), where 2nd stage address
translation
is set up.
Signed-off-by: Bhupinder Thakur
Reviewed-by: Julien Grall
---
xen/arch/arm/p2m.c| 5 -
xen/arch/arm/setup.c | 2 --
xen/include/asm-arm/p2m.h | 3 ---
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index cc5634b..2327509 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1241,7 +1241,7 @@ static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
*/
static DECLARE_BITMAP(vmid_mask, MAX_VMID);
-void p2m_vmid_allocator_init(void)
+static void p2m_vmid_allocator_init(void)
{
set_bit(INVALID_VMID, vmid_mask);
}
@@ -1659,6 +1659,9 @@ void __init setup_virt_paging(void)
#endif
printk("P2M: %d levels with order-%d root, VTCR 0x%lx\n",
4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, val);
+
+p2m_vmid_allocator_init();
+
/* It is not allowed to concatenate a level zero root */
BUG_ON( P2M_ROOT_LEVEL == 0 && P2M_ROOT_ORDER > 0 );
setup_virt_paging_one((void *)val);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 38eb888..ac49515 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -789,8 +789,6 @@ void __init start_xen(unsigned long boot_phys_offset,
gic_init();
-p2m_vmid_allocator_init();
-
softirq_init();
tasklet_subsys_init();
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index fdb6b47..0987be2 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -152,9 +152,6 @@ void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
/* Not supported on ARM. */
}
-/* Initialise vmid allocator */
-void p2m_vmid_allocator_init(void);
-
/* Second stage paging setup, to be called on all CPUs */
void setup_virt_paging(void);
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [XEN VMID PATCH 2/2 v4] xen/arm: Add support for 16 bit VMIDs
VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision. This allows more than 256 VMs to be supported by Xen. This change adds support for 16-bit VMIDs in Xen based on whether the architecture supports it. Signed-off-by: Bhupinder Thakur --- xen/arch/arm/p2m.c | 45 +++-- xen/include/asm-arm/p2m.h | 2 +- xen/include/asm-arm/processor.h | 18 - 3 files changed, 57 insertions(+), 8 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 2327509..b166122 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -14,15 +15,23 @@ #include #include +#define MAX_VMID_8_BIT (1UL << 8) +#define MAX_VMID_16_BIT (1UL << 16) + +#define INVALID_VMID 0 /* VMID 0 is reserved */ + #ifdef CONFIG_ARM_64 static unsigned int __read_mostly p2m_root_order; static unsigned int __read_mostly p2m_root_level; #define P2M_ROOT_ORDERp2m_root_order #define P2M_ROOT_LEVEL p2m_root_level +static unsigned int __read_mostly max_vmid = MAX_VMID_8_BIT; +#define MAX_VMID max_vmid #else /* First level P2M is alway 2 consecutive pages */ #define P2M_ROOT_LEVEL 1 #define P2M_ROOT_ORDER1 +#define MAX_VMIDMAX_VMID_8_BIT #endif #define P2M_ROOT_PAGES(1vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) << 48; +p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid << 48); /* * Make sure that all TLBs corresponding to the new VMID are flushed @@ -1230,19 +1239,27 @@ static int p2m_alloc_table(struct domain *d) return 0; } -#define MAX_VMID 256 -#define INVALID_VMID 0 /* VMID 0 is reserved */ static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED; /* - * VTTBR_EL2 VMID field is 8 bits. Using a bitmap here limits us to - * 256 concurrent domains. + * VTTBR_EL2 VMID field is 8 or 16 bits. Aarch64 supports 16-bit VMID. + * Using a bitmap here limits us to 256 or 65536 (for Aarch64) concurrent + * domains. The bitmap space will be allocated dynamically based on + * whether 8 or 16 bit VMIDs are supported. */ -static DECLARE_BITMAP(vmid_mask, MAX_VMID); +static unsigned long *vmid_mask; static void p2m_vmid_allocator_init(void) { +/* + * allocate space for vmid_mask based on MAX_VMID + */ +vmid_mask = xzalloc_array(unsigned long, BITS_TO_LONGS(MAX_VMID)); + +if ( !vmid_mask ) +panic("Could not allocate VMID bitmap space"); + set_bit(INVALID_VMID, vmid_mask); } @@ -1632,20 +1649,36 @@ void __init setup_virt_paging(void) unsigned int cpu; unsigned int pa_range = 0x10; /* Larger than any possible value */ +bool vmid_8_bit = false; for_each_online_cpu ( cpu ) { const struct cpuinfo_arm *info = &cpu_data[cpu]; if ( info->mm64.pa_range < pa_range ) pa_range = info->mm64.pa_range; + +/* set a flag if the current cpu does not suppot 16 bit VMIDs */ +if ( info->mm64.vmid_bits != MM64_VMID_16_BITS_SUPPORT ) +vmid_8_bit = true; } +/* + * if the flag is not set then it means all CPUs support 16-bit + * VMIDs. + */ +if ( !vmid_8_bit ) +max_vmid = MAX_VMID_16_BIT; + /* pa_range is 4 bits, but the defined encodings are only 3 bits */ if ( pa_range&0x8 || !pa_range_info[pa_range].pabits ) panic("Unknown encoding of ID_AA64MMFR0_EL1.PARange %x\n", pa_range); val |= VTCR_PS(pa_range); val |= VTCR_TG0_4K; + +/* set the VS bit only if 16 bit VMID is supported */ +if ( MAX_VMID == MAX_VMID_16_BIT ) +val |= VTCR_VS; val |= VTCR_SL0(pa_range_info[pa_range].sl0); val |= VTCR_T0SZ(pa_range_info[pa_range].t0sz); diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h index 0987be2..9de55fc 100644 --- a/xen/include/asm-arm/p2m.h +++ b/xen/include/asm-arm/p2m.h @@ -30,7 +30,7 @@ struct p2m_domain { struct page_info *root; /* Current VMID in use */ -uint8_t vmid; +uint16_t vmid; /* Current Translation Table Base Register for the p2m */ uint64_t vttbr; diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h index 15bf890..48ce59b 100644 --- a/xen/include/asm-arm/processor.h +++ b/xen/include/asm-arm/processor.h @@ -215,6 +215,8 @@ #define VTCR_PS(x) ((x)<<16) +#define VTCR_VS(_AC(0x1,UL)<<19) + #endif #define VTCR_RES1 (_AC(1,UL)<<31) @@ -269,6 +271,11 @@ /* FSR long format */ #define FSRL_STATUS_DEBUG (_AC(0x22,UL)<<0) +#ifdef CONFIG_ARM_64 +#define MM64_VMID_8_BITS_SUPPORT0x0 +#define MM64_VMID_16_BITS_SUPPORT 0x2 +#endif + #ifndef __ASSEMBLY__ struct cpuinfo_arm { @@ -337,7 +344,16 @@ struct cpuinfo_arm { unsigned long tgranule_64K:4; unsigned long tgranule_4K:4; unsigned long __res
Re: [Xen-devel] [XEN VMID PATCH 2/2 v3] xen/arm: Add support for 16 bit VMIDs
Hi Julien,
On 13 December 2016 at 19:43, Julien Grall wrote:
> Hi Bhupinder,
>
> On 12/12/16 07:26, Bhupinder Thakur wrote:
>
> [...]
>
>> -void p2m_vmid_allocator_init(void)
>> +int p2m_vmid_allocator_init(void)
>> {
>> -set_bit(INVALID_VMID, vmid_mask);
>> +int ret = 0;
>> +
>> +/*
>> + * allocate space for vmid_mask based on MAX_VMID
>> + */
>> +vmid_mask = xzalloc_array(unsigned long, BITS_TO_LONGS(MAX_VMID));
>
>
> I would directly handle the panic within this function rather than return an
> error. I.e
>
> if ( !vmid_mask )
> panic();
>
> This would simplify the logic a bit.
>
ok. I will modify the code accordingly.
>> static int p2m_alloc_vmid(struct domain *d)
>> @@ -1632,20 +1653,36 @@ void __init setup_virt_paging(void)
>>
>> unsigned int cpu;
>> unsigned int pa_range = 0x10; /* Larger than any possible value */
>> +unsigned int vmid_8_bit_flag = 0;
>
>
> Please use bool:
>
> bool vmid_8_bit_flag = false;
>
> I would also drop _flag as it is not necessary.
ok. I will modify the code accordingly.
>
>>
>> for_each_online_cpu ( cpu )
>> {
>> const struct cpuinfo_arm *info = &cpu_data[cpu];
>> if ( info->mm64.pa_range < pa_range )
>> pa_range = info->mm64.pa_range;
>> +
>> +/* set a flag if the current cpu does not suppot 16 bit VMIDs */
>> +if ( info->mm64.vmid_bits != MM64_VMID_16_BITS_SUPPORT )
>> +vmid_8_bit_flag = 1;
>
>
> s/1/true/
>
ok
> The rest of the patch looks good to me.
>
> Cheers,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 103378: regressions - FAIL
flight 103378 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103378/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen ca01e5821245ff547fecdf091c29f45e5aba58cf baseline version: xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5 Last test of basis 103284 2016-12-13 19:03:56 Z1 days Failing since103292 2016-12-13 22:19:08 Z1 days 11 attempts Testing same since 103364 2016-12-14 22:02:45 Z0 days3 attempts People who touched revisions under test: Andrew Cooper Cédric Bosdonnat Ian Jackson Jan Beulich Juergen Gross Konrad Rzeszutek Wilk Ross Lagerwall Stefano Stabellini Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt 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 407 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Removal of redundant check
> On Dec 15, 2016, at 8:18 AM, Dario Faggioli wrote: > Oh, and I see that you are both inlining in the email and attaching the > patch. I personally don't particularly mind, but that may make the life > of a committer (the person which, when the patch will have all the > Acks, will put it inside the Xen git repository) a bit more difficult. > > So, this is mostly George's call, I think, but FWIW, I'd suggest you > avoid doing that. :-) git send-email is usually easier for everyone (both submitter and committer); but some people’s corporate setup doesn’t allow its use. Jan’s patches are always pasted in-line and attached, for instance. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current
On Wed, Dec 14, 2016 at 8:05 PM, Julien Grall wrote: >>> Note that ARM does not provide any hardware instruction to translate >>> an IPA (guest physical address) to a PA. So we have a walker there. >>> >>> We also a walk for debugging guest page table (though only when it is >>> using LPAE). I guess it could be re-used in the case where it is not >>> possible to do it in hardware. Although, it would be rewritten to make >>> it safe. >> >> >> This sounds like the kind of thing which would be generally useful, >> although I'd like to understand the problem better before making >> suggestions. > > > memaccess will restrict permission of certain memory regions in stage-2 page > table. For the purpose of the example, lets say read-access as been > restricted. > > One of these memory regions may contain the stage-1 page table. Do you agree > that the guest will not able to read stage-1 page table due the restriction? But only if the memory is read-protected, right? If a guest PT (stage-1) has read permission but not write permission, the hardware walker should still work, shouldn't it? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 103373: regressions - FAIL
flight 103373 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103373/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen ca01e5821245ff547fecdf091c29f45e5aba58cf baseline version: xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5 Last test of basis 103284 2016-12-13 19:03:56 Z1 days Failing since103292 2016-12-13 22:19:08 Z1 days 10 attempts Testing same since 103364 2016-12-14 22:02:45 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Cédric Bosdonnat Ian Jackson Jan Beulich Juergen Gross Konrad Rzeszutek Wilk Ross Lagerwall Stefano Stabellini Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt 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 407 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] SVM/VMX and Interrupt Shadows
On 12/13/2016 02:24 PM, Andrew Cooper wrote: Hello, All of this came about while reviewing some of Jans improvements to the x86 instruction emulator. It turns out that the XSA-156 / CVE-2015-8104 fix, c/s bd2239d9 "x86/HVM: always intercept #AC and #DB", introduced an awkward bug on Intel hardware. Executing a sti while singlestepping is active currently causes a VMEntry failure, because the #DB is still intercepted, but on re-entry, the sti interrupt shadow is still active and hardware complains about invalid guest state. Experimentally, on both Intel and AMD hardware, the mov_ss shadow inhibits #DB and the VMexit caused by its interception, whereas the sti shadow doesn't inhibit #DB. AMD's APM is very vague on this --- vol2 says in the STI's shadow *certain* debug traps are not recognized and doesn't say anything about MOV SS. And vol3 is silent about traps completely. I also found that that very old (family fh) processors had an erratum related to interrupt shadows but I assume you are running on something better than 2008 processor. I guess Suravee will have to clarify this one as well. -boris Therefore, my planned fix for VT-x is to unconditionally clobber the sti shadow if we intercept #DB. I am also looking to get the behaviour correct for all hardware, and from the instruction emulator. So my question to both AMD and Intel is how do the these shadow bits actually function in real hardware? I can't find any useful information in the manuals, other than rules about how to use the fields in the VMCS/VMCB. Additionally, Intel: vmx_set_info_guest() clobbers the sti shadow if a debugger is attached, citing a rule that eflags.TF may not be set alongside the sti shadow. I can't find any such rule in the list of vmentry checks, but then again I can't find a rule which I have actually violated with the above scenario. Have I missed anything obvious? AMD: Despite observably different behaviour, the VMCB only has a single bit for shadowing. Will the hardware mov_ss shadow always inhibit all #DB activity, including instruction breakpoints on the following instruction? If not, I can't see a way to safely fix this. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/arm: fix rank/vgic locks inversion bug
The locking order is: first rank lock, then vgic lock. The order is
respected everywhere, except for gic_update_one_lr.
gic_update_one_lr is called with the vgic lock held, but it calls
vgic_get_target_vcpu, which tries to obtain the rank lock. This can
cause deadlocks.
We already have a version of vgic_get_target_vcpu that doesn't take the
rank lock: __vgic_get_target_vcpu. Also the only routine that modify
the target vcpu are vgic_store_itargetsr and vgic_store_irouter. They
call vgic_migrate_irq, which already take the vgic lock.
Solve the lock inversion problem, by not taking the rank lock in
gic_update_one_lr (calling __vgic_get_target_vcpu instead of
vgic_get_target_vcpu). We make this safe, by placing modifications to
rank->vcpu within regions protected by the vgic lock.
Signed-off-by: Stefano Stabellini
---
There are supposed to be 2 Coverity IDs associated with this, but the
system the currently down.
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a5348f2..3483192 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -506,7 +506,7 @@ static void gic_update_one_lr(struct vcpu *v, int i)
list_del_init(&p->inflight);
if ( test_and_clear_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) )
{
-struct vcpu *v_target = vgic_get_target_vcpu(v, irq);
+struct vcpu *v_target = __vgic_get_target_vcpu(v, irq);
irq_set_affinity(p->desc, cpumask_of(v_target->processor));
}
}
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 3dbcfe8..666ebdb 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -95,6 +95,7 @@ static void vgic_store_itargetsr(struct domain *d, struct
vgic_irq_rank *rank,
{
unsigned int i;
unsigned int virq;
+unsigned long flags;
ASSERT(spin_is_locked(&rank->lock));
@@ -116,6 +117,7 @@ static void vgic_store_itargetsr(struct domain *d, struct
vgic_irq_rank *rank,
{
unsigned int new_target, old_target;
uint8_t new_mask;
+struct vcpu *old;
/*
* Don't need to mask as we rely on new_mask to fit for only one
@@ -153,16 +155,18 @@ static void vgic_store_itargetsr(struct domain *d, struct
vgic_irq_rank *rank,
new_target--;
old_target = rank->vcpu[offset];
+old = d->vcpu[old_target];
+spin_lock_irqsave(&old->arch.vgic.lock, flags);
/* Only migrate the vIRQ if the target vCPU has changed */
if ( new_target != old_target )
{
-vgic_migrate_irq(d->vcpu[old_target],
+vgic_migrate_irq(old,
d->vcpu[new_target],
virq);
}
-
rank->vcpu[offset] = new_target;
+spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
}
}
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index d61479d..880c643 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -122,6 +122,7 @@ static void vgic_store_irouter(struct domain *d, struct
vgic_irq_rank *rank,
{
struct vcpu *new_vcpu, *old_vcpu;
unsigned int virq;
+unsigned long flags;
/* There is 1 vIRQ per IROUTER */
virq = offset / NR_BYTES_PER_IROUTER;
@@ -150,11 +151,13 @@ static void vgic_store_irouter(struct domain *d, struct
vgic_irq_rank *rank,
if ( !new_vcpu )
return;
+spin_lock_irqsave(&old_vcpu->arch.vgic.lock, flags);
/* Only migrate the IRQ if the target vCPU has changed */
if ( new_vcpu != old_vcpu )
vgic_migrate_irq(old_vcpu, new_vcpu, virq);
rank->vcpu[offset] = new_vcpu->vcpu_id;
+spin_unlock_irqrestore(&old_vcpu->arch.vgic.lock, flags);
}
static inline bool vgic_reg64_check_access(struct hsr_dabt dabt)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 364d5f0..4f7971f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -219,7 +219,7 @@ int vcpu_vgic_free(struct vcpu *v)
}
/* The function should be called by rank lock taken. */
-static struct vcpu *__vgic_get_target_vcpu(struct vcpu *v, unsigned int virq)
+struct vcpu *__vgic_get_target_vcpu(struct vcpu *v, unsigned int virq)
{
struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
@@ -257,9 +257,11 @@ static int vgic_get_virq_priority(struct vcpu *v, unsigned
int virq)
void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
{
-unsigned long flags;
struct pending_irq *p = irq_to_pending(old, irq);
+ASSERT(spin_is_locked(&old->arch.vgic.lock));
+ASSERT(!local_irq_is_enabled());
+
/* nothing to do for virtual interrupts */
if ( p->desc == NULL )
return;
@@ -270,12 +272,9 @@ void vgic_migrate_irq(struct vcpu *old, struct vcpu *new,
unsigned int irq)
perfc_incr(vgic_irq_migrates);
-spin_lock_irqsave(&old->arch.vgic.lock, flags);
-
if ( list_empty(&p->inflight) )
{
irq_set_affinity(p->desc, c
[Xen-devel] [xen-unstable-smoke test] 103364: regressions - FAIL
flight 103364 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103364/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen ca01e5821245ff547fecdf091c29f45e5aba58cf baseline version: xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5 Last test of basis 103284 2016-12-13 19:03:56 Z1 days Failing since103292 2016-12-13 22:19:08 Z1 days9 attempts Testing same since 103364 2016-12-14 22:02:45 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Cédric Bosdonnat Ian Jackson Jan Beulich Juergen Gross Konrad Rzeszutek Wilk Ross Lagerwall Stefano Stabellini Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt 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 407 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Removal of redundant check
Hello! Glad to see he patch here. One thing, about the subject line: it should contains "tags", i.e., an indication of the component that the patch affects. So, for example, in this case, the patch touches Credit1, which means scheduling inside Xen. So, a valid subject line could be: [PATCH] xen: sched: removal of redundant check in Credit or: [PATCH] xen: credit: removal of redundant check On Wed, 2016-12-14 at 23:49 +0530, Praveen Kumar wrote: > The patch gets rid of a redundant check in csched_vcpu_acct which > adds > more code clarity and performance. > I'd remove "which adds more code clarity and performance" and put here something like: "In fact, the function is only called from csched_tick, which already checks that current is not the idle vcpu." > This patch also adds an ASSERT to > the same effect, in order to make assumption ( i.e., no calling this > on > idle vcpus) even more clear and as a guard for future mis-use. > > Signed-off-by: Praveen Kumar > Apart from what just said above, the patch looks good to me. Can you send version 2 with the changelog updated? Oh, and I see that you are both inlining in the email and attaching the patch. I personally don't particularly mind, but that may make the life of a committer (the person which, when the patch will have all the Acks, will put it inside the Xen git repository) a bit more difficult. So, this is mostly George's call, I think, but FWIW, I'd suggest you avoid doing that. :-) Thanks and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-pair
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-pair
testid xen-boot/dst_host
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Bug introduced: 9a9a2373142ac2c6fd9df9d038eb929b919e30d7
Bug not present: 1b15bd7396897e2f8018f863dd18006092a4deb0
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103366/
commit 9a9a2373142ac2c6fd9df9d038eb929b919e30d7
Author: Kashyap Desai
Date: Fri Oct 21 06:33:32 2016 -0700
scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices
[ Upstream commit 1e793f6fc0db920400574211c48f9157a37e3945 ]
Commit 02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.
[mkp: clarified patch description]
Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
Reviewed-by: Hannes Reinecke
Reviewed-by: Ewan D. Milne
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/test-amd64-i386-pair.xen-boot--dst_host.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/linux-4.1/test-amd64-i386-pair.xen-boot--dst_host
--summary-out=tmp/103370.bisection-summary --basis-template=101737
--blessings=real,real-bisect --flight=103370 linux-4.1 test-amd64-i386-pair
xen-boot/dst_host
Searching for failure / basis pass:
103264 fail [dst_host=nobling1,src_host=nobling0] / 101737
[dst_host=huxelrebe1,src_host=huxelrebe0] 101715
[dst_host=pinot1,src_host=pinot0] 101687 [dst_host=elbling0,src_host=elbling1]
101672 [dst_host=nocera1,src_host=nocera0] 101659
[dst_host=fiano1,src_host=fiano0] 101649 [dst_host=baroque1,src_host=baroque0]
101401 [dst_host=chardonnay1,src_host=chardonnay0] 101004
[dst_host=elbling0,src_host=elbling1] 101001
[dst_host=huxelrebe1,src_host=huxelrebe0] 100753
[dst_host=nocera1,src_host=nocera0] 100594
[dst_host=huxelrebe1,src_host=huxelrebe0] 100587
[dst_host=chardonnay0,src_host=chardonnay1] 100383
[dst_host=chardonnay1,src_host=chardonnay0] 100371
[dst_host=pinot0,src_host=pinot1] 99879 [dst_host=baroque1,src_host=baroque0]
99873 [dst_host=elbling1,src_host=elbling0] 99847
[dst_host=pinot1,src_host=pinot0] 99801 [dst_host=pinot1,src_host=pinot0] 99741
[dst_host=pinot1,src_host=pinot0] 99714 [dst_host=pinot1,src_host=pinot0] 99701
[dst_host=pinot1,src_host=pinot0] 99664 [dst_host=pinot1,src_host=pinot0] 97730
[dst_host=pinot1,src_host=pinot0] 97692 [dst_host=pinot1,src_host=pinot0] 97644
[dst_host=pinot1,src_host=pinot0] 97613 [dst_host=pinot1,src_host=pinot0] 97558
[dst_host=pinot1,src_host=pinot0] 97496 [dst_host=pinot1,src_host=pinot0] 97434
[dst_host=pinot1,src_host=pinot0] 97394 [dst_host=pinot1,src_host=pinot0] 97279
[dst_host=pinot1,src_host=pinot0] 96211 [dst_host=baroque1,src_host=baroque0]
96183 [dst_host=fiano1,src_host=fiano0] 96160 [dst_host=pinot0,src_host=pinot1]
95848 [dst_host=elbling0,src_host=elbling1] 95818
[dst_host=pinot1,src_host=pinot0] 95591
[dst_host=huxelrebe1,src_host=huxelrebe0] 95517
[dst_host=chardonnay0,src_host=chardonnay1] 95455
[dst_host=chardonnay1,src_host=chardonnay0] 95408
[dst_host=rimava0,src_host=rimava1] 94729 [dst_host=elbling1,src_host=elbling0]
94034 [dst_host=italia0,src_host=italia1] 93220
[dst_host=huxelrebe0,src_host=huxelrebe1] 93111
[dst_host=baroque1,src_host=baroque0] 92143
[dst_host=huxelrebe1,src_host=huxelrebe0] 91350
[dst_host=rimava0,src_host=rimava1] 91189 [dst_host=baroque1,src_host=baroque0]
91008 [dst_host=chardonnay0,src_host=chardonnay1] 90845
[dst_host=pinot0,src_host=pinot1] 89382 [dst_host=fiano0,src_host=fiano1] 89248
[dst_host=pinot1,src_host=pinot0] 88721 [dst_host=merlot1,src_host=merlot0]
88639 [dst_host=huxelrebe1,src_host=huxelrebe0] 88510
[dst_host=elbling0,src_host=elbling1] 88390
[dst_host=elbling1,src_host=elbling0] 88251 [dst_host=fiano1,src_host=fiano0]
88073 [dst_host=baroque0,s
[Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-pair
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-pair
testid xen-boot/src_host
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Bug introduced: 9a9a2373142ac2c6fd9df9d038eb929b919e30d7
Bug not present: 1b15bd7396897e2f8018f863dd18006092a4deb0
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103366/
commit 9a9a2373142ac2c6fd9df9d038eb929b919e30d7
Author: Kashyap Desai
Date: Fri Oct 21 06:33:32 2016 -0700
scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices
[ Upstream commit 1e793f6fc0db920400574211c48f9157a37e3945 ]
Commit 02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.
[mkp: clarified patch description]
Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
Reviewed-by: Hannes Reinecke
Reviewed-by: Ewan D. Milne
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/test-amd64-i386-pair.xen-boot--src_host.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/linux-4.1/test-amd64-i386-pair.xen-boot--src_host
--summary-out=tmp/103366.bisection-summary --basis-template=101737
--blessings=real,real-bisect linux-4.1 test-amd64-i386-pair xen-boot/src_host
Searching for failure / basis pass:
103264 fail [dst_host=nobling1,src_host=nobling0] / 101737
[dst_host=huxelrebe1,src_host=huxelrebe0] 101715
[dst_host=pinot1,src_host=pinot0] 101687 [dst_host=elbling0,src_host=elbling1]
101672 [dst_host=nocera1,src_host=nocera0] 101659
[dst_host=fiano1,src_host=fiano0] 101649 [dst_host=baroque1,src_host=baroque0]
101401 [dst_host=chardonnay1,src_host=chardonnay0] 101004
[dst_host=elbling0,src_host=elbling1] 101001
[dst_host=huxelrebe1,src_host=huxelrebe0] 100753
[dst_host=nocera1,src_host=nocera0] 100594
[dst_host=huxelrebe1,src_host=huxelrebe0] 100587
[dst_host=chardonnay0,src_host=chardonnay1] 100383
[dst_host=chardonnay1,src_host=chardonnay0] 100371
[dst_host=pinot0,src_host=pinot1] 99879 [dst_host=baroque1,src_host=baroque0]
99873 [dst_host=elbling1,src_host=elbling0] 99847
[dst_host=pinot1,src_host=pinot0] 99801 [dst_host=pinot1,src_host=pinot0] 99741
[dst_host=pinot1,src_host=pinot0] 99714 [dst_host=pinot1,src_host=pinot0] 99701
[dst_host=pinot1,src_host=pinot0] 99664 [dst_host=pinot1,src_host=pinot0] 97730
[dst_host=pinot1,src_host=pinot0] 97692 [dst_host=pinot1,src_host=pinot0] 97644
[dst_host=pinot1,src_host=pinot0] 97613 [dst_host=pinot1,src_host=pinot0] 97558
[dst_host=pinot1,src_host=pinot0] 97496 [dst_host=pinot1,src_host=pinot0] 97434
[dst_host=pinot1,src_host=pinot0] 97394 [dst_host=pinot1,src_host=pinot0] 97279
[dst_host=pinot1,src_host=pinot0] 96211 [dst_host=baroque1,src_host=baroque0]
96183 [dst_host=fiano1,src_host=fiano0] 96160 [dst_host=pinot0,src_host=pinot1]
95848 [dst_host=elbling0,src_host=elbling1] 95818
[dst_host=pinot1,src_host=pinot0] 95591
[dst_host=huxelrebe1,src_host=huxelrebe0] 95517
[dst_host=chardonnay0,src_host=chardonnay1] 95455
[dst_host=chardonnay1,src_host=chardonnay0] 95408
[dst_host=rimava0,src_host=rimava1] 94729 [dst_host=elbling1,src_host=elbling0]
94034 [dst_host=italia0,src_host=italia1] 93220
[dst_host=huxelrebe0,src_host=huxelrebe1] 93111
[dst_host=baroque1,src_host=baroque0] 92143
[dst_host=huxelrebe1,src_host=huxelrebe0] 91350
[dst_host=rimava0,src_host=rimava1] 91189 [dst_host=baroque1,src_host=baroque0]
91008 [dst_host=chardonnay0,src_host=chardonnay1] 90845
[dst_host=pinot0,src_host=pinot1] 89382 [dst_host=fiano0,src_host=fiano1] 89248
[dst_host=pinot1,src_host=pinot0] 88721 [dst_host=merlot1,src_host=merlot0]
88639 [dst_host=huxelrebe1,src_host=huxelrebe0] 88510
[dst_host=elbling0,src_host=elbling1] 88390
[dst_host=elbling1,src_host=elbling0] 88251 [dst_host=fiano1,src_host=fiano0]
88073 [dst_host=baroque0,src_host=baroque1]
Re: [Xen-devel] [PATCH] MAINTAINERS: Add myself as the public API "Czar"
Hey Konrad, it looks like you forgot about this. Cheers, Stefano On Fri, 18 Nov 2016, Konrad Rzeszutek Wilk wrote: > That way we have one person who can: a) poke other maintainers > or pull them in with new drivers are introduced, b) we have > one maintainer who can shepherd the patches along instead of > depending on the REST maintainers which may be busy with > other responsibilities. > > Signed-off-by: Konrad Rzeszutek Wilk > --- > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Stefano Stabellini > Cc: Tim Deegan > Cc: Wei Liu > --- > MAINTAINERS | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index f0d0202..492f197 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -304,6 +304,11 @@ X: xen/arch/x86/acpi/lib.c > F: xen/drivers/cpufreq/ > F: xen/include/acpi/cpufreq/ > > +PUBLIC INTERFACES > +M: Konrad Rzeszutek Wilk > +S: Supported > +F: xen/include/public/ > + > QEMU-DM > M: Ian Jackson > S: Supported > -- > 2.9.3 > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 68221: all pass
This run is configured for baseline tests only. flight 68221 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68221/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf dc756baeda55490202f3150a8821b5164e906451 baseline version: ovmf 94a1bc1212edf521b7c96bfb9dc653818c95bec7 Last test of basis68217 2016-12-13 23:21:14 Z0 days Testing same since68221 2016-12-14 16:19:37 Z0 days1 attempts People who touched revisions under test: Hao Wu Jiewen Yao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit dc756baeda55490202f3150a8821b5164e906451 Author: Jiewen Yao Date: Mon Dec 12 14:35:05 2016 +0800 SecurityPkg:/Tcg2Dxe: remove 4G limitation Tcg2Dxe allocates event log below 4G. It is unnecessary. Cc: Chao Zhang Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao Reviewed-by: Star Zeng Reviewed-by: Chao Zhang commit 82bf462e3a473fdce2475fac96c225bc62658b18 Author: Hao Wu Date: Mon Dec 12 09:07:52 2016 +0800 MdeModulePkg/NonDiscoverablePciDev: Fix type mismatch in switch/case Fix switch/case statement type mismatch in functions PciIoMemRead & PciIoMemWrite. Parameter 'Width' is of enum type EFI_PCI_IO_PROTOCOL_WIDTH, but the enum type provided in 'switch (Width)' block is of type EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_WIDTH. Cc: Ard Biesheuvel Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu Reviewed-by: Ruiyu Ni commit 2961c65425df42e31554bdeb3f6af0451580f047 Author: Jiewen Yao Date: Sat Dec 10 15:08:16 2016 +0800 MdeModulePkg/CapsuleLib: Correct debug message. Cc: Feng Tian Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao Reviewed-by: Star Zeng ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.4-testing test] 103311: regressions - FAIL
flight 103311 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103311/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 102521 test-xtf-amd64-amd64-3 31 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 102521 test-xtf-amd64-amd64-3 42 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 102521 test-xtf-amd64-amd64-5 52 leak-check/check fail REGR. vs. 102521 test-xtf-amd64-amd64-4 52 leak-check/check fail REGR. vs. 102521 test-xtf-amd64-amd64-3 52 leak-check/check fail REGR. vs. 102521 test-xtf-amd64-amd64-2 52 leak-check/check fail REGR. vs. 102521 test-xtf-amd64-amd64-1 52 leak-check/check fail REGR. vs. 102521 test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail REGR. vs. 102521 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 102521 test-amd64-i386-xend-qemut-winxpsp3 9 windows-install fail REGR. vs. 102521 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 102521 Regressions which are regarded as allowable (not blocking): test-xtf-amd64-amd64-4 16 xtf/test-pv32pae-selftestfail like 102521 test-xtf-amd64-amd64-2 16 xtf/test-pv32pae-selftestfail like 102521 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102521 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102521 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102521 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 10 xtf-fep fail never pass build-amd64-rumprun 7 xen-buildfail never pass test-xtf-amd64-amd64-1 16 xtf/test-pv32pae-selftestfail never pass test-xtf-amd64-amd64-4 10 xtf-fep fail never pass test-xtf-amd64-amd64-1 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 18 xtf/test-hvm32-cpuid-faulting fail never pass build-i386-rumprun7 xen-buildfail never pass test-xtf-amd64-amd64-4 29 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 10 xtf-fep fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-4 35 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 29 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 39 xtf/test-hvm64-cpuid-faulting fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-xtf-amd64-amd64-1 35 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-3 10 xtf-fep fail 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 9 debian-di-installfail never pass test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass test-xtf-amd64-amd64-1 39 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 10 xtf-fep fail never pass test-xtf-amd64-amd64-2 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 29 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 35 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 39 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 51 xtf/test-hvm64-xsa-195 fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-4 51 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-3 51 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-2 51 xtf/test-hvm64-xsa-195 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-1 51 xtf/test-hvm64-xsa-195 fail never pass test-armhf-armhf-xl-cubietruck 12 m
[Xen-devel] [xen-unstable-smoke test] 103356: regressions - FAIL
flight 103356 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103356/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen 7b9f21cabc14d823d888ff00413e49b41ca430fe baseline version: xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5 Last test of basis 103284 2016-12-13 19:03:56 Z1 days Failing since103292 2016-12-13 22:19:08 Z0 days8 attempts Testing same since 103356 2016-12-14 19:02:39 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Cédric Bosdonnat Ian Jackson Jan Beulich Juergen Gross Ross Lagerwall Stefano Stabellini Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 7b9f21cabc14d823d888ff00413e49b41ca430fe Author: Andrew Cooper Date: Wed Dec 14 11:33:17 2016 + x86/traps: Correct pagefault handling issues introduced in c/s d5c251c There are two bugs. Firstly, the ASSERT(paging_mode_only_log_dirty(d)) can trip when servicing a hypervisor #PF in the context of an HVM guest, e.g. a copy_to_user() failure in the shadow pagetable code. Secondly, the entry conditions paging_fault() were previously guarded on !paging_mode_external(d) which limited entry to PV contexts, but for both guest and hypervisor faults. Switching this to paging_mode_log_dirty() opened it up to HVM contexts as well. Reinstate the old !paging_mode_external(d) check, as it is actually the relevent fact, and extend the comment to explicitly state that hypervisor faults should follow this path. Inside, we are now guarenteed to be in the context of a PV guest, so can safely use the assertion about log dirty. Signed-off-by: Andrew Cooper Reviewed-by: Tim Deegan commit 6a6bbedd39e39f6c45001ce468c5e53a3a2b3ba6 Author: Ross Lagerwall Date: Wed Dec 14 11:12:01 2016 + x86: Use ACPI reboot method for Dell OptiPlex 9020 When EFI booting the Dell OptiPlex 9020, it sometimes GP faults in the EFI runtime instead of rebooting. Quirk this hardware to use the ACPI reboot method instead. dmidecode info: BIOS Information Vendor: Dell Inc. Version: A15 Release Date: 11/08/2015 System Information Manufacturer: Dell Inc. Product Name: OptiPlex 9020 Version: 00 Signed-off-by: Ross Lagerwall Reviewed-by: Andrew Cooper commit 47591e012f08f95858d444641e773f101ba41e21 Author: Andrew Cooper Date: Wed Dec 14 10:58:08 2016 + x86/emul: Further simplify DstBitBase handling The masking of src.val is common to both paths. Move it later and simplify the entry condition for adjusting the memory operand. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich commit 713b23ccd1e6c9188b9beb52494e4a4196329056 Author: Wei Liu Date: Wed Dec 14 14:44:33 2016 + Config.mk: update mini-os changeset Signed-off-by: Wei Liu commit 0738d6fe7116cc2398bcb557c957ab38b712fe96 Author: Juergen Gross Date: Tue Dec 13 16:38:06 2016 +0100 stubdom: modify ioemu linkfarm only if necessary Several stubdom libraries are being rebuilt each time a top level make is called as they depend on stubdom/ioemu/linkfarm.stamp which is depending on tools/qemu-xen-traditional-dir. Unfortunately this directory is modified by eac
Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one
On Wed, Dec 14, 2016 at 03:59:00PM +0100, Dario Faggioli wrote: > On Tue, 2016-12-13 at 19:00 +, Julien Grall wrote: > > Hi all, > > > > Stefano suggested to move the call at 5pm and I haven't seen any > > disagreement. > > > > So the call will be tomorrow (Wednesday 14th December at 5pm). Hi all, Thanks for the call today. I'm sending a link to EEMI the power management framework that Xilinx co-developed with Aggios. I don't have a link to the ARM specs for SCMI. I found some slides though. Perhaps Julien has specs? SCMI: http://www.slideshare.net/linaroorg/las16200-scmi-system-management-and-control-interface EEMI: https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf Roughly, EEMI works top down by having the various SW layers request power down/up and other settings to the layer beneath. The various layers are responsible for recounting so that we don't shut down something that is in use and also to isolate so that we don't turn on or off anything that we don't own. At the moment we tunnel API calls via SMC calls to EL3. For calls that ATF at EL3 can implement it answers directly. If not, these calls further propagate over a shared memory / IPI interface to a dedicated tiny core (PMU) with power management firmware. The PMU is responsible for mediating power/clock request changes and making sure that the requesters don't mess with devices or settings that don't belong to them. So top down the idea is: EL0 User-space uses devices (open/close or whatever). EL1 OS/Kernel refcounts per process and requests power down/up of devs when not used. EL2 Hypervisor (or dom0 or something not yet implemented) refcounts per guest and forwards the request down the chain if appropriate. EL3 Trusted Firmware mediates between Normal and Secure world. PMU Mediates between different CPU clusters and Programmable logic. Best regards, Edgar ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]
On Wed, Dec 14, 2016 at 11:12 AM, Ian Jackson wrote:
> Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db:
> Retry on constraint violation [and 2 more messages] [and 1 more messages]"):
>> On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson
>> wrote:
>> I would alter that slightly to:
>>
>> There is a consistent serialization of all serializable
>> transactions which successfully commit.
>
> Here `serializable' means SERIALIZABLE ?
I'm not entirely sure what you mean to convey by the
capitalization, so I'll just say that 'serializable' there referred
to the transaction isolation level. (I *think* that was what you
were getting at.)
>> For examples, please see this Wiki page. You might be particularly
>> interested in the examples in the "Read Only Transactions" section:
>>
>> https://wiki.postgresql.org/wiki/SSI
>
> Thanks. I read that part of the wiki page. But in that example, we
> are told that T1 will be aborted, not T3.
That is true in the first "Deposit Report") example in that
section. The second ("Rollover") example shows the read-only
transaction (T3) being the one which is aborted and retried.
> Can it happen that a transaction which does not make any update
> attempts, will see "impossible" data, and that this is only detected
> at COMMIT ? Does that apply even to READ ONLY transactions ?
As Robert pointed out, a read-only transaction cannot normally be
aborted by a serialization failure on COMMIT. Under exceptional
conditions, like an attempt to suppress the serialization failure,
you might see the commit aborted, though.
Also as pointed out by Robert, the state seen by a read-only
transaction doesn't lack internal consistency, but it will be
rolled back with a serialization failure exception if it can show a
state which is inconsistent with some successfully-committed state
of the database.
In the "Rollover" example, the first time T3 is attempted its
SELECT it would have shown rows containing 100 and 11, were it not
canceled. That could have been consistent with the earlier state
of 100 and 10 and the business rules that the first number can only
change by having the second number added to it, and the second
number can only change by being incremented; but that state and
those rules don't fit with the *later* state of 110, 11, because
that requires that the second number be added to the first before
it was incremented, and if we allow the result of the first T3
transaction attempt to be seen, it would tell us that the increment
happened first. Since we've already allowed successful commit of
transactions putting things into a state only consistent with
adding 10 to 100 before incrementing 10 to 11, cancel the read-only
transaction and start over. This time it will show something
consistent with the apparent order of execution of the other
transactions.
Note that neither the order that the first two transaction started
in (T1->T2) nor the order they committed in (T2->T1) determines the
apparent order of execution. It is the rw-dependencies that
control (T1 reads a version of data before T2's work is applied, so
T1 *appears* to have run before T2 in apparent order of execution.)
Since both are successfully committed with that apparent order of
execution, a third transaction (T3), which sees the work of T2
(since it had committed when the snapshot for T3 was taken) but not
T1 (since it had not committed when the snapshot for T3 was taken)
cannot be allowed to proceed.
I know an example like that can cause one's head to hurt a bit
(been there), but even if you don't fight your way to a full grasp
of that case, it will hopefully give you some idea of both why we
can have high concurrency with this approach, and why it is
necessary to discard results from failed transactions.
>> Once a serialization failure occurs the transaction is flagged as
>> "doomed" and will not, under any circumstances be allowed to
>> commit. If you find any exception to that, please report it as a
>> bug.
>
> Right. I think this prevents any exception-catching arrangements from
> suppressing the serialisation failure. Since AIUI it is not possible
> to run the outer COMMIT from within an exception trapping context.
Right.
> If it /is/ possible to run that outer COMMIT in a way which swallows
> the exception then [...]
That is not possible, as I understand things.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.
On 12/12/2016 09:00 AM, Anshul Makkar wrote:
During guest migrate allow permission to prevent
spurious page faults.
Prevents these errors:
d73: Non-privileged (73) attempt to map I/O space
avc: denied { set_misc_info } for domid=0 target=11
scontext=system_u:system_r:dom0_t
tcontext=system_u:system_r:domU_t tclass=domain
GPU passthrough for hvm guest:
avc: denied { send_irq } for domid=0 target=10
scontext=system_u:system_r:dom0_t
tcontext=system_u:system_r:domU_t tclass=hvm
Signed-off-by: Anshul Makkar
Acked-by: Daniel De Graaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 07/11] docs: move vtpm from misc to man
On 12/09/2016 11:17 AM, Cédric Bosdonnat wrote: vtpm.txt is referenced in xl.cfg man page. Convert it to pod, move it to the man folder and update the reference. Signed-off-by: Cédric Bosdonnat Since this manpage only describes Xen's vTPM implementation, and Xen is not the only vTPM that exists in Linux (there's a Linux kernel "vtpm_proxy" interface and another ibmvtpm module), I think it needs be named something like "xen-vtpm". The same applies to patch 8 (vtpmmgr) as that manpage (and software) is Xen-specific. The POD sources look correct, though I have not compiled & looked at the resulting manpages. -- Daniel De Graaf National Security Agency ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/8] xen-livepatch misc fixes/changes
On Wed, Dec 14, 2016 at 01:16:00PM -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Dec 14, 2016 at 07:51:52AM +, Ross Lagerwall wrote: > > Hi all, > > > > This series contains a few fixes to the xen-livepatch tool. > > It also contains a few changes to make the output more readable. > > Hey Ross, > > I've applied and reviewed some of the patches. Testing them right now > and if theere are no issues will push to staging shortly. Completed. Patches pushed in staging. Thank you again! ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] Removal of redundant check
The patch gets rid of a redundant check in csched_vcpu_acct which adds more code clarity and performance. This patch also adds an ASSERT to the same effect, in order to make assumption ( i.e., no calling this on idle vcpus) even more clear and as a guard for future mis-use. Signed-off-by: Praveen Kumar diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c index fc3a321..dfe8545 100644 --- a/xen/common/sched_credit.c +++ b/xen/common/sched_credit.c @@ -941,6 +941,7 @@ csched_vcpu_acct(struct csched_private *prv, unsigned int cpu) ASSERT( current->processor == cpu ); ASSERT( svc->sdom != NULL ); +ASSERT( !is_idle_vcpu(svc->vcpu) ); /* * If this VCPU's priority was boosted when it last awoke, reset it. @@ -957,8 +958,7 @@ csched_vcpu_acct(struct csched_private *prv, unsigned int cpu) /* * Update credits */ -if ( !is_idle_vcpu(svc->vcpu) ) -burn_credits(svc, NOW()); +burn_credits(svc, NOW()); /* * Put this VCPU and domain back on the active list if it wasThe patch gets rid of a redundant check in csched_vcpu_acct which adds more code clarity and performance. This patch also adds an ASSERT to the same effect, in order to make assumption ( i.e., no calling this on idle vcpus) even more clear and as a guard for future mis-use. Signed-off-by: Praveen Kumar diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c index fc3a321..dfe8545 100644 --- a/xen/common/sched_credit.c +++ b/xen/common/sched_credit.c @@ -941,6 +941,7 @@ csched_vcpu_acct(struct csched_private *prv, unsigned int cpu) ASSERT( current->processor == cpu ); ASSERT( svc->sdom != NULL ); +ASSERT( !is_idle_vcpu(svc->vcpu) ); /* * If this VCPU's priority was boosted when it last awoke, reset it. @@ -957,8 +958,7 @@ csched_vcpu_acct(struct csched_private *prv, unsigned int cpu) /* * Update credits */ -if ( !is_idle_vcpu(svc->vcpu) ) -burn_credits(svc, NOW()); +burn_credits(svc, NOW()); /* * Put this VCPU and domain back on the active list if it was ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 103342: regressions - FAIL
flight 103342 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103342/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 96a7cb37b921d2b320183d194d143262e1dd5b53
baseline version:
xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5
Last test of basis 103284 2016-12-13 19:03:56 Z0 days
Failing since103292 2016-12-13 22:19:08 Z0 days7 attempts
Testing same since 103336 2016-12-14 13:01:52 Z0 days2 attempts
People who touched revisions under test:
Cédric Bosdonnat
Ian Jackson
Jan Beulich
Stefano Stabellini
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt fail
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 96a7cb37b921d2b320183d194d143262e1dd5b53
Author: Jan Beulich
Date: Wed Dec 14 10:11:08 2016 +0100
x86emul: MOVNTI does not allow REP prefixes
Just like 66, prefixes F3 and F2 cause #UD.
Also adjust a related comment, which in its previous wording was
misleading (as in 16-bit mode there would nothing be undone when
adjusting operand size from 2 to 4).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit bd201eb1681ce6eb1b2d53b4d26a27081956770f
Author: Jan Beulich
Date: Wed Dec 14 10:10:39 2016 +0100
x86emul: check for LAHF_LM availability
We can't exclude someone wanting to hide LAHF/SAHF from 64-bit guests.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit 4133077d06a14d041d68250e67eac4d7bcbabfcf
Author: Jan Beulich
Date: Wed Dec 14 10:10:11 2016 +0100
x86emul: check for CLFLUSH{,OPT} availability
We can't exclude someone wanting to hide either of the instructions
from guests.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit d95533f554cde498b9afe731b94a4d9198b47cbe
Author: Jan Beulich
Date: Wed Dec 14 10:09:40 2016 +0100
x86emul: check for SYSENTER/SYSEXIT availability
We can't exclude someone wanting to hide the instructions from guests.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit 54abe826c8297e12f805be2bcf318ef75cc7f58d
Author: Jan Beulich
Date: Wed Dec 14 10:08:22 2016 +0100
x86emul: CMPXCHG{8,16}B ignore prefixes
This removes 0F C7 from the list of two-byte opcodes treating prefixes
66, F3, and F2 as opcode extensions. We better manually handle this in
the opcode specific code:
- CMPXCHG8B ignores all these prefixes (its handling is being adjusted
accordingly, with a respective test case added as well, to avoid
re-introducing the subject of XSA-200),
- RDRAND/RDSEED (support to be added subsequently) honor 66, but treat
F3 and F2 as opcode extensions (resolving to RDPID in the RDSEED
case, which in turn ignores 66).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit 6cf995f1f59240532e27cb788a390185f4276d6f
Author: Jan Beulich
Date: Wed Dec 14 09:54:35 2016 +0100
x86/PV: prefer pv_inject_hw_exception()
... over editing the error code and calling do_guest_trap().
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit 4999bf3e8b4ced3fbdc4f64443a7fdab638322bb
Author: Jan Beulich
Date: Wed Dec 14 09:54:03 2016 +0100
x86/PV: use generic emulator for privileged instruction handling
There's a new emulator return code being added to allow bypassing
certain operations (see the code
Re: [Xen-devel] [PATCH v2 0/8] xen-livepatch misc fixes/changes
On Wed, Dec 14, 2016 at 07:51:52AM +, Ross Lagerwall wrote: > Hi all, > > This series contains a few fixes to the xen-livepatch tool. > It also contains a few changes to make the output more readable. Hey Ross, I've applied and reviewed some of the patches. Testing them right now and if theere are no issues will push to staging shortly. Thank you for the fixes! > > Changed in v2: > * Fix minor comments. > * Split the last patch into two. > > Ross Lagerwall (8): > tools/livepatch: Show the correct expected state before action > tools/livepatch: Set stdout and stderr unbuffered > tools/livepatch: Improve output > livepatch: Fix documentation of timeout > tools/livepatch: Remove pointless retry loop > tools/livepatch: Remove unused struct member > tools/livepatch: Save errno where needed > tools/livepatch: Exit with 2 if a timeout occurs > > docs/misc/livepatch.markdown | 13 +-- > tools/libxc/include/xenctrl.h | 2 +- > tools/misc/xen-livepatch.c| 218 > ++ > xen/common/livepatch.c| 4 +- > xen/include/public/sysctl.h | 5 +- > 5 files changed, 151 insertions(+), 91 deletions(-) > > -- > 2.7.4 > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [RFC] netif: staging grants for requests
Hey, Back in the Xen hackaton '16 networking session there were a couple of ideas brought up. One of them was about exploring permanently mapped grants between xen-netback/xen-netfront. I started experimenting and came up with sort of a design document (in pandoc) on what it would like to be proposed. This is meant as a seed for discussion and also requesting input to know if this is a good direction. Of course, I am willing to try alternatives that we come up beyond the contents of the spec, or any other suggested changes ;) Any comments or feedback is welcome! Cheers, Joao --- % Staging grants for network I/O requests % Joao Martins <> % Revision 1 \clearpage Status: **Experimental** Architecture(s): x86 and ARM Component(s): Guest Hardware: Intel and AMD # Background and Motivation At the Xen hackaton '16 networking session, we spoke about having a permanently mapped region to describe header/linear region of packet buffers. This document outlines the proposal covering motivation of this and applicability for other use-cases alongside the necessary changes. This proposal is an RFC and also includes alternative solutions. The motivation of this work is to eliminate grant ops for packet I/O intensive workloads such as those observed with smaller requests size (i.e. <= 256 bytes or <= MTU). Currently on Xen, only bulk transfer (e.g. 32K..64K packets) are the only ones performing really good (up to 80 Gbit/s in few CPUs), usually backing end-hosts and server appliances. Anything that involves higher packet rates (<= 1500 MTU) or without sg, performs badly almost like a 1 Gbit/s throughput. # Proposal The proposal is to leverage the already implicit copy from and to packet linear data on netfront and netback, to be done instead from a permanently mapped region. In some (physical) NICs this is known as header/data split. Specifically some workloads (e.g. NFV) it would provide a big increase in throughput when we switch to (zero)copying in the backend/frontend, instead of the grant hypercalls. Thus this extension aims at futureproofing the netif protocol by adding the possibility of guests setting up a list of grants that are set up at device creation and revoked at device freeing - without taking too much grant entries in account for the general case (i.e. to cover only the header region <= 256 bytes, 16 grants per ring) while configurable by kernel when one wants to resort to a copy-based as opposed to grant copy/map. \clearpage # General Operation Here we describe how netback and netfront general operate, and where the proposed solution will fit. The security mechanism currently involves grants references which in essence are round-robin recycled 'tickets' stamped with the GPFNs, permission attributes, and the authorized domain: (This is an in-memory view of struct grant_entry_v1): 0 1 2 3 4 5 6 7 octet ++---++ | flags | domain id | frame | ++---++ Where there are N grant entries in a grant table, for example: @0: ++---++ | rw | 0 | 0xABCDEF | ++---++ | rw | 0 | 0xFA124| ++---++ | ro | 1 | 0xBEEF | ++---++ . @N: ++---++ | rw | 0 | 0x9923A| ++---++ Each entry consumes 8 bytes, therefore 512 entries can fit on one page. The `gnttab_max_frames` which is a default of 32 pages. Hence 16,384 grants. The ParaVirtualized (PV) drivers will use the grant reference (index in the grant table - 0 .. N) in their command ring. \clearpage ## Guest Transmit The view of the shared transmit ring is the following: 0 1 2 3 4 5 6 7 octet +++ | req_prod | req_event | +++ | rsp_prod | rsp_event | +++ | pvt| pad[44]| ++| | | [64bytes] +++-\ | gref | offset| flags | | ++---++ +-'struct | id | size | id| status | | netif_tx_sring_ent
[Xen-devel] [linux-4.1 test] 103264: regressions - trouble: broken/fail/pass
flight 103264 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103264/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101737 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101737 test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-pvh-intel 6 xen-bootfail REGR. vs. 101737 test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101737 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 101737 build-armhf-pvops 5 kernel-build fail in 102733 REGR. vs. 101737 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 103011 pass in 103264 test-amd64-i386-xl 3 host-install(3) broken in 103011 pass in 103264 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 103011 pass in 103264 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 103011 pass in 103264 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 103011 pass in 103264 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 103011 pass in 103264 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 102733 pass in 102886 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeat fail in 102755 pass in 103089 test-armhf-armhf-libvirt-xsm 14 guest-stop fail in 102755 pass in 103264 test-amd64-i386-xl-xsm6 xen-boot fail in 102886 pass in 103264 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail in 102886 pass in 103264 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 102886 pass in 103264 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 103011 pass in 103264 test-armhf-armhf-libvirt-xsm 11 guest-start fail in 103011 pass in 103264 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 103089 pass in 103264 test-armhf-armhf-libvirt 11 guest-start fail in 103165 pass in 103264 test-amd64-amd64-libvirt 6 xen-boot fail pass in 102733 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail pass in 102733 test-amd64-i386-xl-raw6 xen-boot fail pass in 102733 test-amd64-i386-libvirt-xsm 6 xen-boot fail pass in 102755 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot fail pass in 102755 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail pass in 102829 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 102886 test-amd64-amd64-libvirt-vhd 6 xen-boot fail pass in 102886 test-amd64-i386-freebsd10-i386 6 xen-boot fail pass in 103011 test-amd64-amd64-xl-xsm 6 xen-boot fail pass in 103089 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 103089 test-amd64-amd64-xl-rtds 6 xen-boot fail pass in 103089 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail pass in 103089 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 103089 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 103165 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 103165 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail pass in 103165 test-armhf-armhf-xl-cubietruck 8 leak-check/basis(8) fail pass in 103165 test-amd64-amd64-i386-pvgrub 10 guest-startfail pass in 103165 test-amd64-amd64-libvirt-xsm 6 xen-boot fail pass in 103165 test-amd64-i386-libvirt 17 guest-start/debian.repeat fail pass in 103165 test-armhf-armhf-xl-multivcpu 11 guest-start fail pass in 103165 test-amd64-amd64-amd64-pvgrub 18 guest-start/debian.repeat fail pass in 103165 Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail blocked in 101737 test-amd64-amd64-rumprun-amd64 17 leak-check/check fail blocked in 101737 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 102755 like 101715 test-armhf-armhf-xl-credit2 11 guest-start fail in 102829 like 101737 test-armhf-armhf-xl-xsm 11 guest-start fail in 102829 like 10
[Xen-devel] [xen-4.7-testing test] 103270: regressions - FAIL
flight 103270 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103270/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 103163 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 103163 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103163 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 103163 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 103163 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103163 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103163 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103163 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail 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-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 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-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail 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-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 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-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass version targeted for testing: xen 7a71cea02afe2bf0f04f1cbf91931081dbe9dd76 baseline version: xen 4be57d3e41f22387c1bc6b4d4332f857eeea84b8 Last test of basis 103163 2016-12-11 20:46:19 Z2 days Testing same since 103270 2016-12-13 14:17:36 Z1 days1 attempts People who touched revisions under test: Jan Beulich Juergen Gross Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rum
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]
On Wed, Dec 14, 2016 at 11:20 AM, Ian Jackson wrote: >> I'm not sure Ian is intentionally taking that position. Not all of us >> are as familiar with the ramifications of every serializability >> behavior we may want as you are. > > Indeed. I think it's fair to say that I'm totally unfamiliar with the > ramifications. You might also fairly characterise me as naive; I had > certainly made some assumptions which it seems are known (around here) > to be both false and difficult to make true. We can't all be database gurus... > Let me try to summarise my understanding of what the developers think > they can and intend to promise, about SERIALIZABLE transactions: > > There is a consistent serialisation of all transactions which > successfully commit; or which do not attempt to make any changes. I think we've figured out that it is limited to transactions which successfully commit plus read-only transactions that roll back at the top level but never roll back a subtransaction. And I'm not sure there aren't other exceptions. Basically, be very wary about relying on information extracted from a transaction that rolled back: there might be dragons there. > A "consistent serialisation" means that there is an order in which > the same transactions might have been executed giving exactly the > answers. This includes, if applicable, the same errors. (The > database is free to generate synchronisation failure errors 40P01 and > 40001 whenever it chooses.) Seems right. > A transaction which attempts to make any changes, and which does not > commit (whether because the application never asks for COMMIT, or > because of reported synchronisation failure) might see internally > inconsistent data, or an internally-consistent view which is not > compatible with any serialisation of other transactions. An > application which needs a coherent view should not rely on any of the > information from such a transaction. I think it will see an internally-consistent view which is not compatible with any global serial ordering. I don't see why it would see an internally-inconsistent view; inconsistent how? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages] [and 1 more messages]"):
> On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson
> wrote:
>
> > Let me try to summarise my understanding of what the developers think
> > they can and intend to promise, about SERIALIZABLE transactions:
> >
> > There is a consistent serialisation of all transactions which
> > successfully commit; or which do not attempt to make any changes.
> >
> > A "consistent serialisation" means that there is an order in which
> > the same transactions might have been executed giving exactly the
> > answers. This includes, if applicable, the same errors. (The
> > database is free to generate synchronisation failure errors 40P01 and
> > 40001 whenever it chooses.)
>
> I would alter that slightly to:
>
> There is a consistent serialization of all serializable
> transactions which successfully commit.
Here `serializable' means SERIALIZABLE ?
> > A transaction which attempts to make any changes, and which does not
> > commit (whether because the application never asks for COMMIT, or
> > because of reported synchronisation failure) might see internally
> > inconsistent data, or an internally-consistent view which is not
> > compatible with any serialisation of other transactions. An
> > application which needs a coherent view should not rely on any of the
> > information from such a transaction.
>
> Even a read-only transaction can see a state that is not consistent
> with business rules (as enforced in the software) given that some
> particular later state is reached.
>
> For examples, please see this Wiki page. You might be particularly
> interested in the examples in the "Read Only Transactions" section:
>
> https://wiki.postgresql.org/wiki/SSI
Thanks. I read that part of the wiki page. But in that example, we
are told that T1 will be aborted, not T3.
Can it happen that a transaction which does not make any update
attempts, will see "impossible" data, and that this is only detected
at COMMIT ? Does that apply even to READ ONLY transactions ?
> > Serialisation failures in subtransactions might cause the parent
> > transaction to experience a serialisation failure too.
>
> There is currently at least one bug
Right. I was trying to capture the intent, modulo bugs.
> Once a serialization failure occurs the transaction is flagged as
> "doomed" and will not, under any circumstances be allowed to
> commit. If you find any exception to that, please report it as a
> bug.
Right. I think this prevents any exception-catching arrangements from
suppressing the serialisation failure. Since AIUI it is not possible
to run the outer COMMIT from within an exception trapping context.
If it /is/ possible to run that outer COMMIT in a way which swallows
the exception then this is not a practical problem but the wording
ought to be changed to refer to the success of the COMMIT statement.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]
On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson wrote: > Let me try to summarise my understanding of what the developers think > they can and intend to promise, about SERIALIZABLE transactions: > > There is a consistent serialisation of all transactions which > successfully commit; or which do not attempt to make any changes. > > A "consistent serialisation" means that there is an order in which > the same transactions might have been executed giving exactly the > answers. This includes, if applicable, the same errors. (The > database is free to generate synchronisation failure errors 40P01 and > 40001 whenever it chooses.) I would alter that slightly to: There is a consistent serialization of all serializable transactions which successfully commit. > A transaction which attempts to make any changes, and which does not > commit (whether because the application never asks for COMMIT, or > because of reported synchronisation failure) might see internally > inconsistent data, or an internally-consistent view which is not > compatible with any serialisation of other transactions. An > application which needs a coherent view should not rely on any of the > information from such a transaction. Even a read-only transaction can see a state that is not consistent with business rules (as enforced in the software) given that some particular later state is reached. For examples, please see this Wiki page. You might be particularly interested in the examples in the "Read Only Transactions" section: https://wiki.postgresql.org/wiki/SSI > Serialisation failures in subtransactions might cause the parent > transaction to experience a serialisation failure too. There is currently at least one bug which may allow serialization anomalies into the database if a constraint violation error is thrown in a subtransaction and that subtransaction catches and suppresses that exception and rolls back its work without throwing an error. I expect that any bugs of this type are will be fixed in a minor release set soon -- probably the next one that is released. Note that I don't think that an exception from any source other than a declarative constraint can cause this type of problem, and that other conditions must exist in combination with this to create a serialization anomaly. A serialization failure within any subtransaction will ensure the top level transaction will fail, even if there is an attempt to catch this exception and commit the top level transaction. It would be possible to catch a serialization failure exception and throw some *other* exception to terminate the transaction; however, (to step into very convoluted territory) if that other exception is caught and suppressed, the serialization failure error would occur. Once a serialization failure occurs the transaction is flagged as "doomed" and will not, under any circumstances be allowed to commit. If you find any exception to that, please report it as a bug. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression due to "mm/swap.c: flush lru pvecs on compound page arrival"
Greg KH writes ("Re: Regression due to "mm/swap.c: flush lru pvecs on compound
page arrival""):
> On Wed, Dec 14, 2016 at 03:14:54PM +, Ian Jackson wrote:
> > Start reading at Dec 14 07:59:33.478093. At Dec 14 08:01:38.294433 a
> > log capture process started sending various debug keys to the console.
>
> And is this also an issue in Linus's tree?
Sorry, no, I was unclear: this is a problem in 3.18.y.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] x86/traps: Correct pagefault handling issues introduced in c/s d5c251c
At 16:53 + on 14 Dec (1481734422), Andrew Cooper wrote: > There are two bugs. > > Firstly, the ASSERT(paging_mode_only_log_dirty(d)) can trip when servicing a > hypervisor #PF in the context of an HVM guest, e.g. a copy_to_user() failure > in the shadow pagetable code. > > Secondly, the entry conditions paging_fault() were previously guarded on > !paging_mode_external(d) which limited entry to PV contexts, but for both > guest and hypervisor faults. Switching this to paging_mode_log_dirty() opened > it up to HVM contexts as well. > > Reinstate the old !paging_mode_external(d) check, as it is actually the > relevent fact, and extend the comment to explicitly state that hypervisor > faults should follow this path. > > Inside, we are now guarenteed to be in the context of a PV guest, so can > safely use the assertion about log dirty. > > Signed-off-by: Andrew Cooper Reviewed-by: Tim Deegan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3] x86/traps: Correct pagefault handling issues introduced in c/s d5c251c
There are two bugs.
Firstly, the ASSERT(paging_mode_only_log_dirty(d)) can trip when servicing a
hypervisor #PF in the context of an HVM guest, e.g. a copy_to_user() failure
in the shadow pagetable code.
Secondly, the entry conditions paging_fault() were previously guarded on
!paging_mode_external(d) which limited entry to PV contexts, but for both
guest and hypervisor faults. Switching this to paging_mode_log_dirty() opened
it up to HVM contexts as well.
Reinstate the old !paging_mode_external(d) check, as it is actually the
relevent fact, and extend the comment to explicitly state that hypervisor
faults should follow this path.
Inside, we are now guarenteed to be in the context of a PV guest, so can
safely use the assertion about log dirty.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
v3:
* Rework, to fix it properly.
---
xen/arch/x86/traps.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 2d79ee0..d69c02d 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1797,10 +1797,6 @@ static int fixup_page_fault(unsigned long addr, struct
cpu_user_regs *regs)
if ( in_irq() || !(regs->eflags & X86_EFLAGS_IF) )
return 0;
-/* Logdirty mode is the only expected paging mode for PV guests. */
-if ( paging_mode_enabled(d) )
-ASSERT(paging_mode_only_log_dirty(d));
-
if ( !(regs->error_code & PFEC_page_present) &&
(pagefault_by_memadd(addr, regs)) )
return handle_memadd_fault(addr, regs);
@@ -1831,10 +1827,19 @@ static int fixup_page_fault(unsigned long addr, struct
cpu_user_regs *regs)
return EXCRET_fault_fixed;
}
-/* Logdirty guests call back into the paging code to update shadows. */
-if ( paging_mode_log_dirty(d) )
+/*
+ * For non-external shadowed guests, we fix up both their own pagefaults
+ * and Xen's, since they share the pagetables. This includes hypervisor
+ * faults, e.g. from copy_to_user().
+ */
+if ( paging_mode_enabled(d) && !paging_mode_external(d) )
{
-int ret = paging_fault(addr, regs);
+int ret;
+
+/* Logdirty mode is the only expected paging mode for PV guests. */
+ASSERT(paging_mode_only_log_dirty(d));
+
+ret = paging_fault(addr, regs);
if ( ret == EXCRET_fault_fixed )
trace_trap_two_addr(TRC_PV_PAGING_FIXUP, regs->eip, addr);
return ret;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: ignore most segment bases for 64-bit mode in is_aligned()
On 14/12/16 15:29, Jan Beulich wrote: > ops->read_segment() will report whatever is actually there in the > register, so we need to actively distinguish ES/CS/SS/DS from FS/GS. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: support {RD,WR}{F,G}SBASE
On 14/12/16 14:49, Jan Beulich wrote:
On 14.12.16 at 14:47, wrote:
>> On 14/12/16 13:39, Jan Beulich wrote:
>> On 14.12.16 at 14:28, wrote:
On 14/12/16 13:18, Jan Beulich wrote:
On 14.12.16 at 13:36, wrote:
>> On 14/12/16 09:37, Jan Beulich wrote:
>>> @@ -5205,6 +5206,44 @@ x86_emulate(
>>> }
>>> break;
>>>
>>> +case X86EMUL_OPC_F3(0x0f, 0xae): /* Grp15 */
>>> +{
>>> +unsigned long cr4;
>>> +
>>> +fail_if(modrm_mod != 3);
>> This should surely be an explicit #UD? The only issue is that we don't
>> yet implement Grp15/F3 instructions with memory operands (as there are
>> none yet defined)?
> If there weren't any, I probably would have used #UD here. But
> there are - ptwrite is even in the normal SDM already (but it looks
> to be missing from the opcode map).
I find that the opcode maps are consistently out of date.
However, I don't understand why you have chosen to avoid the #UD. #UD
is the appropriate action for an opcode which isn't implemented.
>>> I don't think we should raise #UD knowingly for the wrong reason.
>>> Hence my plan was to go through all fail_if()-s once we are at a
>>> point where we consider the emulator complete enough, but keep
>>> using fail_if() vs #UD to distinguish cases where we know of gaps
>>> vs an encoding being undefined in up-to-date docs. While I guess
>>> we don't always match this model at present, that was at least
>>> what I have been trying to follow in all my recent work.
>> Hmm.
>>
>> I had considered at one point to have X86EMUL_NOT_IMPLEMENTED which was
>> separate from X86EMUL_UNHANDLEABLE, as they are subtly different.
>> NOT_IMPLEMENTED means "everything else was fine, but I don't know how to
>> do that", whereas UNHANDLEABLE is "something went wrong trying to do
>> that", and is typically used for missing hooks or problems in lower levels.
> Fine with me, preferably when we're closer to covering most of the
> opcode space. Bottom line here though is that unless you insist I'd
> prefer to keep the fail_if() as being more in line with what we do
> elsewhere.
Fine for now.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression due to "mm/swap.c: flush lru pvecs on compound page arrival"
On Wed, Dec 14, 2016 at 03:14:54PM +, Ian Jackson wrote:
> Michal Hocko writes ("Re: Regression due to "mm/swap.c: flush lru pvecs on
> compound page arrival""):
> > On Wed 14-12-16 13:29:56, Ian Jackson wrote:
> > > This commit breaks the test "test-amd64-amd64-xl-qemut-win7-amd64" in
> > > the Xen Project CI system.
> >
> > Could you be more specific about the regression please?
>
> The effect seems to be that it causes some kind of OOM condition
> during boot under Xen:
>
> Dec 14 08:00:04.637998 [ 22.584134] Out of memory: Kill process 2747
> (exim4) score 2 or sacrifice child
>
> It's not quite clear to me but I think the problem may be hardware
> specific.
>
> Full logs are available here:
>
> > > > Last fail repro:
> > > > http://logs.test-lab.xenproject.org/osstest/logs/103315/
>
> See in particular this, which is the host serial console output:
>
> http://logs.test-lab.xenproject.org/osstest/logs/103315/test-amd64-amd64-xl-qemut-win7-amd64/serial-elbling1.log
>
> Start reading at Dec 14 07:59:33.478093. At Dec 14 08:01:38.294433 a
> log capture process started sending various debug keys to the console.
And is this also an issue in Linus's tree?
thanks,
greg k-h
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing baseline-only test] 68219: tolerable FAIL
This run is configured for baseline tests only. flight 68219 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68219/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-xtf-amd64-amd64-5 20 xtf/test-hvm32-invlpg~shadow fail baseline untested test-xtf-amd64-amd64-5 31 xtf/test-hvm32pae-invlpg~shadow fail baseline untested test-xtf-amd64-amd64-5 42 xtf/test-hvm64-invlpg~shadow fail baseline untested test-amd64-amd64-i386-pvgrub 10 guest-start fail baseline untested test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail baseline untested test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail baseline untested test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail baseline untested test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail baseline untested test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail baseline untested test-amd64-amd64-xl-qemut-winxpsp3 9 windows-install fail baseline untested Tests which did not succeed, but are not blocking: test-amd64-i386-rumprun-i386 10 rumprun-demo-xenstorels/xenstorels fail never pass test-xtf-amd64-amd64-4 61 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-2 61 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-3 61 xtf/test-pv32pae-xsa-194 fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail 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-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-rumprun-amd64 10 rumprun-demo-xenstorels/xenstorels fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-5 61 xtf/test-pv32pae-xsa-194 fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-1 61 xtf/test-pv32pae-xsa-194 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 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail 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 test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 57e3ac3a0bceb33093bed584194c7cf163648441 baseline version: xen 77892923406df6026babb493191978ea5000c191 Last test of basis68188 2016-12-10 02:54:55 Z4 days Testing same since68219 2016-12-14 08:14:28 Z0 days1 attempts People who touched revisions under test: Stefano Stabellini jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm
Re: [Xen-devel] [PATCH v2 4/4] nestedhvm: replace VMCX_EADDR by INVALID_PADDR
On 12/14/2016 05:18 AM, Haozhong Zhang wrote: > On 12/14/16 18:11 +0800, Haozhong Zhang wrote: >> ... because INVALID_PADDR is a more general one. >> >> Suggested-by: Jan Beulich >> Signed-off-by: Haozhong Zhang >> --- >> xen/arch/x86/hvm/nestedhvm.c | 2 +- >> xen/arch/x86/hvm/svm/nestedsvm.c | 18 +- >> xen/arch/x86/hvm/svm/vmcb.c | 2 +- >> xen/arch/x86/hvm/vmx/vvmx.c | 16 >> xen/include/asm-x86/hvm/vcpu.h | 2 -- >> 5 files changed, 19 insertions(+), 21 deletions(-) >> > > Forgot to cc AMD maintainers. Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]
Robert Haas writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on
constraint violation [and 2 more messages]"):
> On Wed, Dec 14, 2016 at 9:26 AM, Kevin Grittner wrote:
> > considered. Essentially, the position Ian has been taking is that
> > PostgreSQL should provide the guarantee of (2) above. As far as I
> > can see, that would require using S2PL -- something the community
> > ripped out of PostgreSQL because of its horrible performance and
> > has refused to consider restoring (for good reason, IMO).
>
> I'm not sure Ian is intentionally taking that position. Not all of us
> are as familiar with the ramifications of every serializability
> behavior we may want as you are.
Indeed. I think it's fair to say that I'm totally unfamiliar with the
ramifications. You might also fairly characterise me as naive; I had
certainly made some assumptions which it seems are known (around here)
to be both false and difficult to make true.
Robert Haas writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on
constraint violation [and 2 more messages]"):
> For example, imagine a transaction that queries pg_stat_activity or
> pg_locks and then makes decisions based on the contents thereof.
I agree that such behviour is unreasonable and should be excluded from
consistency guarantees! I don't think (even very naive) application
programmers would disagree. From my point of those tables are `part
of the innards', and expecting transactional behaviour from them is
clearly too optimistic. (I guess that should be made clear somewhere
near where these kind of system tables are mentioned in the docs.)
Let me try to summarise my understanding of what the developers think
they can and intend to promise, about SERIALIZABLE transactions:
There is a consistent serialisation of all transactions which
successfully commit; or which do not attempt to make any changes.
A "consistent serialisation" means that there is an order in which
the same transactions might have been executed giving exactly the
answers. This includes, if applicable, the same errors. (The
database is free to generate synchronisation failure errors 40P01 and
40001 whenever it chooses.)
A transaction which attempts to make any changes, and which does not
commit (whether because the application never asks for COMMIT, or
because of reported synchronisation failure) might see internally
inconsistent data, or an internally-consistent view which is not
compatible with any serialisation of other transactions. An
application which needs a coherent view should not rely on any of the
information from such a transaction.
"Transactions which do not attempt to make any changes" excludes any
transactions whose subtransactions try to make changes.
Serialisation failures in subtransactions might cause the parent
transaction to experience a serialisation failure too. "Try to make
changes" includes even DML statements which are bound to fail.
Is that an accurate statement of the current thinking ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.4-testing bisection] complete test-xtf-amd64-amd64-1
branch xen-4.4-testing xenbranch xen-4.4-testing job test-xtf-amd64-amd64-1 testid leak-check/check Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Tree: xtf git://xenbits.xen.org/xtf.git *** Found and reproduced problem changeset *** Bug is in tree: xtf git://xenbits.xen.org/xtf.git Bug introduced: b945085085fe782d20524b7f4bf95875407cd081 Bug not present: 6d562f0e17d8187aca7a47a38b584b989c8ded7a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103341/ commit b945085085fe782d20524b7f4bf95875407cd081 Author: Andrew Cooper Date: Wed Nov 2 18:44:43 2016 + XSA-195 PoC Signed-off-by: Andrew Cooper For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.4-testing/test-xtf-amd64-amd64-1.leak-check--check.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-4.4-testing/test-xtf-amd64-amd64-1.leak-check--check --summary-out=tmp/103341.bisection-summary --basis-template=102521 --blessings=real,real-bisect xen-4.4-testing test-xtf-amd64-amd64-1 leak-check/check Searching for failure / basis pass: 103240 fail [host=baroque0] / 102718 [host=godello0] 102521 [host=baroque1] 101268 [host=godello1] 101256 [host=italia0] template as basis? using template as basis. Failure / basis pass flights: 103240 / 102521 (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Tree: xtf git://xenbits.xen.org/xtf.git Latest b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 eb200a6a9aca6ea6c03bea986d4b64c090672ed1 5fadf00bf21ad3706f69b12877cd76aab4e17ecd 149c34a6ea0c6821620554059e85cb89acf0ff8f 1f021c88130b4d2d818ba4f269b3929339c00a88 Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 564f935e958bd102df822c978bd021673365dc78 e72488cdcf2208f2df334fa88c35b33e695fa93b 6639a202f285ace4adf57453ade066bd4b4298e0 36431397ac902e791e16a016ade3413bd6b63069 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#b65f2f457c49b2cfd7967c34b7a0b04c25587f13-b65f2f457c49b2cfd7967c34b7a0b04c25587f13 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#564f935e958bd102df822c978bd021673365dc78-eb200a6a9aca6ea6c03bea986d4b64c090672ed1 git://xenbits.xen.org/qemu-xen.git#e72488cdcf2208f2df334fa88c35b33e695fa93b-5fadf00bf21ad3706f69b12877cd76aab4e17ecd git://xenbits.xen.org/xen.git#6639a202f285ace4adf57453ade066bd4b4298e0-149c34a6ea0c6821620554059e85cb89acf0ff8f git://xenbits.xen.org/xtf.git#36431397ac902e791e16a016ade3413bd6b63069-1f021c88130b4d2d818ba4f269b3929339c00a88 Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 464. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 464. Loaded 1277 nodes in revision graph Searching for test results: 102521 [host=baroque1] 102718 [host=godello0] 102769 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 851b5ee8ae2a841373d605ae6f755cb33a3626f9 5fadf00bf21ad3706f69b12877cd76aab4e17ecd 1c1bfc1cf252f76b69664a7a6446d205da28f382 1f021c88130b4d2d818ba4f269b3929339c00a88 102863 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 851b5ee8ae2a841373d605ae6f755cb33a3626f9 5fadf00bf21ad3706f69b12877cd76aab4e17ecd 1c1bfc1cf252f76b69664a7a6446d205da28f382 1f021c88130b4d2d818ba4f269b3929339c00a88 102808 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 851b5ee8ae2a841373d605ae6f755cb33a3626f9 5fadf00bf21ad3706f69b12877cd76aab4e17ecd 1c1bfc1cf252f76b69664a7a6446d205da28f382 1f021c88130b4d2d818ba4f269b3929339c00a88 102914 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 851b5ee8ae2a841373d605ae6f755cb33a3626f9 5fadf00bf21ad3706f69b12877cd76aab4e17ecd 1c1bfc1cf252f76b69664a7a6446d205da28f382 1f021c88130b4d2d818ba4f269b3929339c00a88 102962 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 851b5ee8ae2a841373d605ae6f755cb33a3626f9 5fadf00bf21ad3706f69b12877cd76aab4e17ecd 1c1bfc1cf252f76b69664a7a6446d205da28f382 1f021c88130b4d2d818ba4f269b3929339c00a88 103058 fail b
[Xen-devel] [ovmf test] 103293: all pass - PUSHED
flight 103293 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103293/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dc756baeda55490202f3150a8821b5164e906451
baseline version:
ovmf 94a1bc1212edf521b7c96bfb9dc653818c95bec7
Last test of basis 103226 2016-12-12 21:55:23 Z1 days
Testing same since 103293 2016-12-13 22:50:12 Z0 days1 attempts
People who touched revisions under test:
Hao Wu
Jiewen Yao
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=dc756baeda55490202f3150a8821b5164e906451
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
dc756baeda55490202f3150a8821b5164e906451
+ branch=ovmf
+ revision=dc756baeda55490202f3150a8821b5164e906451
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' xdc756baeda55490202f3150a8821b5164e906451 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/lin
Re: [Xen-devel] [RFC PATCH] vvmx: replace vmreturn() by vmsucceed() and vmfail*()
On Wed, Dec 14, 2016 at 07:29:21PM +0800, Haozhong Zhang wrote: > Replace vmreturn() by vmsucceed(), vmfail(), vmfail_valid() and > vmfail_invalid(), which are consistent to the pseudo code on Intel > SDM, and allow to return VM instruction error numbers to L1 > hypervisor. > > Signed-off-by: Haozhong Zhang Reviewed-by: Konrad Rzeszutek Wilk And thank you for doing this so shortly! ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 4/4] nestedhvm: replace VMCX_EADDR by INVALID_PADDR
On Wed, Dec 14, 2016 at 03:16:33AM -0700, Jan Beulich wrote: > >>> On 14.12.16 at 11:11, wrote: > > ... because INVALID_PADDR is a more general one. > > > > Suggested-by: Jan Beulich > > Signed-off-by: Haozhong Zhang > > Reviewed-by: Jan Beulich > > Thanks for doing this! Indeed! Thank you. And Reviewed-by: Konrad Rzeszutek Wilk as well. > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/paging: Update paging_mark_dirty() to use mfn_t
On Wed, Dec 14, 2016 at 03:28:49PM +, Andrew Cooper wrote:
> On 14/12/16 15:13, Jan Beulich wrote:
> On 14.12.16 at 15:26, wrote:
> >> Signed-off-by: Andrew Cooper
> >> ---
> >> CC: Jan Beulich
> >> CC: Tim Deegan
> >> CC: George Dunlap
> >> CC: Konrad Rzeszutek Wilk
> >> CC: Stefano Stabellini
> >> CC: Julien Grall
> >>
> >> The one use of paging_mark_dirty() in common/tmem shows that TMEM currently
> >> wont compile for ARM.
> > I don't understand: It builds prior to this change, so why would it
> > stop building afterwards? Without this remark I'd have given my
> > R-b ...
>
> Oh. cli_{get,put}_page() are stubbed to ASSERT(0) on ARM, which
> restricts the paging_mark_dirty() call to !ARM.
>
> The history is weird here. The last change here was you taking out the
> __ia64__ code.
>
> I can't work out why they should be stubbed separately; there is nothing
> overly x86-specific in them.
>
> Konrad: Any ideas?
My recollection was that nobody had tried tmem under ARM and it made
it just easier to bypass it until the security audit is completed.
But ARM is the perfect candidate for tmem.. I did have enabling tmem
on ARM on my TODO list but it is below migration. Hm.
I am with changes that look "OKish" to the tmem and then fixing
them when I get my hands on enabling tmem on ARM.
>
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/paging: Update paging_mark_dirty() to use mfn_t
At 14:26 + on 14 Dec (1481725588), Andrew Cooper wrote: > Signed-off-by: Andrew Cooper Both patches Acked-by: Tim Deegan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/paging: Rename paging_mark_pfn_dirty() and use pfn_t
On 14/12/16 15:22, Jan Beulich wrote:
On 14.12.16 at 15:26, wrote:
>> paging_mark_gfn_dirty() actually takes a pfn, even by paramter name. Rename
>> the function and alter the type to pfn_t to match.
>>
>> Push pfn_t into the LOGDIRTY_IDX() macros, and clean up a couple of local
>> variable types in paging_mark_pfn_dirty().
>>
>> Leave an explicit comment in vmx_vcpu_flush_pml_buffer() when we intentally
>> perform a straight conversion from gfn to pfn.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
> with two remarks:
>
>> @@ -331,8 +331,8 @@ void paging_mark_gfn_dirty(struct domain *d, unsigned
>> long pfn)
>> if ( changed )
>> {
>> PAGING_DEBUG(LOGDIRTY,
>> - "marked mfn %" PRI_mfn " (pfn=%lx), dom %d\n",
>> - mfn_x(mfn), pfn, d->domain_id);
>> + "marked mfn %" PRI_mfn " (pfn %" PRI_pfn "), dom %d\n",
>> + mfn_x(mfn), pfn_x(pfn), d->domain_id);
> Mind making the domain part canonical (i.e. d%d), and perhaps
> even moving it to the front ("d%d: ...\n")?
Ok.
>
>> @@ -345,23 +345,23 @@ void paging_mark_gfn_dirty(struct domain *d, unsigned
>> long pfn)
>> /* Mark a page as dirty */
>> void paging_mark_dirty(struct domain *d, mfn_t gmfn)
>> {
>> -unsigned long pfn;
>> +pfn_t pfn;
>>
>> if ( !paging_mode_log_dirty(d) || !mfn_valid(gmfn) ||
>> page_get_owner(mfn_to_page(gmfn)) != d )
>> return;
>>
>> /* We /really/ mean PFN here, even for non-translated guests. */
>> -pfn = get_gpfn_from_mfn(mfn_x(gmfn));
>> +pfn = _pfn(get_gpfn_from_mfn(mfn_x(gmfn)));
>>
>> -paging_mark_gfn_dirty(d, pfn);
>> +paging_mark_pfn_dirty(d, pfn);
>> }
> Looking at all of this, could patch 1 perhaps rename gmfn to mfn
> in this function?
This actually follows the shadow naming convention, of an mfn belonging
to a guest, and as checked in the first if clause.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86emul: ignore most segment bases for 64-bit mode in is_aligned()
ops->read_segment() will report whatever is actually there in the
register, so we need to actively distinguish ES/CS/SS/DS from FS/GS.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1642,12 +1642,17 @@ static bool is_aligned(enum x86_segment
/* Expecting powers of two only. */
ASSERT(!(size & (size - 1)));
-/* No alignment checking when we have no way to read segment data. */
-if ( !ops->read_segment )
-return true;
+if ( mode_64bit() && seg < x86_seg_fs )
+memset(®, 0, sizeof(reg));
+else
+{
+/* No alignment checking when we have no way to read segment data. */
+if ( !ops->read_segment )
+return true;
-if ( ops->read_segment(seg, ®, ctxt) != X86EMUL_OKAY )
-return false;
+if ( ops->read_segment(seg, ®, ctxt) != X86EMUL_OKAY )
+return false;
+}
return !((reg.base + offs) & (size - 1));
}
x86emul: ignore most segment bases for 64-bit mode in is_aligned()
ops->read_segment() will report whatever is actually there in the
register, so we need to actively distinguish ES/CS/SS/DS from FS/GS.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1642,12 +1642,17 @@ static bool is_aligned(enum x86_segment
/* Expecting powers of two only. */
ASSERT(!(size & (size - 1)));
-/* No alignment checking when we have no way to read segment data. */
-if ( !ops->read_segment )
-return true;
+if ( mode_64bit() && seg < x86_seg_fs )
+memset(®, 0, sizeof(reg));
+else
+{
+/* No alignment checking when we have no way to read segment data. */
+if ( !ops->read_segment )
+return true;
-if ( ops->read_segment(seg, ®, ctxt) != X86EMUL_OKAY )
-return false;
+if ( ops->read_segment(seg, ®, ctxt) != X86EMUL_OKAY )
+return false;
+}
return !((reg.base + offs) & (size - 1));
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/paging: Update paging_mark_dirty() to use mfn_t
On 14/12/16 15:13, Jan Beulich wrote:
On 14.12.16 at 15:26, wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Tim Deegan
>> CC: George Dunlap
>> CC: Konrad Rzeszutek Wilk
>> CC: Stefano Stabellini
>> CC: Julien Grall
>>
>> The one use of paging_mark_dirty() in common/tmem shows that TMEM currently
>> wont compile for ARM.
> I don't understand: It builds prior to this change, so why would it
> stop building afterwards? Without this remark I'd have given my
> R-b ...
Oh. cli_{get,put}_page() are stubbed to ASSERT(0) on ARM, which
restricts the paging_mark_dirty() call to !ARM.
The history is weird here. The last change here was you taking out the
__ia64__ code.
I can't work out why they should be stubbed separately; there is nothing
overly x86-specific in them.
Konrad: Any ideas?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression due to "mm/swap.c: flush lru pvecs on compound page arrival"
On Wed 14-12-16 13:29:56, Ian Jackson wrote:
> osstest service owner writes ("[linux-3.18 bisection] complete
> test-amd64-amd64-xl-qemut-win7-amd64"):
> > *** Found and reproduced problem changeset ***
> >
> > Bug is in tree: linux
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > Bug introduced: a2d8c514753276394d68414f563591f174ef86cb
> > Bug not present: 8f620446135b64ca6f96cf32066a76d64e79a388
> > Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103315/
> >
> > commit a2d8c514753276394d68414f563591f174ef86cb
> > Author: Lukasz Odzioba
> > Date: Fri Jun 24 14:50:01 2016 -0700
> >
> > mm/swap.c: flush lru pvecs on compound page arrival
>
> This commit breaks the test "test-amd64-amd64-xl-qemut-win7-amd64" in
> the Xen Project CI system.
Ohh, I can see it now. This is not an upstream commit. This is a 3.18.37
backport which was wrong! You need the follow up fix 52c84a95dc6a
("4.1.28 Fix bad backport of 8f182270dfec "mm/swap.c: flush lru pvecs on
compound page arrival""). The primary problem was that __lru_cache_add
has leaked pages which would explain your OOM.
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/paging: Rename paging_mark_pfn_dirty() and use pfn_t
>>> On 14.12.16 at 15:26, wrote:
> paging_mark_gfn_dirty() actually takes a pfn, even by paramter name. Rename
> the function and alter the type to pfn_t to match.
>
> Push pfn_t into the LOGDIRTY_IDX() macros, and clean up a couple of local
> variable types in paging_mark_pfn_dirty().
>
> Leave an explicit comment in vmx_vcpu_flush_pml_buffer() when we intentally
> perform a straight conversion from gfn to pfn.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with two remarks:
> @@ -331,8 +331,8 @@ void paging_mark_gfn_dirty(struct domain *d, unsigned
> long pfn)
> if ( changed )
> {
> PAGING_DEBUG(LOGDIRTY,
> - "marked mfn %" PRI_mfn " (pfn=%lx), dom %d\n",
> - mfn_x(mfn), pfn, d->domain_id);
> + "marked mfn %" PRI_mfn " (pfn %" PRI_pfn "), dom %d\n",
> + mfn_x(mfn), pfn_x(pfn), d->domain_id);
Mind making the domain part canonical (i.e. d%d), and perhaps
even moving it to the front ("d%d: ...\n")?
> @@ -345,23 +345,23 @@ void paging_mark_gfn_dirty(struct domain *d, unsigned
> long pfn)
> /* Mark a page as dirty */
> void paging_mark_dirty(struct domain *d, mfn_t gmfn)
> {
> -unsigned long pfn;
> +pfn_t pfn;
>
> if ( !paging_mode_log_dirty(d) || !mfn_valid(gmfn) ||
> page_get_owner(mfn_to_page(gmfn)) != d )
> return;
>
> /* We /really/ mean PFN here, even for non-translated guests. */
> -pfn = get_gpfn_from_mfn(mfn_x(gmfn));
> +pfn = _pfn(get_gpfn_from_mfn(mfn_x(gmfn)));
>
> -paging_mark_gfn_dirty(d, pfn);
> +paging_mark_pfn_dirty(d, pfn);
> }
Looking at all of this, could patch 1 perhaps rename gmfn to mfn
in this function?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] gnttab_end_foreign_access/unmap fails for GNTMAP_device_map?
Hi, Jan! On 12/14/2016 04:59 PM, Jan Beulich wrote: On 14.12.16 at 15:46, wrote: Hi, all! I am trying to map and then unmap grant refs in Dom0 from DomU which are used for DMA by a real device in Dom0 (x86_64). Mapping is done with GNTMAP_host_map | GNTMAP_device_map flags and device can successfully access the pages and do DMA. The problem is I cannot unmap the buffer back: Dom0 says unmapping was done w/o errors, but when DomU tries to gnttab_end_foreign_access I see lots of [ 55.052979] xen:grant_table: WARNING: g.e. 0xdce still in use! [ 55.052984] deferring g.e. 0xdce (pfn 0x) messages in DomU and those grefs are never freed and system gets exhausted at some point. The same code, but with only GNTMAP_host_map flag is able to release references as expected. Even if I don't give the buffer to any HW device in Dom0 the use of GNTMAP_device_map flag makes troubles. I also tried to add GNTMAP_readonly, but it didn't help. In DomU right before doing gnttab_end_foreign_access I am checking flags with gnttab_query_foreign_access: both GTF_reading and GTF_writing are set. With GNTMAP_readonly only GTF_reading (which I believe is expected). I tried to look at the Xen sources and thought that it could probably be related to pin/unpin? Possibly - looking at __gnttab_unmap_common(), are you passing GNTMAP_device_map also to the unmap operation (together with the frame number, or else the flag would be ignored)? Jan Indeed, it helped: gnttab_set_unmap_op(&unmap_ops[i], addr, GNTMAP_host_map | GNTMAP_device_map, xen_obj->map_handles[i]); *unmap_ops[i].dev_bus_addr = xen_obj->dev_bus_addr[i];* I was confused by gnttab_set_unmap_op which unmap->dev_bus_addr = 0; Can anyone please shed some light if anything additional needs to be done in case GNTMAP_device_map is in use or point me to what needs to checked so I can find the root cause? Thank you, Oleksandr Thank you, Oleksandr ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression due to "mm/swap.c: flush lru pvecs on compound page arrival"
Michal Hocko writes ("Re: Regression due to "mm/swap.c: flush lru pvecs on
compound page arrival""):
> On Wed 14-12-16 13:29:56, Ian Jackson wrote:
> > This commit breaks the test "test-amd64-amd64-xl-qemut-win7-amd64" in
> > the Xen Project CI system.
>
> Could you be more specific about the regression please?
The effect seems to be that it causes some kind of OOM condition
during boot under Xen:
Dec 14 08:00:04.637998 [ 22.584134] Out of memory: Kill process 2747
(exim4) score 2 or sacrifice child
It's not quite clear to me but I think the problem may be hardware
specific.
Full logs are available here:
> > > Last fail repro:
> > > http://logs.test-lab.xenproject.org/osstest/logs/103315/
See in particular this, which is the host serial console output:
http://logs.test-lab.xenproject.org/osstest/logs/103315/test-amd64-amd64-xl-qemut-win7-amd64/serial-elbling1.log
Start reading at Dec 14 07:59:33.478093. At Dec 14 08:01:38.294433 a
log capture process started sending various debug keys to the console.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/paging: Update paging_mark_dirty() to use mfn_t
>>> On 14.12.16 at 15:26, wrote: > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Tim Deegan > CC: George Dunlap > CC: Konrad Rzeszutek Wilk > CC: Stefano Stabellini > CC: Julien Grall > > The one use of paging_mark_dirty() in common/tmem shows that TMEM currently > wont compile for ARM. I don't understand: It builds prior to this change, so why would it stop building afterwards? Without this remark I'd have given my R-b ... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/traps: Correct overly-general assertion introduced in c/s d5c251c
>>> On 14.12.16 at 15:11, wrote:
> @@ -1831,10 +1827,17 @@ static int fixup_page_fault(unsigned long addr,
> struct cpu_user_regs *regs)
> return EXCRET_fault_fixed;
> }
>
> -/* Logdirty guests call back into the paging code to update shadows. */
> -if ( paging_mode_log_dirty(d) )
> +/*
> + * Logdirty guests call back into the paging code to update shadows. We
> + * don't expect any other paging modes with PV guests.
> + */
> +if ( guest_mode(regs) && paging_mode_enabled(d) )
As said in the (apparently to late) reply to v1 - I think guest_mode()
is wrong to use here, as hypervisor accesses to guest buffers also
need to be handled by paging_fault() when the guest is in log-dirty
mode.
Jan
> {
> -int ret = paging_fault(addr, regs);
> +int ret;
> +
> +ASSERT(paging_mode_only_log_dirty(d));
> +
> +ret = paging_fault(addr, regs);
> if ( ret == EXCRET_fault_fixed )
> trace_trap_two_addr(TRC_PV_PAGING_FIXUP, regs->eip, addr);
> return ret;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]
On Wed, Dec 14, 2016 at 8:38 AM, Robert Haas wrote: > On Wed, Dec 14, 2016 at 9:26 AM, Kevin Grittner wrote: >> Predicate locks >> from reads within subtransactions are not discarded, even if the >> work of the subtransaction is otherwise discarded. > > Oh, interesting. Just to be clear, I'm not lobbying to change that; I > was guessing (very late at night) what decision you probably made and > it seems I was incorrect. But doesn't that imply that if a read fails > in a subtransaction with serialization_error, the parent MUST also be > killed with serialization_error? To prevent serialization anomalies, a top level transaction which gets a serialization error in a subtransaction must fail. To provide the best information for an application framework which wants to make smart decisions about when to retry a transaction from the start, it should fail with a serialization error. I'm starting to think that, in addition to the doomed flag mechanism, we should perhaps (as you suggested earlier in this thread) not allow the serialization failure exception to be caught. Or require that it be re-thrown? I don't know. Maybe if someone catches a serialization failure error, they should just be told that they can't complain about where, later in the transaction, it might be re-thrown. (And yes, that could be in a COMMIT, even for a read-only transaction.) It may be that catching a serialization failure and throwing a *different* error could confuse the application framework's retry logic; I think at that point we have to give up and let that be. There may be some circumstances where there is a valid need to replace a serialization failure with some other error that you *want* to have appear in front of an end user. >> Fortunately, Thomas Munro took an interest in the problem as it >> related to duplicates on primary keys, unique constraints, and >> unique indexes, and put forward a patch that cured the defect in >> the common cases, and provided an easy workaround for the one case >> he was unable to fix in that initial patch. To finish the work for >> these constraints and indexes, I think we need to add predicate >> locking while descending to the insertion point during the check >> for an existing duplicate. > > I suggest adding something about this to README-SSI as a known issue. Good idea. Will do. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 103336: regressions - FAIL
flight 103336 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103336/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 96a7cb37b921d2b320183d194d143262e1dd5b53
baseline version:
xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5
Last test of basis 103284 2016-12-13 19:03:56 Z0 days
Failing since103292 2016-12-13 22:19:08 Z0 days6 attempts
Testing same since 103336 2016-12-14 13:01:52 Z0 days1 attempts
People who touched revisions under test:
Cédric Bosdonnat
Ian Jackson
Jan Beulich
Stefano Stabellini
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt fail
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 96a7cb37b921d2b320183d194d143262e1dd5b53
Author: Jan Beulich
Date: Wed Dec 14 10:11:08 2016 +0100
x86emul: MOVNTI does not allow REP prefixes
Just like 66, prefixes F3 and F2 cause #UD.
Also adjust a related comment, which in its previous wording was
misleading (as in 16-bit mode there would nothing be undone when
adjusting operand size from 2 to 4).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit bd201eb1681ce6eb1b2d53b4d26a27081956770f
Author: Jan Beulich
Date: Wed Dec 14 10:10:39 2016 +0100
x86emul: check for LAHF_LM availability
We can't exclude someone wanting to hide LAHF/SAHF from 64-bit guests.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit 4133077d06a14d041d68250e67eac4d7bcbabfcf
Author: Jan Beulich
Date: Wed Dec 14 10:10:11 2016 +0100
x86emul: check for CLFLUSH{,OPT} availability
We can't exclude someone wanting to hide either of the instructions
from guests.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit d95533f554cde498b9afe731b94a4d9198b47cbe
Author: Jan Beulich
Date: Wed Dec 14 10:09:40 2016 +0100
x86emul: check for SYSENTER/SYSEXIT availability
We can't exclude someone wanting to hide the instructions from guests.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit 54abe826c8297e12f805be2bcf318ef75cc7f58d
Author: Jan Beulich
Date: Wed Dec 14 10:08:22 2016 +0100
x86emul: CMPXCHG{8,16}B ignore prefixes
This removes 0F C7 from the list of two-byte opcodes treating prefixes
66, F3, and F2 as opcode extensions. We better manually handle this in
the opcode specific code:
- CMPXCHG8B ignores all these prefixes (its handling is being adjusted
accordingly, with a respective test case added as well, to avoid
re-introducing the subject of XSA-200),
- RDRAND/RDSEED (support to be added subsequently) honor 66, but treat
F3 and F2 as opcode extensions (resolving to RDPID in the RDSEED
case, which in turn ignores 66).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit 6cf995f1f59240532e27cb788a390185f4276d6f
Author: Jan Beulich
Date: Wed Dec 14 09:54:35 2016 +0100
x86/PV: prefer pv_inject_hw_exception()
... over editing the error code and calling do_guest_trap().
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit 4999bf3e8b4ced3fbdc4f64443a7fdab638322bb
Author: Jan Beulich
Date: Wed Dec 14 09:54:03 2016 +0100
x86/PV: use generic emulator for privileged instruction handling
There's a new emulator return code being added to allow bypassing
certain operations (see the code
Re: [Xen-devel] gnttab_end_foreign_access/unmap fails for GNTMAP_device_map?
>>> On 14.12.16 at 15:46, wrote: > Hi, all! > > I am trying to map and then unmap grant refs in Dom0 from DomU > which are used for DMA by a real device in Dom0 (x86_64). > Mapping is done with GNTMAP_host_map | GNTMAP_device_map flags > and device can successfully access the pages and do DMA. > The problem is I cannot unmap the buffer back: Dom0 says > unmapping was done w/o errors, but when DomU tries to > gnttab_end_foreign_access I see lots of > [ 55.052979] xen:grant_table: WARNING: g.e. 0xdce still in use! > [ 55.052984] deferring g.e. 0xdce (pfn 0x) > messages in DomU and those grefs are never freed and system gets > exhausted at some point. > > The same code, but with only GNTMAP_host_map flag is able to release > references as expected. Even if I don't give the buffer to any > HW device in Dom0 the use of GNTMAP_device_map flag makes troubles. > I also tried to add GNTMAP_readonly, but it didn't help. > In DomU right before doing gnttab_end_foreign_access I am checking > flags with gnttab_query_foreign_access: both GTF_reading > and GTF_writing are set. With GNTMAP_readonly only GTF_reading > (which I believe is expected). > I tried to look at the Xen sources and thought that it could > probably be related to pin/unpin? Possibly - looking at __gnttab_unmap_common(), are you passing GNTMAP_device_map also to the unmap operation (together with the frame number, or else the flag would be ignored)? Jan > Can anyone please shed some light if anything additional needs to > be done in case GNTMAP_device_map is in use or point me to > what needs to checked so I can find the root cause? > > Thank you, > Oleksandr ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one
On Tue, 2016-12-13 at 19:00 +, Julien Grall wrote: > Hi all, > > Stefano suggested to move the call at 5pm and I haven't seen any > disagreement. > > So the call will be tomorrow (Wednesday 14th December at 5pm). > Hey, I'm not sure I will be able join today. Both my interest and my contribution to the discussion is all about big.LITTLE (and, in general, heterogeneous processing support), for which I sent a design doc a few days ago. I'll keep an eye out for the minute. Feel free to forward to me any question and/or bring me in any discussion related to such topic. Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: support {RD,WR}{F,G}SBASE
>>> On 14.12.16 at 14:47, wrote:
> On 14/12/16 13:39, Jan Beulich wrote:
> On 14.12.16 at 14:28, wrote:
>>> On 14/12/16 13:18, Jan Beulich wrote:
>>> On 14.12.16 at 13:36, wrote:
> On 14/12/16 09:37, Jan Beulich wrote:
>> @@ -5205,6 +5206,44 @@ x86_emulate(
>> }
>> break;
>>
>> +case X86EMUL_OPC_F3(0x0f, 0xae): /* Grp15 */
>> +{
>> +unsigned long cr4;
>> +
>> +fail_if(modrm_mod != 3);
> This should surely be an explicit #UD? The only issue is that we don't
> yet implement Grp15/F3 instructions with memory operands (as there are
> none yet defined)?
If there weren't any, I probably would have used #UD here. But
there are - ptwrite is even in the normal SDM already (but it looks
to be missing from the opcode map).
>>> I find that the opcode maps are consistently out of date.
>>>
>>> However, I don't understand why you have chosen to avoid the #UD. #UD
>>> is the appropriate action for an opcode which isn't implemented.
>> I don't think we should raise #UD knowingly for the wrong reason.
>> Hence my plan was to go through all fail_if()-s once we are at a
>> point where we consider the emulator complete enough, but keep
>> using fail_if() vs #UD to distinguish cases where we know of gaps
>> vs an encoding being undefined in up-to-date docs. While I guess
>> we don't always match this model at present, that was at least
>> what I have been trying to follow in all my recent work.
>
> Hmm.
>
> I had considered at one point to have X86EMUL_NOT_IMPLEMENTED which was
> separate from X86EMUL_UNHANDLEABLE, as they are subtly different.
> NOT_IMPLEMENTED means "everything else was fine, but I don't know how to
> do that", whereas UNHANDLEABLE is "something went wrong trying to do
> that", and is typically used for missing hooks or problems in lower levels.
Fine with me, preferably when we're closer to covering most of the
opcode space. Bottom line here though is that unless you insist I'd
prefer to keep the fail_if() as being more in line with what we do
elsewhere.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/traps: Correct overly-general assertion introduced in c/s d5c251c
>>> On 14.12.16 at 14:56, wrote: > On 14/12/16 12:52, Jan Beulich wrote: > On 14.12.16 at 12:35, wrote: >>> The assertion about guest paging mode must only apply to guest pagefaults. >>> >>> This ASSERT() accidentally also trips if Xen takes a pagefault when in HVM >>> context, such as a copy_to_user() failure in the shadow pagetable code. >>> >>> Signed-off-by: Andrew Cooper >> Reviewed-by: Jan Beulich >> >> But isn't the other piece the original patch touched in the same >> function suffering a similar problem? I.e. can't this mis-trigger >> when dealing with a page fault in Xen while in the context of a >> HVM guest in log-dirty mode, and hence needs re-adding the >> !paging_mode_external() check (or alternatively using >> paging_mode_only_log_dirty() instead of paging_mode_log_dirty())? > > Good point, although it should still be guest_mode() to be more clearly > avoiding the hypervisor case. Remember the old comment you've replaced: This code appears to be meant to also take care of certain hypervisor faults (I guess when accessing guest memory while the guest is in log-dirty mode). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] gnttab_end_foreign_access/unmap fails for GNTMAP_device_map?
Hi, all! I am trying to map and then unmap grant refs in Dom0 from DomU which are used for DMA by a real device in Dom0 (x86_64). Mapping is done with GNTMAP_host_map | GNTMAP_device_map flags and device can successfully access the pages and do DMA. The problem is I cannot unmap the buffer back: Dom0 says unmapping was done w/o errors, but when DomU tries to gnttab_end_foreign_access I see lots of [ 55.052979] xen:grant_table: WARNING: g.e. 0xdce still in use! [ 55.052984] deferring g.e. 0xdce (pfn 0x) messages in DomU and those grefs are never freed and system gets exhausted at some point. The same code, but with only GNTMAP_host_map flag is able to release references as expected. Even if I don't give the buffer to any HW device in Dom0 the use of GNTMAP_device_map flag makes troubles. I also tried to add GNTMAP_readonly, but it didn't help. In DomU right before doing gnttab_end_foreign_access I am checking flags with gnttab_query_foreign_access: both GTF_reading and GTF_writing are set. With GNTMAP_readonly only GTF_reading (which I believe is expected). I tried to look at the Xen sources and thought that it could probably be related to pin/unpin? Can anyone please shed some light if anything additional needs to be done in case GNTMAP_device_map is in use or point me to what needs to checked so I can find the root cause? Thank you, Oleksandr ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]
On Wed, Dec 14, 2016 at 9:40 AM, Kevin Grittner wrote: > On Wed, Dec 14, 2016 at 8:27 AM, Robert Haas wrote: >> But even after that fix, at the least, you'll still be able to >> demonstrate the same problem by trapping serialization_failure rather >> than unique_constraint. > > I hope not; the "doomed" flag associated with a serializable > transaction should cause another attempt to cancel the transaction > at every subsequent opportunity, including commit. While we're > digging into bugs in this area it wouldn't hurt (as I said in my > prior post) to confirm that this is being handled everywhere it > should be, but I'd be kinda surprised if it wasn't. Oh, hmm. So you're saying that if I begin a subtransaction, read some data that causes a serialization anomaly, and then rollback the subtransaction, my toplevel transaction is now doomed? If so, then isn't that a counterexample to my proposition that a read-only transaction can't be cancelled at commit time? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [MINIOS PATCH] build: prepend OBJ_DIR to linker script
On Tue, Dec 13, 2016 at 10:49:09PM +0100, Samuel Thibault wrote:
> Juergen Gross, on Tue 13 Dec 2016 16:18:07 +0100, wrote:
> > On 13/12/16 16:02, Wei Liu wrote:
> > > After 5623e2d2 ("x86: use unified linker script") the linker script for
> > > x86 build is generated. But the special rule to generate linker script
> > > doesn't have OBJ_DIR prepended so in parallel build the same file is
> > > written multiple times. This is racy and would cause parallel build to
> > > fail.
> > >
> > > Fix this by prepending OBJ_DIR to the path of linker script. Change
> > > other variables where necessary.
> > >
> > > Signed-off-by: Wei Liu
> >
> > Reviewed-by: Juergen Gross
>
> Acked-by: Samuel Thibault
Thanks. Pushed.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]
On Wed, Dec 14, 2016 at 8:27 AM, Robert Haas wrote: > But even after that fix, at the least, you'll still be able to > demonstrate the same problem by trapping serialization_failure rather > than unique_constraint. I hope not; the "doomed" flag associated with a serializable transaction should cause another attempt to cancel the transaction at every subsequent opportunity, including commit. While we're digging into bugs in this area it wouldn't hurt (as I said in my prior post) to confirm that this is being handled everywhere it should be, but I'd be kinda surprised if it wasn't. > imagine a transaction that queries pg_stat_activity or > pg_locks and then makes decisions based on the contents thereof. That > transaction is determined to behave different under concurrency than > it does on an idle system, and even the ineluctable triumvirate of > Kevin Grittner, Dan Ports, and Michael Cahill will not be able to > prevent it from doing so. That's not a bug. OK, I'll agree that it may be theoretically possible to create some sort of "side channel" for seeing data which subverts serializability in some arcane way. I would agree that's not a bug any more than limited data that is unavoidably leaked through security barriers is. I don't think that subtransactions should rise to that level, though. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]
Thanks for the reply. On Wed, Dec 14, 2016 at 9:26 AM, Kevin Grittner wrote: > considered. Essentially, the position Ian has been taking is that > PostgreSQL should provide the guarantee of (2) above. As far as I > can see, that would require using S2PL -- something the community > ripped out of PostgreSQL because of its horrible performance and > has refused to consider restoring (for good reason, IMO). I'm not sure Ian is intentionally taking that position. Not all of us are as familiar with the ramifications of every serializability behavior we may want as you are. > Huh, I had to think about that for a minute, but you are right > about never rolling back a read-only transaction at commit time ... Yeah, I had to think about it for about an hour ... and look at the code and README-SSI. So if you only had to think about it for a minute, you win. :-) >> if either transaction had executed before the other in a >> serial schedule, the second transaction in the schedule would have had >> to have seen (A, B') or (A', B) rather than (A, B), but that's not >> what happened. But what if each of T1 and T2 did the reads in a >> subtransaction, rolled it back, and then did the write in the main >> transaction and committed? The database system has two options. >> First, it could assume that the toplevel transaction may have relied >> on the results of the aborted subtransaction. > > This is what we do in our implementation of SSI. Predicate locks > from reads within subtransactions are not discarded, even if the > work of the subtransaction is otherwise discarded. Oh, interesting. Just to be clear, I'm not lobbying to change that; I was guessing (very late at night) what decision you probably made and it seems I was incorrect. But doesn't that imply that if a read fails in a subtransaction with serialization_error, the parent MUST also be killed with serialization_error? If not, then I don't see how you can escape having results that, overall, are not serializable. > What we missed is that, while we took action to try to ensure that > a serialization failure could not be discarded, we didn't consider > that a constraint violation exception which was preventing an > anomaly *could* be discarded. Effectively, this has escalated > detection of serialization failures involving reads which are part > of enforcing declarative constraints from the level of a feature > request to cure a significant annoyance for those using them, to a > bug fix necessary to prevent serialization anomalies. Hmm. I see. > Fortunately, Thomas Munro took an interest in the problem as it > related to duplicates on primary keys, unique constraints, and > unique indexes, and put forward a patch that cured the defect in > the common cases, and provided an easy workaround for the one case > he was unable to fix in that initial patch. To finish the work for > these constraints and indexes, I think we need to add predicate > locking while descending to the insertion point during the check > for an existing duplicate. I suggest adding something about this to README-SSI as a known issue. > I'm not sure about foreign key constraints and exclusion > constraints. I have neither seen a failure related to either of > these, nor proven that there cannot be one. Without having > assessed the scope of the problems (if any) in those constraints, > it's hard to say what needs to be done or how much work it is. I think it's a natural result of implementing techniques from academic research papers that there will sometimes be open research questions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]
On Wed, Dec 14, 2016 at 9:05 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> I have not read any database literature on the interaction of >> serializability with subtransactions. This seems very thorny. >> Suppose T1 reads A and B and updates A -> A' while concurrently T2 >> reads A and B and updates B -> B'. This is obviously not >> serializable; if either transaction had executed before the other in a >> serial schedule, the second transaction in the schedule would have had >> to have seen (A, B') or (A', B) rather than (A, B), but that's not >> what happened. But what if each of T1 and T2 did the reads in a >> subtransaction, rolled it back, and then did the write in the main >> transaction and committed? The database system has two options. >> First, it could assume that the toplevel transaction may have relied >> on the results of the aborted subtransaction. But if it does that, >> then any serialization failure which afflicts a subtransaction must >> necessarily also kill the main transaction, which seems pedantic and >> unhelpful. If you'd wanted the toplevel transaction to be killled, >> you wouldn't have used a subtransaction, right? Second, it could >> assume that the toplevel transaction in no way relied on or used the >> values obtained from the aborted subtransaction. However, that >> defeats the whole purpose of having subtransactions in the first >> place. What's the point of being able to start subtransactions if you >> can't roll them back and then decide to do something else instead? It >> seems to me that what the database system should do is make that >> second assumption, and what the user should do is understand that to >> the degree that transactions depend on the results of aborted >> subtransactions, there may be serialization anomalies that go >> undetected. > > Actually, Ian's sample transaction is even more malicious, because the > problem is not caused by reads within the aborted subtransaction -- the > cached-in-app reads occured *before* the subtransaction started in the > first place. I think saving a count(*) across a possibly-failed > insertion on the same table is wrong. I can't blame the database for > the behavior. I don't see why it's wrong to cache a COUNT(*) across a possibly-failed substransaction; instead, I would argue that the problem is that by relying on the knowledge that the subtransaction failed while inserting A as a justification for inserting B, it's intrinsically doing something that it sensitive to concurrency. I understand that Ian --- and Kevin, and Thomas Munro --- would like that subtransaction to fail with serialization_failure rather than a unique_violation, and I previously argued that the change was fine but shouldn't be back-patched since it might break things for existing users. But people are continuing to show up and say "hey, this is broken", and now Kevin's chosen to back-patch, and I'm not going to kick up a fuss about that. After all, there's a growing number of people complaining about the same thing and saying it's a bug, so I guess it's a bug! But even after that fix, at the least, you'll still be able to demonstrate the same problem by trapping serialization_failure rather than unique_constraint. And even if you decree that trapping serialization_failure is off the table, I bet there are other ways for a supposedly-serializable transaction to sort of cheat, find out enough information about what's going on in the system to adjust its behavior, and then do something different based on that. And if that's possible and if a transaction finds a way to do it, then it's going to allow results not equivalent to any serial schedule. For example, imagine a transaction that queries pg_stat_activity or pg_locks and then makes decisions based on the contents thereof. That transaction is determined to behave different under concurrency than it does on an idle system, and even the ineluctable triumvirate of Kevin Grittner, Dan Ports, and Michael Cahill will not be able to prevent it from doing so. That's not a bug. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86/paging: Update paging_mark_dirty() to use mfn_t
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Julien Grall
The one use of paging_mark_dirty() in common/tmem shows that TMEM currently
wont compile for ARM.
I considered introducing a common prototype in include/xen/paging.h which can
be overriden by include/asm/paging.h, which would also allow the removal of
gnttab_mark_dirty() which seems to exist only to stub out other common uses.
If this is considered a good idea, I'd prefer to submit a separate patch than
to merge it into this one.
---
xen/arch/x86/debug.c | 2 +-
xen/arch/x86/hvm/hvm.c| 12 ++--
xen/arch/x86/hvm/ioreq.c | 2 +-
xen/arch/x86/mm.c | 16
xen/arch/x86/mm/guest_walk.c | 8
xen/arch/x86/mm/mem_sharing.c | 2 +-
xen/arch/x86/mm/p2m-pod.c | 2 +-
xen/arch/x86/mm/paging.c | 5 +
xen/arch/x86/mm/shadow/common.c | 6 +++---
xen/arch/x86/mm/shadow/multi.c| 2 +-
xen/common/tmem_xen.c | 2 +-
xen/include/asm-x86/grant_table.h | 2 +-
xen/include/asm-x86/paging.h | 2 +-
13 files changed, 30 insertions(+), 33 deletions(-)
diff --git a/xen/arch/x86/debug.c b/xen/arch/x86/debug.c
index 3030022..259b8c4 100644
--- a/xen/arch/x86/debug.c
+++ b/xen/arch/x86/debug.c
@@ -181,7 +181,7 @@ unsigned int dbg_rw_guest_mem(struct domain *dp, void *
__user gaddr,
if ( toaddr )
{
copy_from_user(va, buf, pagecnt);/* va = buf */
-paging_mark_dirty(dp, mfn_x(mfn));
+paging_mark_dirty(dp, mfn);
}
else
{
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 61f5029..a589b17 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1923,7 +1923,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long
gla,
*/
if ( npfec.write_access )
{
-paging_mark_dirty(currd, mfn_x(mfn));
+paging_mark_dirty(currd, mfn);
/*
* If p2m is really an altp2m, unlock here to avoid lock ordering
* violation when the change below is propagated from host p2m.
@@ -2613,7 +2613,7 @@ static void *_hvm_map_guest_frame(unsigned long gfn,
bool_t permanent,
if ( unlikely(p2m_is_discard_write(p2mt)) )
*writable = 0;
else if ( !permanent )
-paging_mark_dirty(d, page_to_mfn(page));
+paging_mark_dirty(d, _mfn(page_to_mfn(page)));
}
if ( !permanent )
@@ -2676,7 +2676,7 @@ void hvm_unmap_guest_frame(void *p, bool_t permanent)
list_for_each_entry(track, &d->arch.hvm_domain.write_map.list, list)
if ( track->page == page )
{
-paging_mark_dirty(d, mfn);
+paging_mark_dirty(d, _mfn(mfn));
list_del(&track->list);
xfree(track);
break;
@@ -2693,7 +2693,7 @@ void hvm_mapped_guest_frames_mark_dirty(struct domain *d)
spin_lock(&d->arch.hvm_domain.write_map.lock);
list_for_each_entry(track, &d->arch.hvm_domain.write_map.list, list)
-paging_mark_dirty(d, page_to_mfn(track->page));
+paging_mark_dirty(d, _mfn(page_to_mfn(track->page)));
spin_unlock(&d->arch.hvm_domain.write_map.lock);
}
@@ -3211,7 +3211,7 @@ static enum hvm_copy_result __hvm_copy(
memcpy(p, buf, count);
else
memset(p, 0, count);
-paging_mark_dirty(curr->domain, page_to_mfn(page));
+paging_mark_dirty(curr->domain, _mfn(page_to_mfn(page)));
}
}
else
@@ -5799,7 +5799,7 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
if ( page )
{
-paging_mark_dirty(d, page_to_mfn(page));
+paging_mark_dirty(d, _mfn(page_to_mfn(page)));
/* These are most probably not page tables any more */
/* don't take a long time and don't die either */
sh_remove_shadows(d, _mfn(page_to_mfn(page)), 1, 0);
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 88071ab..e1123dc 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -282,7 +282,7 @@ static int hvm_add_ioreq_gmfn(
rc = guest_physmap_add_page(d, _gfn(iorp->gmfn),
_mfn(page_to_mfn(iorp->page)), 0);
if ( rc == 0 )
-paging_mark_dirty(d, page_to_mfn(iorp->page));
+paging_mark_dirty(d, _mfn(page_to_mfn(iorp->page)));
return rc;
}
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c5dd6f2..24a5211 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2251,7 +2251,7 @@ static int alloc_page_type(struct page_info *page,
unsigned long type,
[Xen-devel] [PATCH 2/2] x86/paging: Rename paging_mark_pfn_dirty() and use pfn_t
paging_mark_gfn_dirty() actually takes a pfn, even by paramter name. Rename
the function and alter the type to pfn_t to match.
Push pfn_t into the LOGDIRTY_IDX() macros, and clean up a couple of local
variable types in paging_mark_pfn_dirty().
Leave an explicit comment in vmx_vcpu_flush_pml_buffer() when we intentally
perform a straight conversion from gfn to pfn.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vmcs.c | 4 +++-
xen/arch/x86/mm/paging.c | 26 +-
xen/include/asm-x86/paging.h | 10 +-
3 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 0995496..5db5fea 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1484,7 +1484,9 @@ void vmx_vcpu_flush_pml_buffer(struct vcpu *v)
* is extremely difficult to debug.
*/
p2m_change_type_one(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
-paging_mark_gfn_dirty(v->domain, gfn);
+
+/* HVM guest: pfn == gfn */
+paging_mark_pfn_dirty(v->domain, _pfn(gfn));
}
unmap_domain_page(pml_buf);
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index 3a66098..0f3d885 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -265,25 +265,25 @@ static int paging_log_dirty_disable(struct domain *d,
bool_t resuming)
}
/* Mark a page as dirty, with taking guest pfn as parameter */
-void paging_mark_gfn_dirty(struct domain *d, unsigned long pfn)
+void paging_mark_pfn_dirty(struct domain *d, pfn_t pfn)
{
-int changed;
+bool changed;
mfn_t mfn, *l4, *l3, *l2;
unsigned long *l1;
-int i1, i2, i3, i4;
+unsigned int i1, i2, i3, i4;
if ( !paging_mode_log_dirty(d) )
return;
/* Shared MFNs should NEVER be marked dirty */
-BUG_ON(SHARED_M2P(pfn));
+BUG_ON(SHARED_M2P(pfn_x(pfn)));
/*
* Values with the MSB set denote MFNs that aren't really part of the
* domain's pseudo-physical memory map (e.g., the shared info frame).
* Nothing to do here...
*/
-if ( unlikely(!VALID_M2P(pfn)) )
+if ( unlikely(!VALID_M2P(pfn_x(pfn))) )
return;
i1 = L1_LOGDIRTY_IDX(pfn);
@@ -331,8 +331,8 @@ void paging_mark_gfn_dirty(struct domain *d, unsigned long
pfn)
if ( changed )
{
PAGING_DEBUG(LOGDIRTY,
- "marked mfn %" PRI_mfn " (pfn=%lx), dom %d\n",
- mfn_x(mfn), pfn, d->domain_id);
+ "marked mfn %" PRI_mfn " (pfn %" PRI_pfn "), dom %d\n",
+ mfn_x(mfn), pfn_x(pfn), d->domain_id);
d->arch.paging.log_dirty.dirty_count++;
}
@@ -345,23 +345,23 @@ void paging_mark_gfn_dirty(struct domain *d, unsigned
long pfn)
/* Mark a page as dirty */
void paging_mark_dirty(struct domain *d, mfn_t gmfn)
{
-unsigned long pfn;
+pfn_t pfn;
if ( !paging_mode_log_dirty(d) || !mfn_valid(gmfn) ||
page_get_owner(mfn_to_page(gmfn)) != d )
return;
/* We /really/ mean PFN here, even for non-translated guests. */
-pfn = get_gpfn_from_mfn(mfn_x(gmfn));
+pfn = _pfn(get_gpfn_from_mfn(mfn_x(gmfn)));
-paging_mark_gfn_dirty(d, pfn);
+paging_mark_pfn_dirty(d, pfn);
}
/* Is this guest page dirty? */
int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn)
{
-unsigned long pfn;
+pfn_t pfn;
mfn_t mfn, *l4, *l3, *l2;
unsigned long *l1;
int rv;
@@ -370,9 +370,9 @@ int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn)
ASSERT(paging_mode_log_dirty(d));
/* We /really/ mean PFN here, even for non-translated guests. */
-pfn = get_gpfn_from_mfn(mfn_x(gmfn));
+pfn = _pfn(get_gpfn_from_mfn(mfn_x(gmfn)));
/* Shared pages are always read-only; invalid pages can't be dirty. */
-if ( unlikely(SHARED_M2P(pfn) || !VALID_M2P(pfn)) )
+if ( unlikely(SHARED_M2P(pfn_x(pfn)) || !VALID_M2P(pfn_x(pfn))) )
return 0;
mfn = d->arch.paging.log_dirty.top;
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index 63e3867..cec6bfd 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -159,7 +159,7 @@ void paging_log_dirty_init(struct domain *d,
/* mark a page as dirty */
void paging_mark_dirty(struct domain *d, mfn_t gmfn);
/* mark a page as dirty with taking guest pfn as parameter */
-void paging_mark_gfn_dirty(struct domain *d, unsigned long pfn);
+void paging_mark_pfn_dirty(struct domain *d, pfn_t pfn);
/* is this guest page dirty?
* This is called from inside paging code, with the paging lock held. */
@@ -175,12 +175,12 @@ int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn);
* TODO2: Abstract out the radix-tree mechanics?
*/
#define LOGDIRTY_NODE_ENTRIES (1 << PAGETABLE_ORDER)
-#define L1_LOGDIRTY_IDX(pfn) ((pfn) & ((1 << (P
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]
On Wed, Dec 14, 2016 at 12:44 AM, Robert Haas wrote: > On Tue, Dec 13, 2016 at 1:00 PM, Ian Jackson > wrote: > Saying that a set of transactions are serializable is equivalent to > the statement that there is some serial order of execution which would > have produced results equivalent to the actual results. That is, > there must be at least one schedule (T1, ..., Tn) such that running > the transactions one after another in that order would have produced > the same results that were obtained by running them concurrently. > Any transactions that roll back whether due to serialization anomalies > or manual user intervention or any other reason are not part of the > schedule, which considers only successfully committed transactions. > The rolled-back transactions effectively didn't happen, and > serializability as a concept makes no claim about the behavior of such > transactions. That's not a PostgreSQL thing: that's database theory. Right. That said, with S2PL's reliance on blocking, it can provide certain guarantees that are not required by the SQL standard nor by normal definitions of serializable transactions. (1) The effective order of execution will match commit order of successfully committed transactions. Both the SQL standard and the most definitions of serializable transactions merely require that there is *some* order of transactions which provides the same effects as having run the transactions one at a time in that order. (2) Even transactions terminated to resolve deadlocks never show serialization anomalies before being canceled. S2PL was the most common technique for implementing serializable transactions for a long time, and some have come to think that its guarantees should always be provided. The problem is that in most common workloads S2PL performs far worse than some other techniques, including the SSI technique used by PostgreSQL, even when the need to discard results from failed transactions is considered. Essentially, the position Ian has been taking is that PostgreSQL should provide the guarantee of (2) above. As far as I can see, that would require using S2PL -- something the community ripped out of PostgreSQL because of its horrible performance and has refused to consider restoring (for good reason, IMO). > However, in practice, the scenario that you mention should generally > work fine in PostgreSQL, I think. If T performed any writes, the > rollback throws them away, so imagine removing the actual T from the > mix and replacing it with a substitute version T' which performs the > same reads but no writes and then tries to COMMIT where T tried to > ROLLBACK. T' will succeed, because we never roll back a read-only > transaction at commit time. Huh, I had to think about that for a minute, but you are right about never rolling back a read-only transaction at commit time (except possibly for a prepared transaction -- I would have to look at that more closely). The reason is that to have a serialization failure under SSI we must have a "dangerous structure" (of a pivot (Tpivot) with both a rw-dependency in (Tin) and a rw-dependency out (Tout)) and Tout must have committed (and committed first). If Tpivot is still active, we will cancel it, because Tin, if it were to be canceled and perform an immediate retry, could hit the exact same problem, and be canceled again based on conflicts with the exact same other transactions. We don't want to burn resources repeating transactions with no progress made. So the only time the read-only transaction can be canceled is when Tout and Tpivot are running concurrently, Tout commits, Tpivot develops a rw-dependency to Tout (either before or after the commit of Tout), Tin starts (after the commit of Tout), Tpivot commits before Tin develops a rw-dependency with it (otherwise Tpivot would be the one canceled), and then Tin develops a rw-dependency to Tpivot. That dependency should be recognized when it is developed, causing Tin to be canceled -- so the commit of Tin should never get the serialization failure. > If it were to fail, it would have to fail *while performing one > of the reads*, not later. Yeah, that's the concise statement of what my lengthy explanation above proves. ;-) > But imagine a hypothetical database system in which anomalies are > never detected until commit time. We somehow track the global > must-happen-before graph and refuse the commit of any transaction > which will create a cycle. You have just described optimistic concurrency control (OCC), which has been used, although not in any really popular DBMS systems I can think of. It certainly has enjoyed a resurgence in some ORMs, though -- implemented outside the DBMS. > Let's also suppose that this system uses > snapshots to implement MVCC. In such a system, read-only transactions > will sometimes fail at commit time if they've seen a view of the world > that is inconsistent with the only remaining possible serial > schedules. For example, su
[Xen-devel] [PATCH v2] x86/traps: Correct overly-general assertion introduced in c/s d5c251c
The assertion about guest paging mode must only apply to guest pagefaults, as
should the later call to paging_fault().
This ASSERT() accidentally also trips if Xen takes a pagefault when in HVM
context, such as a copy_to_user() failure in the shadow pagetable code.
Merge the ASSERT() into the later paging_fault() callsite, prediating
everything on guest_mode() to start with.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* Avoid calling paging_fault() for hypervisor pagefaults.
---
xen/arch/x86/traps.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 2d79ee0..7f28d0a 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1797,10 +1797,6 @@ static int fixup_page_fault(unsigned long addr, struct
cpu_user_regs *regs)
if ( in_irq() || !(regs->eflags & X86_EFLAGS_IF) )
return 0;
-/* Logdirty mode is the only expected paging mode for PV guests. */
-if ( paging_mode_enabled(d) )
-ASSERT(paging_mode_only_log_dirty(d));
-
if ( !(regs->error_code & PFEC_page_present) &&
(pagefault_by_memadd(addr, regs)) )
return handle_memadd_fault(addr, regs);
@@ -1831,10 +1827,17 @@ static int fixup_page_fault(unsigned long addr, struct
cpu_user_regs *regs)
return EXCRET_fault_fixed;
}
-/* Logdirty guests call back into the paging code to update shadows. */
-if ( paging_mode_log_dirty(d) )
+/*
+ * Logdirty guests call back into the paging code to update shadows. We
+ * don't expect any other paging modes with PV guests.
+ */
+if ( guest_mode(regs) && paging_mode_enabled(d) )
{
-int ret = paging_fault(addr, regs);
+int ret;
+
+ASSERT(paging_mode_only_log_dirty(d));
+
+ret = paging_fault(addr, regs);
if ( ret == EXCRET_fault_fixed )
trace_trap_two_addr(TRC_PV_PAGING_FIXUP, regs->eip, addr);
return ret;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]
Robert Haas wrote: > I have not read any database literature on the interaction of > serializability with subtransactions. This seems very thorny. > Suppose T1 reads A and B and updates A -> A' while concurrently T2 > reads A and B and updates B -> B'. This is obviously not > serializable; if either transaction had executed before the other in a > serial schedule, the second transaction in the schedule would have had > to have seen (A, B') or (A', B) rather than (A, B), but that's not > what happened. But what if each of T1 and T2 did the reads in a > subtransaction, rolled it back, and then did the write in the main > transaction and committed? The database system has two options. > First, it could assume that the toplevel transaction may have relied > on the results of the aborted subtransaction. But if it does that, > then any serialization failure which afflicts a subtransaction must > necessarily also kill the main transaction, which seems pedantic and > unhelpful. If you'd wanted the toplevel transaction to be killled, > you wouldn't have used a subtransaction, right? Second, it could > assume that the toplevel transaction in no way relied on or used the > values obtained from the aborted subtransaction. However, that > defeats the whole purpose of having subtransactions in the first > place. What's the point of being able to start subtransactions if you > can't roll them back and then decide to do something else instead? It > seems to me that what the database system should do is make that > second assumption, and what the user should do is understand that to > the degree that transactions depend on the results of aborted > subtransactions, there may be serialization anomalies that go > undetected. Actually, Ian's sample transaction is even more malicious, because the problem is not caused by reads within the aborted subtransaction -- the cached-in-app reads occured *before* the subtransaction started in the first place. I think saving a count(*) across a possibly-failed insertion on the same table is wrong. I can't blame the database for the behavior. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/traps: Correct overly-general assertion introduced in c/s d5c251c
On 14/12/16 12:52, Jan Beulich wrote: On 14.12.16 at 12:35, wrote: >> The assertion about guest paging mode must only apply to guest pagefaults. >> >> This ASSERT() accidentally also trips if Xen takes a pagefault when in HVM >> context, such as a copy_to_user() failure in the shadow pagetable code. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich > > But isn't the other piece the original patch touched in the same > function suffering a similar problem? I.e. can't this mis-trigger > when dealing with a page fault in Xen while in the context of a > HVM guest in log-dirty mode, and hence needs re-adding the > !paging_mode_external() check (or alternatively using > paging_mode_only_log_dirty() instead of paging_mode_log_dirty())? Good point, although it should still be guest_mode() to be more clearly avoiding the hypervisor case. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH] vvmx: replace vmreturn() by vmsucceed() and vmfail*()
On 12/14/16 11:55 +, Andrew Cooper wrote: On 14/12/16 11:29, Haozhong Zhang wrote: Replace vmreturn() by vmsucceed(), vmfail(), vmfail_valid() and vmfail_invalid(), which are consistent to the pseudo code on Intel SDM, and allow to return VM instruction error numbers to L1 hypervisor. Signed-off-by: Haozhong Zhang --- * This patch is based on my patchset "[PATCH v2 0/4] vvmx: fix L1 vmxon". * I'm not sure whether this patch by itself makes sense or should be sent with additional bugfix patches, so I tag it as RFC. Explanation: besides returning error numbers, this patch does not fix other bugs in the individual nvmx_handle_*() function, so the error numbers used (especially) for L1 vmclear, vmptrld and vmwrite are still inconsistent to Intel SDM, or even incorrect. If I were doing this work, I would purposefully split an API improvement like this into a separate patch(s) as bugfixes to do with the use of the API. I think a change like this is fine even without the other bugfixes, as it is still an improvement. (Of course, if you have time, it would certainly be better to do the other bugfixes as well). Bugfixes for VMX instructions are already on my TODO list, though they are of lower priority than my other tasks. Haozhong As for the patch itself, LGTM. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/emul: Simplfy L{ES, DS, SS, FS, GS} handling
On 14/12/16 13:34, Jan Beulich wrote:
On 14.12.16 at 12:20, wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -2765,6 +2765,7 @@ x86_emulate(
>> if ( mode_64bit() && (op_bytes == 4) )
>> op_bytes = 8;
>> seg = (b >> 3) & 7;
>> +ASSERT(is_x86_user_segment(seg));
> Kind of pointless, don't you think? It's guaranteed by the set of
> case statements ahead of here.
Well, I didn't think so at the time. All other uses either have seg
used from a constant, or has previously had a user check in a
generate_exception_if() clause.
>
>> @@ -3393,25 +3394,32 @@ x86_emulate(
>> _regs.eip = dst.val;
>> break;
>>
>> -case 0xc4: /* les */ {
>> +case 0xc4: /* les */
>> +case 0xc5: /* lds */
>> +{
>> unsigned long sel;
> Since you're touching this anyway, and since you're eliminating the
> use of dst.val here, may I ask that you eliminate this local variable
> at once, using dst.val instead?
Good point.
>
>> -dst.val = x86_seg_es;
>> -les: /* dst.val identifies the segment */
>> -generate_exception_if(mode_64bit() && !ext, EXC_UD);
>> +
>> +generate_exception_if(mode_64bit(), EXC_UD);
>> +seg = (b & 1) * 3; /* es = 0, ds = 3 */
>> +goto les;
>> +
>> +case X86EMUL_OPC(0x0f, 0xb2): /* lss */
>> +case X86EMUL_OPC(0x0f, 0xb4): /* lfs */
>> +case X86EMUL_OPC(0x0f, 0xb5): /* lgs */
>> +seg = b & 7;
>> +
>> +les:
> My general line of thinking about where to place case labels was
> - next to each other for opcodes sharing all of their code, or allowing
> plain fall-through,
> - in numeric order when plain fall-through is not possible.
> Hence I'd prefer if the three could stay at the place where LSS was.
Ok.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: support {RD,WR}{F,G}SBASE
On 14/12/16 13:39, Jan Beulich wrote:
On 14.12.16 at 14:28, wrote:
>> On 14/12/16 13:18, Jan Beulich wrote:
>> On 14.12.16 at 13:36, wrote:
On 14/12/16 09:37, Jan Beulich wrote:
> @@ -5205,6 +5206,44 @@ x86_emulate(
> }
> break;
>
> +case X86EMUL_OPC_F3(0x0f, 0xae): /* Grp15 */
> +{
> +unsigned long cr4;
> +
> +fail_if(modrm_mod != 3);
This should surely be an explicit #UD? The only issue is that we don't
yet implement Grp15/F3 instructions with memory operands (as there are
none yet defined)?
>>> If there weren't any, I probably would have used #UD here. But
>>> there are - ptwrite is even in the normal SDM already (but it looks
>>> to be missing from the opcode map).
>> I find that the opcode maps are consistently out of date.
>>
>> However, I don't understand why you have chosen to avoid the #UD. #UD
>> is the appropriate action for an opcode which isn't implemented.
> I don't think we should raise #UD knowingly for the wrong reason.
> Hence my plan was to go through all fail_if()-s once we are at a
> point where we consider the emulator complete enough, but keep
> using fail_if() vs #UD to distinguish cases where we know of gaps
> vs an encoding being undefined in up-to-date docs. While I guess
> we don't always match this model at present, that was at least
> what I have been trying to follow in all my recent work.
Hmm.
I had considered at one point to have X86EMUL_NOT_IMPLEMENTED which was
separate from X86EMUL_UNHANDLEABLE, as they are subtly different.
NOT_IMPLEMENTED means "everything else was fine, but I don't know how to
do that", whereas UNHANDLEABLE is "something went wrong trying to do
that", and is typically used for missing hooks or problems in lower levels.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.9 Development Update
Hi Stefano On 09.12.16 21:01, Stefano Stabellini wrote: > On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote: >> On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote: >>> On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote: >> Should we have a section on new PV drivers? If so, I suggest to add: >> - Xen transport for 9pfs >> - PV Calls > Good idea. We could also include DRM and PV Sound (CC Oleksandr). > This is a great idea. Let me explain what we have and what the direction is: 1. Frontends which we already have, working, but need to refactor/cleanup: 1.1. PV sound 1.2. PV DRM 1.3. DISPL protocol, I will push v1 for review right after sndif done 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy via DRM Prime buffer sharing) 1.4. PV events not done, but we are considering [1]. If it fits and is maintained, then we'll probably stick to it, otherwise new PV will be created 2. Backends, for the above frontends already implemented: 2.1. A unified library for Xen backends (libxenbe) 2.2. DRM + Wayland 2.3. ALSA 2.4. Events not implemented yet All the above sources are available on *public* Github repos (I can provide links on request) and the intention is to upstream. >>> Please do post the links.. >> Please note these are all WIP: >> 1. Frontends >> https://github.com/andr2000?tab=repositories >> 2. Backends >> https://github.com/al1img?tab=repositories > Now, I don't want to sound pessimistic, but I thought I was being > audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really > think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL, > PV DRM frontends and backends, all by April? I would probably reduce the > list a bit. I am pretty sure we can finish sound and displ. DRM is a "stretch goal" I believe :) > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen: ARM: Support for mapping OperationRegion in ACPI ASL
On Tue, Dec 13, 2016 at 07:14:27PM -0600, Jiandi An wrote: > Hi Guys, > > Xen currently does not handle mapping of MMIO regions specified under > OperationRegion in ACPI ASL. OperationRegion is well defined in ACPI > specification. I'm seeking for architectural direction on adding support for > mapping OperationRegion. > > Some context here. Mapping of resources specificed under _CRS in ACPI is > handled by dom0 requesting Xen to map as platform devices are added. > https://lwn.net/Articles/674666/ provided service xen_map_device_mmio() in > dom0 to call Xen to map and it's done so by registering > xen_platform_notifier() platform bus driver. This covers the platform > devices. > > The OperationRegion access in dom0 is in acpica path. The following is a > stack of the code path where OperationRegion is parsed. > acpi_ex_system_memory_space_handler() gets the parsed address specified in > OperationRegion in ACPI and maps it then performs the memory read or write. > > acpi_ex_system_memory_space_handler+0x378/0x424 > acpi_ev_address_space_dispatch+0x294/0x310 > acpi_ex_access_region+0x3c0/0x468 > acpi_ex_field_datum_io+0x14c/0x380 > acpi_ex_extract_from_field+0xe8/0x2f4 > acpi_ex_read_data_from_field+0x330/0x38c > acpi_ex_resolve_node_to_value+0x310/0x3fc > acpi_ex_resolve_to_value+0x354/0x3e8 > acpi_ds_evaluate_name_path+0xa4/0x15c > acpi_ds_exec_end_op+0xbc/0x6c8 > acpi_ps_parse_loop+0x7ac/0x840 > acpi_ps_parse_aml+0x1c4/0x434 > acpi_ps_execute_method+0x1f0/0x2a0 > acpi_ns_evaluate+0x2e4/0x424 > acpi_ut_evaluate_object+0xb0/0x250 > acpi_ut_execute_STA+0xb0/0x164 > acpi_ns_init_one_device+0xac/0x250 > acpi_ns_walk_namespace+0x108/0x254 > acpi_ns_initialize_devices+0x274/0x35c > acpi_initialize_objects+0x90/0xf0 > acpi_init+0xc0/0x30c > do_one_initcall+0x44/0x138 > kernel_init_freeable+0x148/0x1ec > kernel_init+0x18/0x108 > > The workaround in testing for handling OperationRegion I did is to call > xen_map_device_mmio() to map the resource specificied in OperationRegion if > it's dom0 running under XEN in acpi_ex_system_memory_space_handler(). But > this is a fairly generic ACPI code path. Looking for achitectural suggestion > to properly handle OperationRegion for Xen on ARM. The ACPI code path obviously calls the underlaying OS code to map it. Could this path have an wrapper around it (so one could register different underlaying 'map_device_mmio' function calls)? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression due to "mm/swap.c: flush lru pvecs on compound page arrival"
On Wed 14-12-16 13:29:56, Ian Jackson wrote:
> osstest service owner writes ("[linux-3.18 bisection] complete
> test-amd64-amd64-xl-qemut-win7-amd64"):
> > *** Found and reproduced problem changeset ***
> >
> > Bug is in tree: linux
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > Bug introduced: a2d8c514753276394d68414f563591f174ef86cb
> > Bug not present: 8f620446135b64ca6f96cf32066a76d64e79a388
> > Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103315/
> >
> > commit a2d8c514753276394d68414f563591f174ef86cb
> > Author: Lukasz Odzioba
> > Date: Fri Jun 24 14:50:01 2016 -0700
> >
> > mm/swap.c: flush lru pvecs on compound page arrival
>
> This commit breaks the test "test-amd64-amd64-xl-qemut-win7-amd64" in
> the Xen Project CI system.
Could you be more specific about the regression please?
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: support {RD,WR}{F,G}SBASE
>>> On 14.12.16 at 14:28, wrote:
> On 14/12/16 13:18, Jan Beulich wrote:
> On 14.12.16 at 13:36, wrote:
>>> On 14/12/16 09:37, Jan Beulich wrote:
@@ -5205,6 +5206,44 @@ x86_emulate(
}
break;
+case X86EMUL_OPC_F3(0x0f, 0xae): /* Grp15 */
+{
+unsigned long cr4;
+
+fail_if(modrm_mod != 3);
>>> This should surely be an explicit #UD? The only issue is that we don't
>>> yet implement Grp15/F3 instructions with memory operands (as there are
>>> none yet defined)?
>> If there weren't any, I probably would have used #UD here. But
>> there are - ptwrite is even in the normal SDM already (but it looks
>> to be missing from the opcode map).
>
> I find that the opcode maps are consistently out of date.
>
> However, I don't understand why you have chosen to avoid the #UD. #UD
> is the appropriate action for an opcode which isn't implemented.
I don't think we should raise #UD knowingly for the wrong reason.
Hence my plan was to go through all fail_if()-s once we are at a
point where we consider the emulator complete enough, but keep
using fail_if() vs #UD to distinguish cases where we know of gaps
vs an encoding being undefined in up-to-date docs. While I guess
we don't always match this model at present, that was at least
what I have been trying to follow in all my recent work.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/emul: Simplfy L{ES, DS, SS, FS, GS} handling
>>> On 14.12.16 at 12:20, wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -2765,6 +2765,7 @@ x86_emulate(
> if ( mode_64bit() && (op_bytes == 4) )
> op_bytes = 8;
> seg = (b >> 3) & 7;
> +ASSERT(is_x86_user_segment(seg));
Kind of pointless, don't you think? It's guaranteed by the set of
case statements ahead of here.
> @@ -3393,25 +3394,32 @@ x86_emulate(
> _regs.eip = dst.val;
> break;
>
> -case 0xc4: /* les */ {
> +case 0xc4: /* les */
> +case 0xc5: /* lds */
> +{
> unsigned long sel;
Since you're touching this anyway, and since you're eliminating the
use of dst.val here, may I ask that you eliminate this local variable
at once, using dst.val instead?
> -dst.val = x86_seg_es;
> -les: /* dst.val identifies the segment */
> -generate_exception_if(mode_64bit() && !ext, EXC_UD);
> +
> +generate_exception_if(mode_64bit(), EXC_UD);
> +seg = (b & 1) * 3; /* es = 0, ds = 3 */
> +goto les;
> +
> +case X86EMUL_OPC(0x0f, 0xb2): /* lss */
> +case X86EMUL_OPC(0x0f, 0xb4): /* lfs */
> +case X86EMUL_OPC(0x0f, 0xb5): /* lgs */
> +seg = b & 7;
> +
> +les:
My general line of thinking about where to place case labels was
- next to each other for opcodes sharing all of their code, or allowing
plain fall-through,
- in numeric order when plain fall-through is not possible.
Hence I'd prefer if the three could stay at the place where LSS was.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: Use ACPI reboot method for Dell OptiPlex 9020
On 14/12/16 13:21, Jan Beulich wrote: On 14.12.16 at 14:15, wrote: >> On 14/12/16 12:58, Jan Beulich wrote: >> On 14.12.16 at 12:12, wrote: When EFI booting the Dell OptiPlex 9020, it sometimes GP faults in the EFI runtime instead of rebooting. >>> Has it been understood what the #GP is due to? I.e. is it namely >>> not because of a mis-aligned SSE instruction memory reference? >> (XEN) [ 349.551011] Hardware Dom0 shutdown: rebooting machine >> (XEN) [ 349.553668] APIC error on CPU0: 40(00) >> (XEN) [ 349.553675] [ Xen-4.7.0-xs128737-d x86_64 debug=y Not >> tainted ] >> (XEN) [ 349.553676] CPU:0 >> (XEN) [ 349.553677] RIP:e008:[] db7aa368 >> (XEN) [ 349.553678] RFLAGS: 00010246 CONTEXT: hypervisor >> (XEN) [ 349.553680] rax: d48595e0 rbx: rcx: >> 5a5a5a5a >> (XEN) [ 349.553681] rdx: 1830 rsi: rdi: >> 8300ded37bb8 >> (XEN) [ 349.553682] rbp: 0021 rsp: 8300ded37b68 r8: >> >> (XEN) [ 349.553682] r9: 0001 r10: 0004 r11: >> 0200 >> (XEN) [ 349.553683] r12: r13: 1830 r14: >> 0065 >> (XEN) [ 349.553684] r15: 0010 cr0: 80050033 cr4: >> 001526e0 >> (XEN) [ 349.553685] cr3: 00040df7c000 cr2: 7f7186aa1a40 >> (XEN) [ 349.553686] ds: 002b es: 002b fs: gs: ss: e010 >> cs: e008 >> (XEN) [ 349.553687] Xen code around (db7aa368): >> (XEN) [ 349.553688] 08 00 00 b9 5a 5a 5a 5a 50 18 48 8b d8 48 83 f8 >> 1f >> 74 0f 48 8b 15 dd >> (XEN) [ 349.553692] Xen stack trace from rsp=8300ded37b68: >> (XEN) [ 349.553693]0700ded37bb8 80022023 83041b92b914 >> 83041b80 >> (XEN) [ 349.553694] db79f348 >> >> (XEN) [ 349.553696] 000d >> db7ff870 >> (XEN) [ 349.553697] 005162b3bf76 >> >> (XEN) [ 349.553698]7cff212c83e7 82d080244f57 0010 >> db7fe671 >> (XEN) [ 349.553699]8300ded37c38 0206 ded28000 >> >> (XEN) [ 349.553701] db7e0311 >> >> (XEN) [ 349.553702] 080f >> >> (XEN) [ 349.553703]00040df7c000 82d080101242 ded28000 >> 8300ded37ca8 >> (XEN) [ 349.553704]82d080352b00 8300ded37ca0 >> fffe >> (XEN) [ 349.553706]8300ded37cf8 82d0801956e7 8300ded37cd0 >> 0046 >> (XEN) [ 349.553707]8300dee1d000 >> 8300ded37dd8 >> (XEN) [ 349.553709]00fb 005162b3bf76 8300ded37d08 >> 82d080195785 >> (XEN) [ 349.553710]8300ded37d28 82d080137482 0016 >> >> (XEN) [ 349.553711]8300ded37d38 82d080195de7 8300ded37dc8 >> 82d08017532c >> (XEN) [ 349.553713] >> >> (XEN) [ 349.553714]83040df78c50 8300ded97000 8000dee1d000 >> >> (XEN) [ 349.553715] 83040defc000 8300ded37dc0 >> 005162dd573d >> (XEN) [ 349.553717]83040df77010 83040df770e8 005162b3bf76 >> 0010 >> (XEN) [ 349.553718]7cff212c8207 82d080244f57 0010 >> 005162b3bf76 >> (XEN) [ 349.553720] Xen call trace: >> (XEN) [ 349.553721][ ] db7aa368 >> (XEN) [ 349.553721] >> (XEN) [ 349.553722] >> (XEN) [ 349.553723] >> (XEN) [ 349.553723] Panic on CPU 0: >> (XEN) [ 349.553724] GENERAL PROTECTION FAULT >> (XEN) [ 349.553724] [error_code=] >> (XEN) [ 349.553725] >> (XEN) [ 349.553725] >> (XEN) [ 349.553726] Reboot in five seconds... >> (XEN) [ 349.553727] Executing kexec image on cpu0 >> (XEN) [ 349.553728] Shot down all CPUs >> >> >> This is caused by callq *0x18(%rax) >> >> The only #GP fault to be have is if the end of that pointer is >> non-canonical. > Thanks for clarifying - I'm fine with the patch then. Ok - I will queue it. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] megaraid_sas regression in linux-3.18 [and 1 more messages]
alexander.le...@verizon.com writes ("RE: megaraid_sas regression in linux-3.18
[and 1 more messages]"):
> Added 5e5ec1759dd6 to the 3.18 queue, thanks!
How often does this queue get flushed ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] Regression due to "mm/swap.c: flush lru pvecs on compound page arrival"
osstest service owner writes ("[linux-3.18 bisection] complete
test-amd64-amd64-xl-qemut-win7-amd64"):
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Bug introduced: a2d8c514753276394d68414f563591f174ef86cb
> Bug not present: 8f620446135b64ca6f96cf32066a76d64e79a388
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103315/
>
> commit a2d8c514753276394d68414f563591f174ef86cb
> Author: Lukasz Odzioba
> Date: Fri Jun 24 14:50:01 2016 -0700
>
> mm/swap.c: flush lru pvecs on compound page arrival
This commit breaks the test "test-amd64-amd64-xl-qemut-win7-amd64" in
the Xen Project CI system.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: support {RD,WR}{F,G}SBASE
On 14/12/16 13:18, Jan Beulich wrote:
On 14.12.16 at 13:36, wrote:
>> On 14/12/16 09:37, Jan Beulich wrote:
>>> @@ -5205,6 +5206,44 @@ x86_emulate(
>>> }
>>> break;
>>>
>>> +case X86EMUL_OPC_F3(0x0f, 0xae): /* Grp15 */
>>> +{
>>> +unsigned long cr4;
>>> +
>>> +fail_if(modrm_mod != 3);
>> This should surely be an explicit #UD? The only issue is that we don't
>> yet implement Grp15/F3 instructions with memory operands (as there are
>> none yet defined)?
> If there weren't any, I probably would have used #UD here. But
> there are - ptwrite is even in the normal SDM already (but it looks
> to be missing from the opcode map).
I find that the opcode maps are consistently out of date.
However, I don't understand why you have chosen to avoid the #UD. #UD
is the appropriate action for an opcode which isn't implemented.
>
>>> +if ( (rc = ops->read_segment(modrm_reg & 1 ? x86_seg_gs :
>>> x86_seg_fs,
>>> + &sreg, ctxt)) != X86EMUL_OKAY )
>>> +goto done;
>>> +dst.reg = decode_register(modrm_rm, &_regs, 0);
>>> +if ( !(modrm_reg & 2) )
>>> +{
>>> +/* rd{f,g}sbase */
>>> +dst.type = OP_REG;
>>> +dst.bytes = (op_bytes == 8) ? 8 : 4;
>>> +dst.val = sreg.base;
>>> +break;
>>> +}
>>> +/* wr{f,g}sbase */
>>> +if ( op_bytes == 8 )
>>> +{
>>> +sreg.base = *dst.reg;
>>> +generate_exception_if(!is_canonical_address(sreg.base),
>>> EXC_GP, 0);
>>> +}
>>> +else
>>> +sreg.base = (uint32_t)*dst.reg;
>>> +fail_if(!ops->write_segment);
>>> +if ( (rc = ops->write_segment(modrm_reg & 1 ? x86_seg_gs :
>>> x86_seg_fs,
>>> + &sreg, ctxt)) != X86EMUL_OKAY )
>>> +goto done;
>> Can I talk you into using a switch statement for this? I know it would
>> only have two or four cases, it but read path exiting midway through
>> took me a while to spot even though I was expecting to find it.
> I was specifically trying to avoid another nested switch here. Would
> it be sufficient if I just made the write path the "else" to that "if"?
Yeah - that is also ok.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation
On Fri, Dec 09, 2016 at 01:57:13PM +0100, Daniel Kiper wrote: > On Tue, Dec 06, 2016 at 11:52:48PM +0100, Daniel Kiper wrote: > > Hi, > > > > This updated patch series adds description of the Multiboot2 protocol new > > features and fixes some issues found here and there. > > > > It applies to multiboot2 branch in GRUB2 git tree. > > > > Here is short list of changes since v2: > > - new patches: 01, 02, > > - changed patches: 07. > > If there are no more objections then I will apply this patch series at > the beginning of next week. Applied! Happy reading... Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: support {RD,WR}{F,G}SBASE
>>> On 14.12.16 at 13:36, wrote:
> On 14/12/16 09:37, Jan Beulich wrote:
>> @@ -5205,6 +5206,44 @@ x86_emulate(
>> }
>> break;
>>
>> +case X86EMUL_OPC_F3(0x0f, 0xae): /* Grp15 */
>> +{
>> +unsigned long cr4;
>> +
>> +fail_if(modrm_mod != 3);
>
> This should surely be an explicit #UD? The only issue is that we don't
> yet implement Grp15/F3 instructions with memory operands (as there are
> none yet defined)?
If there weren't any, I probably would have used #UD here. But
there are - ptwrite is even in the normal SDM already (but it looks
to be missing from the opcode map).
>> +generate_exception_if((modrm_reg & 4) || !mode_64bit(), EXC_UD);
>> +fail_if(!ops->read_cr);
>> +if ( (rc = ops->read_cr(4, &cr4, ctxt)) != X86EMUL_OKAY )
>> +goto done;
>> +generate_exception_if(!(cr4 & CR4_FSGSBASE), EXC_UD);
>> +fail_if(!ops->read_segment);
>
> seg = modrm_reg & 1 ? x86_seg_gs : x86_seg_fs
>
> would avoid the repetition later for write_segment().
Will do.
>> +if ( (rc = ops->read_segment(modrm_reg & 1 ? x86_seg_gs :
>> x86_seg_fs,
>> + &sreg, ctxt)) != X86EMUL_OKAY )
>> +goto done;
>> +dst.reg = decode_register(modrm_rm, &_regs, 0);
>> +if ( !(modrm_reg & 2) )
>> +{
>> +/* rd{f,g}sbase */
>> +dst.type = OP_REG;
>> +dst.bytes = (op_bytes == 8) ? 8 : 4;
>> +dst.val = sreg.base;
>> +break;
>> +}
>> +/* wr{f,g}sbase */
>> +if ( op_bytes == 8 )
>> +{
>> +sreg.base = *dst.reg;
>> +generate_exception_if(!is_canonical_address(sreg.base), EXC_GP,
>> 0);
>> +}
>> +else
>> +sreg.base = (uint32_t)*dst.reg;
>> +fail_if(!ops->write_segment);
>> +if ( (rc = ops->write_segment(modrm_reg & 1 ? x86_seg_gs :
>> x86_seg_fs,
>> + &sreg, ctxt)) != X86EMUL_OKAY )
>> +goto done;
>
> Can I talk you into using a switch statement for this? I know it would
> only have two or four cases, it but read path exiting midway through
> took me a while to spot even though I was expecting to find it.
I was specifically trying to avoid another nested switch here. Would
it be sufficient if I just made the write path the "else" to that "if"?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH][XTF] don't require x32 support in binutils
On 14/12/16 13:10, Andrew Cooper wrote: > On 14/12/16 13:07, Jan Beulich wrote: >> Older binutils don't have this at all, and newer may not have it >> configured in. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Andrew Cooper , although > >> --- a/build/gen.mk >> +++ b/build/gen.mk >> @@ -40,6 +40,8 @@ install: install-each-env info.json >> @$(INSTALL_DIR) $(DESTDIR)$(xtftestdir)/$(NAME) >> $(INSTALL_DATA) info.json $(DESTDIR)$(xtftestdir)/$(NAME) >> >> +hvm64-format := $(firstword $(filter elf32-x86-64,$(shell $(OBJCOPY) >> --help)) elf32-i386) >> + >> define PERENV_build >> >> ifneq ($(1),hvm64) >> @@ -47,10 +49,10 @@ install: install-each-env info.json >> test-$(1)-$(NAME): $$(DEPS-$(1)) $$(link-$(1)) >> $$(LD) $$(LDFLAGS_$(1)) $$(DEPS-$(1)) -o $$@ >> else >> -# hvm64 needs linking normally, then converting to elf32-x86-64 >> +# hvm64 needs linking normally, then converting to elf32-x86-64 or >> elf32-i386 >> test-$(1)-$(NAME): $$(DEPS-$(1)) $$(link-$(1)) >> $$(LD) $$(LDFLAGS_$(1)) $$(DEPS-$(1)) -o $$@.tmp >> -$$(OBJCOPY) $$@.tmp -O elf32-x86-64 $$@ >> +$(OBJCOPY) $$@.tmp -O $(hvm64-format) $$@ > > This needs to stays as $(OBJCOPY) as this code gets eval()'d once > before running. Sorry - I meant $$(OBJCOPY) here. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: Use ACPI reboot method for Dell OptiPlex 9020
On 14/12/16 12:58, Jan Beulich wrote: On 14.12.16 at 12:12, wrote: >> When EFI booting the Dell OptiPlex 9020, it sometimes GP faults in the >> EFI runtime instead of rebooting. > Has it been understood what the #GP is due to? I.e. is it namely > not because of a mis-aligned SSE instruction memory reference? (XEN) [ 349.551011] Hardware Dom0 shutdown: rebooting machine (XEN) [ 349.553668] APIC error on CPU0: 40(00) (XEN) [ 349.553675] [ Xen-4.7.0-xs128737-d x86_64 debug=y Not tainted ] (XEN) [ 349.553676] CPU:0 (XEN) [ 349.553677] RIP:e008:[] db7aa368 (XEN) [ 349.553678] RFLAGS: 00010246 CONTEXT: hypervisor (XEN) [ 349.553680] rax: d48595e0 rbx: rcx: 5a5a5a5a (XEN) [ 349.553681] rdx: 1830 rsi: rdi: 8300ded37bb8 (XEN) [ 349.553682] rbp: 0021 rsp: 8300ded37b68 r8: (XEN) [ 349.553682] r9: 0001 r10: 0004 r11: 0200 (XEN) [ 349.553683] r12: r13: 1830 r14: 0065 (XEN) [ 349.553684] r15: 0010 cr0: 80050033 cr4: 001526e0 (XEN) [ 349.553685] cr3: 00040df7c000 cr2: 7f7186aa1a40 (XEN) [ 349.553686] ds: 002b es: 002b fs: gs: ss: e010 cs: e008 (XEN) [ 349.553687] Xen code around (db7aa368): (XEN) [ 349.553688] 08 00 00 b9 5a 5a 5a 5a 50 18 48 8b d8 48 83 f8 1f 74 0f 48 8b 15 dd (XEN) [ 349.553692] Xen stack trace from rsp=8300ded37b68: (XEN) [ 349.553693]0700ded37bb8 80022023 83041b92b914 83041b80 (XEN) [ 349.553694] db79f348 (XEN) [ 349.553696] 000d db7ff870 (XEN) [ 349.553697] 005162b3bf76 (XEN) [ 349.553698]7cff212c83e7 82d080244f57 0010 db7fe671 (XEN) [ 349.553699]8300ded37c38 0206 ded28000 (XEN) [ 349.553701] db7e0311 (XEN) [ 349.553702] 080f (XEN) [ 349.553703]00040df7c000 82d080101242 ded28000 8300ded37ca8 (XEN) [ 349.553704]82d080352b00 8300ded37ca0 fffe (XEN) [ 349.553706]8300ded37cf8 82d0801956e7 8300ded37cd0 0046 (XEN) [ 349.553707]8300dee1d000 8300ded37dd8 (XEN) [ 349.553709]00fb 005162b3bf76 8300ded37d08 82d080195785 (XEN) [ 349.553710]8300ded37d28 82d080137482 0016 (XEN) [ 349.553711]8300ded37d38 82d080195de7 8300ded37dc8 82d08017532c (XEN) [ 349.553713] (XEN) [ 349.553714]83040df78c50 8300ded97000 8000dee1d000 (XEN) [ 349.553715] 83040defc000 8300ded37dc0 005162dd573d (XEN) [ 349.553717]83040df77010 83040df770e8 005162b3bf76 0010 (XEN) [ 349.553718]7cff212c8207 82d080244f57 0010 005162b3bf76 (XEN) [ 349.553720] Xen call trace: (XEN) [ 349.553721][ ] db7aa368 (XEN) [ 349.553721] (XEN) [ 349.553722] (XEN) [ 349.553723] (XEN) [ 349.553723] Panic on CPU 0: (XEN) [ 349.553724] GENERAL PROTECTION FAULT (XEN) [ 349.553724] [error_code=] (XEN) [ 349.553725] (XEN) [ 349.553725] (XEN) [ 349.553726] Reboot in five seconds... (XEN) [ 349.553727] Executing kexec image on cpu0 (XEN) [ 349.553728] Shot down all CPUs This is caused by callq *0x18(%rax) The only #GP fault to be have is if the end of that pointer is non-canonical. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH][XTF] don't require x32 support in binutils
On 14/12/16 13:07, Jan Beulich wrote: > Older binutils don't have this at all, and newer may not have it > configured in. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper , although > > --- a/build/gen.mk > +++ b/build/gen.mk > @@ -40,6 +40,8 @@ install: install-each-env info.json > @$(INSTALL_DIR) $(DESTDIR)$(xtftestdir)/$(NAME) > $(INSTALL_DATA) info.json $(DESTDIR)$(xtftestdir)/$(NAME) > > +hvm64-format := $(firstword $(filter elf32-x86-64,$(shell $(OBJCOPY) > --help)) elf32-i386) > + > define PERENV_build > > ifneq ($(1),hvm64) > @@ -47,10 +49,10 @@ install: install-each-env info.json > test-$(1)-$(NAME): $$(DEPS-$(1)) $$(link-$(1)) > $$(LD) $$(LDFLAGS_$(1)) $$(DEPS-$(1)) -o $$@ > else > -# hvm64 needs linking normally, then converting to elf32-x86-64 > +# hvm64 needs linking normally, then converting to elf32-x86-64 or elf32-i386 > test-$(1)-$(NAME): $$(DEPS-$(1)) $$(link-$(1)) > $$(LD) $$(LDFLAGS_$(1)) $$(DEPS-$(1)) -o $$@.tmp > - $$(OBJCOPY) $$@.tmp -O elf32-x86-64 $$@ > + $(OBJCOPY) $$@.tmp -O $(hvm64-format) $$@ This needs to stays as $(OBJCOPY) as this code gets eval()'d once before running. > rm -f $$@.tmp > endif > > > > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH][XTF] don't require x32 support in binutils
Older binutils don't have this at all, and newer may not have it configured in. Signed-off-by: Jan Beulich --- a/build/gen.mk +++ b/build/gen.mk @@ -40,6 +40,8 @@ install: install-each-env info.json @$(INSTALL_DIR) $(DESTDIR)$(xtftestdir)/$(NAME) $(INSTALL_DATA) info.json $(DESTDIR)$(xtftestdir)/$(NAME) +hvm64-format := $(firstword $(filter elf32-x86-64,$(shell $(OBJCOPY) --help)) elf32-i386) + define PERENV_build ifneq ($(1),hvm64) @@ -47,10 +49,10 @@ install: install-each-env info.json test-$(1)-$(NAME): $$(DEPS-$(1)) $$(link-$(1)) $$(LD) $$(LDFLAGS_$(1)) $$(DEPS-$(1)) -o $$@ else -# hvm64 needs linking normally, then converting to elf32-x86-64 +# hvm64 needs linking normally, then converting to elf32-x86-64 or elf32-i386 test-$(1)-$(NAME): $$(DEPS-$(1)) $$(link-$(1)) $$(LD) $$(LDFLAGS_$(1)) $$(DEPS-$(1)) -o $$@.tmp - $$(OBJCOPY) $$@.tmp -O elf32-x86-64 $$@ + $(OBJCOPY) $$@.tmp -O $(hvm64-format) $$@ rm -f $$@.tmp endif don't require x32 support in binutils Older binutils don't have this at all, and newer may not have it configured in. Signed-off-by: Jan Beulich --- a/build/gen.mk +++ b/build/gen.mk @@ -40,6 +40,8 @@ install: install-each-env info.json @$(INSTALL_DIR) $(DESTDIR)$(xtftestdir)/$(NAME) $(INSTALL_DATA) info.json $(DESTDIR)$(xtftestdir)/$(NAME) +hvm64-format := $(firstword $(filter elf32-x86-64,$(shell $(OBJCOPY) --help)) elf32-i386) + define PERENV_build ifneq ($(1),hvm64) @@ -47,10 +49,10 @@ install: install-each-env info.json test-$(1)-$(NAME): $$(DEPS-$(1)) $$(link-$(1)) $$(LD) $$(LDFLAGS_$(1)) $$(DEPS-$(1)) -o $$@ else -# hvm64 needs linking normally, then converting to elf32-x86-64 +# hvm64 needs linking normally, then converting to elf32-x86-64 or elf32-i386 test-$(1)-$(NAME): $$(DEPS-$(1)) $$(link-$(1)) $$(LD) $$(LDFLAGS_$(1)) $$(DEPS-$(1)) -o $$@.tmp - $$(OBJCOPY) $$@.tmp -O elf32-x86-64 $$@ + $(OBJCOPY) $$@.tmp -O $(hvm64-format) $$@ rm -f $$@.tmp endif ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: Use ACPI reboot method for Dell OptiPlex 9020
>>> On 14.12.16 at 12:12, wrote: > When EFI booting the Dell OptiPlex 9020, it sometimes GP faults in the > EFI runtime instead of rebooting. Has it been understood what the #GP is due to? I.e. is it namely not because of a mis-aligned SSE instruction memory reference? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/traps: Correct overly-general assertion introduced in c/s d5c251c
>>> On 14.12.16 at 12:35, wrote: > The assertion about guest paging mode must only apply to guest pagefaults. > > This ASSERT() accidentally also trips if Xen takes a pagefault when in HVM > context, such as a copy_to_user() failure in the shadow pagetable code. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich But isn't the other piece the original patch touched in the same function suffering a similar problem? I.e. can't this mis-trigger when dealing with a page fault in Xen while in the context of a HVM guest in log-dirty mode, and hence needs re-adding the !paging_mode_external() check (or alternatively using paging_mode_only_log_dirty() instead of paging_mode_log_dirty())? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: support {RD,WR}{F,G}SBASE
On 14/12/16 09:37, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -432,6 +432,7 @@ typedef union {
> #define CR4_OSFXSR (1<<9)
> #define CR4_OSXMMEXCPT (1<<10)
> #define CR4_UMIP (1<<11)
> +#define CR4_FSGSBASE (1<<16)
> #define CR4_OSXSAVE(1<<18)
>
> /* EFLAGS bit definitions. */
> @@ -5205,6 +5206,44 @@ x86_emulate(
> }
> break;
>
> +case X86EMUL_OPC_F3(0x0f, 0xae): /* Grp15 */
> +{
> +unsigned long cr4;
> +
> +fail_if(modrm_mod != 3);
This should surely be an explicit #UD? The only issue is that we don't
yet implement Grp15/F3 instructions with memory operands (as there are
none yet defined)?
> +generate_exception_if((modrm_reg & 4) || !mode_64bit(), EXC_UD);
> +fail_if(!ops->read_cr);
> +if ( (rc = ops->read_cr(4, &cr4, ctxt)) != X86EMUL_OKAY )
> +goto done;
> +generate_exception_if(!(cr4 & CR4_FSGSBASE), EXC_UD);
> +fail_if(!ops->read_segment);
seg = modrm_reg & 1 ? x86_seg_gs : x86_seg_fs
would avoid the repetition later for write_segment().
> +if ( (rc = ops->read_segment(modrm_reg & 1 ? x86_seg_gs : x86_seg_fs,
> + &sreg, ctxt)) != X86EMUL_OKAY )
> +goto done;
> +dst.reg = decode_register(modrm_rm, &_regs, 0);
> +if ( !(modrm_reg & 2) )
> +{
> +/* rd{f,g}sbase */
> +dst.type = OP_REG;
> +dst.bytes = (op_bytes == 8) ? 8 : 4;
> +dst.val = sreg.base;
> +break;
> +}
> +/* wr{f,g}sbase */
> +if ( op_bytes == 8 )
> +{
> +sreg.base = *dst.reg;
> +generate_exception_if(!is_canonical_address(sreg.base), EXC_GP,
> 0);
> +}
> +else
> +sreg.base = (uint32_t)*dst.reg;
> +fail_if(!ops->write_segment);
> +if ( (rc = ops->write_segment(modrm_reg & 1 ? x86_seg_gs :
> x86_seg_fs,
> + &sreg, ctxt)) != X86EMUL_OKAY )
> +goto done;
Can I talk you into using a switch statement for this? I know it would
only have two or four cases, it but read path exiting midway through
took me a while to spot even though I was expecting to find it.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: init_acpi_config should return rc in exit path
On Wed, Dec 14, 2016 at 11:49:34AM +, Andrew Cooper wrote: > On 14/12/16 11:44, Wei Liu wrote: > > ... otherwise it returns 0 even if the function fails. > > Coverity-ID: 1397121 > Does it work this way? Coverity does lead to the discovery of this bug, but this CID doesn't reveal the bug directly. > > Signed-off-by: Wei Liu > > Reviewed-by: Andrew Cooper > > > --- > > Cc: Ian Jackson > > > > This should be backported to 4.8. > > --- > > tools/libxl/libxl_x86_acpi.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c > > index 686ac8e..6cf0c30 100644 > > --- a/tools/libxl/libxl_x86_acpi.c > > +++ b/tools/libxl/libxl_x86_acpi.c > > @@ -154,7 +154,7 @@ static int init_acpi_config(libxl__gc *gc, > > config->acpi_revision = 5; > > > > out: > > -return 0; > > +return rc; > > } > > > > int libxl__dom_load_acpi(libxl__gc *gc, > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 103325: regressions - FAIL
flight 103325 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103325/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 1035fe9b160bf298985296a6c73f2ab3d1ae55c5
baseline version:
xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5
Last test of basis 103284 2016-12-13 19:03:56 Z0 days
Testing same since 103292 2016-12-13 22:19:08 Z0 days5 attempts
People who touched revisions under test:
Cédric Bosdonnat
Ian Jackson
Stefano Stabellini
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt fail
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 1035fe9b160bf298985296a6c73f2ab3d1ae55c5
Author: Cédric Bosdonnat
Date: Tue Dec 13 17:31:52 2016 +0100
libxl: QED disks support
Qdisk supports qcow and qcow2, extend it to also support qed disk
format.
Signed-off-by: Cédric Bosdonnat
[ wei: regenerate libxlu_disk_l.{c,h} ]
Acked-by: Wei Liu
Acked-by: Ian Jackson
commit 9963caae97ad140fa207c3c61a9442b417afc1e9
Author: Stefano Stabellini
Date: Tue Dec 13 11:08:39 2016 -0800
fix LDRB Thumb2 decoding
Rt is four bit at offset 12, not three. See see encoding T2 for LDRB
A8.8.70 in ARM DDI 0406C.c
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current
Hi Andrew, On 13/12/16 19:39, Andrew Cooper wrote: On 13/12/16 18:41, Julien Grall wrote: On 13/12/16 18:28, Andrew Cooper wrote: On 12/12/16 23:47, Tamas K Lengyel wrote: Newer versions of VT-x/SVM may provide additional information on a vmexit, which include a guest physical address relevant to the the reason for the vmexit. Xen will attempt to proactively use this information to avoid a software pagewalk, but can always fall back to the software method if needs be. That is a good idea, but may bring some issue with memacces as we currently have on ARM. Why would a software-only approach have problem on ARM? Slow certainly, but it should function correctly. Sorry I meant, that using hardware instruction to translate an address on ARM has some drawback when using memaccess. However, ARM supports 2 kind of page tables (short page table and LPAE), different page size (4KB, 16KB, 64KB), split page tables, endianness... This would require some works to make all the combinations working. Furthermore, on 32-bit host not all the RAM is mapped in Xen. So guest pages are mapped on demand, requiring TLB invalidation. So I would only use the software approach when it is strictly necessary. I presume ARM has always relied on hardware support for translation, and has no software translation support? I presume therefore that translations only work when in current context? That's correct. ARM provided hardware support for most of translation from the start. But it relies on the guest page table to be accessible (e.g there is no memory restriction in stage-2). Ok, so ARM provides an instruction to translate an arbitrary virtual address to guest physical. How does this work in the context of Xen, or can hardware follow the currently-active virtualisation state to find the guest pagetables? Or does it rely on information in the TLB? Xen and the guest vCPU are using different separate set of the registers. When running in Xen context, the guest vCPU state is still present and will be used by the hardware to translate a VA to guest physical address. Note that ARM does not provide any hardware instruction to translate an IPA (guest physical address) to a PA. So we have a walker there. We also a walk for debugging guest page table (though only when it is using LPAE). I guess it could be re-used in the case where it is not possible to do it in hardware. Although, it would be rewritten to make it safe. This sounds like the kind of thing which would be generally useful, although I'd like to understand the problem better before making suggestions. memaccess will restrict permission of certain memory regions in stage-2 page table. For the purpose of the example, lets say read-access as been restricted. One of these memory regions may contain the stage-1 page table. Do you agree that the guest will not able to read stage-1 page table due the restriction? Similarly, when the hardware will do the page table walk it all the accesses will be on behalf of the guest. So a read on stage-1 page table would fail and the hardware will not be able to do the translation. I hope this clarify the problem. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Future x86 emulator direction
On 14/12/16 11:13, Jan Beulich wrote: On 14.12.16 at 11:43, wrote: >> The movlpd's should be easy to implement. They aren't meaningfully >> different from their integer counterparts in terms of needs for the >> emulator. > Well, the thing here is the increasing complexity of determining > the right size to do the actual memory access with. My plan with > all of SSEn/AVXn is to primarily group instructions by their memory > access patterns, rather than by base functionality (as is the case > now) - we're using a stub anyway, and what exactly an insn does > is of little interest (as long as it doesn't do anything unusual). > That'll then also hopefully allow to simplify the relatively > convoluted way we're currently dealing with the few insns we do > support. Ok. Sounds like a good plan. > >>> (XEN) Mem event emulation failed: d3v0 32bit @ 0008:821d385f -> 0f 6e 06 >>> 0f 72 d0 18 0f ef 05 08 f6 32 82 0f 61 >> This is just a straight movd (%esi),%mm0 >> >> I could have sworn we already had support for this... > See the set of three patches sent earlier today: So far we support > only their store forms, yet this is a load. Very true. I will take a look at your other series. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
