Re: [Xen-devel] [PATCH V4] x86 spinlock: Fix memory corruption on completing completions
On 02/13/2015 09:02 PM, Oleg Nesterov wrote:
On 02/13, Raghavendra K T wrote:
@@ -164,7 +161,7 @@ static inline int arch_spin_is_locked(arch_spinlock_t *lock)
{
struct __raw_tickets tmp = READ_ONCE(lock-tickets);
- return tmp.tail != tmp.head;
+ return tmp.tail != (tmp.head ~TICKET_SLOWPATH_FLAG);
}
Well, this can probably use __tickets_equal() too. But this is cosmetic.
That looks good. Added.
It seems that arch_spin_is_contended() should be fixed with this change,
(__ticket_t)(tmp.tail - tmp.head) TICKET_LOCK_INC
can be true because of TICKET_SLOWPATH_FLAG in .head, even if it is actually
unlocked.
Done.
Hmm! it was because I was still under impression that slowpath bit is
in tail. You are right, situation could lead to positive max and may
report false contention.
And the (__ticket_t) typecast looks unnecessary, it only adds more
confusuin, but this is cosmetic too.
Done.
@@ -772,7 +773,8 @@ __visible void kvm_lock_spinning(struct arch_spinlock
*lock, __ticket_t want)
* check again make sure it didn't become free while
* we weren't looking.
*/
- if (ACCESS_ONCE(lock-tickets.head) == want) {
+ head = READ_ONCE(lock-tickets.head);
+ if (__tickets_equal(head, want)) {
add_stats(TAKEN_SLOW_PICKUP, 1);
goto out;
This is off-topic, but with or without this change perhaps it makes sense
to add smp_mb__after_atomic(). It is nop on x86, just to make this code
more understandable for those (for me ;) who can never remember even the
x86 rules.
Hope you meant it for add_stat. yes smp_mb__after_atomic() would be
harmless barrier() in x86. Did not add this V5 as yoiu though but this
made me look at slowpath_enter code and added an explicit barrier()
there :).
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH V5] x86 spinlock: Fix memory corruption on completing completions
Paravirt spinlock clears slowpath flag after doing unlock.
As explained by Linus currently it does:
prev = *lock;
add_smp(lock-tickets.head, TICKET_LOCK_INC);
/* add_smp() is a full mb() */
if (unlikely(lock-tickets.tail TICKET_SLOWPATH_FLAG))
__ticket_unlock_slowpath(lock, prev);
which is *exactly* the kind of things you cannot do with spinlocks,
because after you've done the add_smp() and released the spinlock
for the fast-path, you can't access the spinlock any more. Exactly
because a fast-path lock might come in, and release the whole data
structure.
Linus suggested that we should not do any writes to lock after unlock(),
and we can move slowpath clearing to fastpath lock.
So this patch implements the fix with:
1. Moving slowpath flag to head (Oleg):
Unlocked locks don't care about the slowpath flag; therefore we can keep
it set after the last unlock, and clear it again on the first (try)lock.
-- this removes the write after unlock. note that keeping slowpath flag would
result in unnecessary kicks.
By moving the slowpath flag from the tail to the head ticket we also avoid
the need to access both the head and tail tickets on unlock.
2. use xadd to avoid read/write after unlock that checks the need for
unlock_kick (Linus):
We further avoid the need for a read-after-release by using xadd;
the prev head value will include the slowpath flag and indicate if we
need to do PV kicking of suspended spinners -- on modern chips xadd
isn't (much) more expensive than an add + load.
Result:
setup: 16core (32 cpu +ht sandy bridge 8GB 16vcpu guest)
benchmark overcommit %improve
kernbench 1x -0.13
kernbench 2x0.02
dbench 1x -1.77
dbench 2x -0.63
[Jeremy: hinted missing TICKET_LOCK_INC for kick]
[Oleg: Moving slowpath flag to head, ticket_equals idea]
[PeterZ: Detailed changelog]
Reported-by: Sasha Levin sasha.le...@oracle.com
Suggested-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
arch/x86/include/asm/spinlock.h | 95 -
arch/x86/kernel/kvm.c | 10 +++--
arch/x86/xen/spinlock.c | 10 +++--
3 files changed, 59 insertions(+), 56 deletions(-)
potential TODO:
* The whole patch be splitted into, 1. move slowpath flag
2. fix memory corruption in completion problem ??
Changes since V4:
- one more usage of tickets_equal() (Oleg)
- head tail situation can lead to false contended check (Oleg)
Changes since V3:
- Detailed changelog (PeterZ)
- Replace ACCESS_ONCE with READ_ONCE (oleg)
- Add xen changes (Oleg)
- Correct break logic in unlock_wait() (Oleg)
Changes since V2:
- Move the slowpath flag to head, this enables xadd usage in unlock code
and inturn we can get rid of read/write after unlock (Oleg)
- usage of ticket_equals (Oleg)
Changes since V1:
- Add missing TICKET_LOCK_INC before unlock kick (fixes hang in overcommit:
Jeremy).
- Remove SLOWPATH_FLAG clearing in fast lock. (Jeremy)
- clear SLOWPATH_FLAG in arch_spin_value_unlocked during comparison.
Result:
setup: 16core (32 cpu +ht sandy bridge 8GB 16vcpu guest)
base = 3_19_rc7
3_19_rc7_spinfix_v3
+---+---+---++---+
kernbench (Time taken in sec lower is better)
+---+---+---++---+
base %stdevpatched %stdev %improve
+---+---+---++---+
1x 54.2300 3.0652 54.3008 4.0366-0.13056
2x 90.1883 5.5509 90.1650 6.4336 0.02583
+---+---+---++---+
+---+---+---++---+
dbench (Throughput higher is better)
+---+---+---++---+
base %stdevpatched %stdev %improve
+---+---+---++---+
1x 7029.9188 2.5952 6905.0712 4.4737-1.77595
2x 3254.207514.8291 3233.713726.8784-0.62976
+---+---+---++---+
(here is the result I got from the patches, I believe there may
be some small overhead from xadd etc, but overall looks fine but
a thorough test may be needed)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 625660f..4413315 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -46,7 +46,8 @@ static __always_inline bool static_key_false(struct
static_key *key);
static inline void __ticket_enter_slowpath(arch_spinlock_t *lock)
{
- set_bit(0, (volatile unsigned long *)lock-tickets.tail);
+ set_bit(0, (volatile unsigned long *)lock-tickets.head);
+ barrier();
}
#else /* !CONFIG_PARAVIRT_SPINLOCKS */
@@ -60,10 +61,30 @@
Re: [Xen-devel] [PATCH V5] x86 spinlock: Fix memory corruption on completing completions
On 02/15/2015 11:25 AM, Raghavendra K T wrote: Paravirt spinlock clears slowpath flag after doing unlock. As explained by Linus currently it does: prev = *lock; add_smp(lock-tickets.head, TICKET_LOCK_INC); /* add_smp() is a full mb() */ if (unlikely(lock-tickets.tail TICKET_SLOWPATH_FLAG)) __ticket_unlock_slowpath(lock, prev); which is *exactly* the kind of things you cannot do with spinlocks, because after you've done the add_smp() and released the spinlock for the fast-path, you can't access the spinlock any more. Exactly because a fast-path lock might come in, and release the whole data structure. Linus suggested that we should not do any writes to lock after unlock(), and we can move slowpath clearing to fastpath lock. So this patch implements the fix with: 1. Moving slowpath flag to head (Oleg): Unlocked locks don't care about the slowpath flag; therefore we can keep it set after the last unlock, and clear it again on the first (try)lock. -- this removes the write after unlock. note that keeping slowpath flag would result in unnecessary kicks. By moving the slowpath flag from the tail to the head ticket we also avoid the need to access both the head and tail tickets on unlock. 2. use xadd to avoid read/write after unlock that checks the need for unlock_kick (Linus): We further avoid the need for a read-after-release by using xadd; the prev head value will include the slowpath flag and indicate if we need to do PV kicking of suspended spinners -- on modern chips xadd isn't (much) more expensive than an add + load. Result: setup: 16core (32 cpu +ht sandy bridge 8GB 16vcpu guest) benchmark overcommit %improve kernbench 1x -0.13 kernbench 2x0.02 dbench 1x -1.77 dbench 2x -0.63 [Jeremy: hinted missing TICKET_LOCK_INC for kick] [Oleg: Moving slowpath flag to head, ticket_equals idea] [PeterZ: Detailed changelog] Reported-by: Sasha Levin sasha.le...@oracle.com Suggested-by: Linus Torvalds torva...@linux-foundation.org Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com --- Sasha, Hope this addresses invalid read concern you had with latest xadd based implementation. (Think we need to test without Oleg's PATCH] sched/completion: completion_done() should serialize with complete() reported by Paul.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.14 test] 34513: tolerable FAIL - PUSHED
flight 34513 linux-3.14 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34513/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 12 guest-start.2 fail pass in 34468 test-armhf-armhf-libvirt 12 guest-start.2 fail pass in 34468 test-armhf-armhf-xl-sedf 9 guest-startfail in 34468 pass in 34513 test-amd64-i386-qemut-rhel6hvm-intel 11 leak-check/check fail in 34468 pass in 34513 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 12 guest-start.2fail blocked in 34268 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34268 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: linuxa74f1d1204a5c892466b52ac68ee6443c1e459d7 baseline version: linux4ccf212fb84d79b75fc66a2e26ac6bdbab0aedbf People who touched revisions under test: Aaro Koskinen aaro.koski...@iki.fi Andrew Morton a...@linux-foundation.org Andy Lutomirski l...@amacapital.net Bjorn Helgaas bhelg...@google.com Bo Shen voice.s...@atmel.com Catalin Marinas catalin.mari...@arm.com Charlotte Richardson charlotte.richard...@stratus.com David Daney david.da...@cavium.com David S. Miller da...@davemloft.net Dmitry Monakhov dmonak...@openvz.org Eric Dumazet eduma...@google.com Eric Nelson eric.nel...@boundarydevices.com Felix Fietkau n...@openwrt.org Greg Kroah-Hartman gre...@linuxfoundation.org Hemmo Nieminen hemmo.niemi...@iki.fi hujianyang hujiany...@huawei.com Jaroslav Kysela pe...@perex.cz Jeff Layton jlay...@samba.org Johan Hovold jo...@kernel.org karl beldan karl.bel...@gmail.com Karl Beldan karl.bel...@rivierawaves.com Lai Jiangshan la...@cn.fujitsu.com Linus Torvalds torva...@linux-foundation.org Linus Walleij linus.wall...@linaro.org Mark Brown broo...@kernel.org Mark Rutland mark.rutl...@arm.com Mathias Krause mini...@googlemail.com Michal Marek mma...@suse.cz Naoya Horiguchi n-horigu...@ah.jp.nec.com Paolo Bonzini pbonz...@redhat.com Pavel Hofman pavel.hof...@ivitera.com Peter Kümmel syntheti...@gmx.net Ralf Baechle r...@linux-mips.org Raymond Ngun rn...@broadcom.com Russell King rmk+ker...@arm.linux.org.uk Ryusuke Konishi konishi.ryus...@lab.ntt.co.jp Sachin Prabhu spra...@redhat.com Shiraz Hashim shas...@codeaurora.org Shirish Pargaonkar shirishpargaon...@gmail.com Steve French steve.fre...@primarydata.com Takashi Iwai ti...@suse.de Theodore Ts'o ty...@mit.edu Thomas Gleixner t...@linutronix.de Wang Kai morgan.w...@huawei.com Will Deacon will.dea...@arm.com
[Xen-devel] [linux-next test] 34512: regressions - FAIL
flight 34512 linux-next real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34512/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 5 xen-boot fail REGR. vs. 34383 test-amd64-i386-qemut-rhel6hvm-intel 5 xen-boot fail REGR. vs. 34383 test-amd64-i386-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 34383 test-amd64-i386-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 34383 test-amd64-i386-qemuu-rhel6hvm-intel 5 xen-boot fail REGR. vs. 34383 test-amd64-i386-xl-qemut-winxpsp3 5 xen-boot fail REGR. vs. 34383 test-amd64-i386-xl-qemut-win7-amd64 5 xen-boot fail REGR. vs. 34383 test-armhf-armhf-libvirt 12 guest-start.2 fail REGR. vs. 34383 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 34383 test-amd64-amd64-xl 5 xen-boot fail REGR. vs. 34383 test-amd64-amd64-xl-qemuu-ovmf-amd64 5 xen-boot fail REGR. vs. 34383 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 34383 test-amd64-amd64-pair 8 xen-boot/dst_host fail REGR. vs. 34383 test-amd64-amd64-pair 7 xen-boot/src_host fail REGR. vs. 34383 test-amd64-i386-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 34383 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 34383 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail REGR. vs. 34383 test-amd64-i386-libvirt 9 guest-start fail like 34383 test-amd64-amd64-xl-sedf-pin 5 xen-boot fail REGR. vs. 34383 test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 34383 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34383 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail like 34383 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: linux7496ad672d0ed7177fefec9c70ece8a70bbd2dc1 baseline version: linuxbfa76d49576599a4b9f9b7a71f23d73d6dcff735 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl fail test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd
Re: [Xen-devel] [PATCH 1/5] multiboot2: Fix information request tag size calculation
В Fri, 30 Jan 2015 18:59:24 +0100
Daniel Kiper daniel.ki...@oracle.com пишет:
Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
---
grub-core/loader/multiboot_mbi2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grub-core/loader/multiboot_mbi2.c
b/grub-core/loader/multiboot_mbi2.c
index 6f74aee..d7c19bc 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -150,7 +150,7 @@ grub_multiboot_load (grub_file_t file, const char
*filename)
= (struct multiboot_header_tag_information_request *) tag;
if (request_tag-flags MULTIBOOT_HEADER_TAG_OPTIONAL)
break;
- for (i = 0; i (request_tag-size - sizeof (request_tag))
+ for (i = 0; i (request_tag-size - sizeof (*request_tag))
/ sizeof (request_tag-requests[0]); i++)
switch (request_tag-requests[i])
{
Applied. Thanks!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-unstable test] 34522: regressions - FAIL
flight 34522 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34522/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 11 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-freebsd10-amd64 11 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-win7-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-amd64-xl-win7-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-winxpsp3-vcpus1 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-winxpsp3 10 guest-localmigratefail REGR. vs. 33488 test-amd64-i386-rhel6hvm-amd 6 leak-check/basis(6) running in 34247 [st=running!] test-amd64-amd64-xl-winxpsp3 10 guest-localmigrate fail in 34247 REGR. vs. 33488 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-bootfail pass in 34477 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail pass in 34247 test-amd64-amd64-xl-winxpsp3 7 windows-install fail pass in 34319 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 9 guest-start fail like 33488 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-qemuu-win7-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-qemuu-ovmf-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-qemuu-winxpsp3 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-amd64-xl-qemuu-win7-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-amd64-xl-qemuu-winxpsp3 10 guest-localmigrate fail REGR. vs. 33488 test-armhf-armhf-xl-multivcpu 14 leak-check/check fail in 34247 blocked in 33488 test-armhf-armhf-libvirt 13 guest-destroy fail in 34247 blocked in 33488 test-armhf-armhf-xl-credit2 5 xen-bootfail in 34247 blocked in 33488 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail in 34477 never pass version targeted for testing: qemuube11dc1e9172f91e798a8f831b30c14b479e08e8 baseline version: qemuu0d37748342e29854db7c9f6c47d7f58c6cfba6b2 People who touched revisions under test: Don Slutz dsl...@verizon.com Paul Durrant paul.durr...@citrix.com Stefano Stabellini stefano.stabell...@eu.citrix.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail
[Xen-devel] [linux-linus test] 34516: regressions - FAIL
flight 34516 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34516/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 5 xen-boot fail REGR. vs. 34227 test-amd64-i386-qemut-rhel6hvm-intel 5 xen-boot fail REGR. vs. 34227 test-amd64-amd64-xl-winxpsp3 5 xen-boot fail REGR. vs. 34227 test-amd64-i386-xl-qemuu-winxpsp3 5 xen-boot fail REGR. vs. 34227 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 34227 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 guest-destroy fail like 34394-bisect test-amd64-i386-libvirt 9 guest-start fail like 34227 test-amd64-amd64-libvirt 9 guest-start fail REGR. vs. 34227 test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 34227 test-amd64-i386-freebsd10-amd64 7 freebsd-install fail like 34227 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34227 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail like 34227 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass version targeted for testing: linuxa26be149facb22d30cd92cadb26f651d6fe802c9 baseline version: linux9d82f5eb3376cbae96ad36a063a9390de1694546 1033 people touched revisions under test, not listing them all jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64
Re: [Xen-devel] [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
В Wed, 11 Feb 2015 08:20:04 + Jan Beulich jbeul...@suse.com пишет: On 10.02.15 at 22:27, daniel.ki...@oracle.com wrote: After some testing we have found at least one machine on which this thing does not work. It is Dell PowerEdge R820 with latest firmware. Machine crashes/stops because early 32-bit code is not relocatable and must live under 0x10 address. (side note: I am surprised how it worked without any issue until now; Multiboot protocol, any version, does not guarantee that OS image will be loaded at specified/requested address; How does it not? It's an ELF binary without relocations that's being loaded - I can't see how such could be validly loaded anywhere but at the virtual address(es) its program header states (and I don't know whether grub [1 or 2] would correctly process relocations if there were any, but I doubt it). grub2 relocates own modules when loading them. It does not do relocation when loading Xen binary, but it does not sound impossible. Now I see two solutions for these issues: 1) We can make early 32-bit code relocatable. We may use something similar to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I think that early code should not blindly map first 16 MiB of memory. It should map first 1 MiB of memory and then 16 MiB of memory starting from xen_phys_start. This way we also fix long standing bug in early code which I described earlier. 2) We can jump from EFI x86-64 mode directly into Xen x86-64 mode like it is done in case of EFI loader. However, then we must duplicate multiboot2 protocol implementation in x86-64 mode (if we wish that multiboot2 protocol can be used on legacy BIOS and EFI platforms; I think that we should support this protocol on both for users convenience). Additionally, we must use a workaround to relocate trampoline if boot services uses memory below 1 MiB (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, x86/EFI: make trampoline allocation more flexible, for more details). I prefer #1 because this way we do not duplicate multiboot2 protocol implementation (one for legacy BIOS and EFI) and we avoid issues with trampoline relocation when low memory is occupied by boot services and/or 1:1 EFI page tables. Between the two, 1 is certainly the preferable option. PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d will not work if trampoline code will overwrite some of EFI 1:1 page tables. Dell PowerEdge R820 store part of 1:1 page tables below 1 MiB. Xen loaded by native EFI loader boots but it is only lucky coincidence that it does not overwrite used entries. So, I tend to go and choose #1 even more. How awful a firmware implementation! On PC-like systems, _nothing_ that _absolutely_ has to be below 1Mb should be placed there. Jan ___ Grub-devel mailing list grub-de...@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 00/17] blktap2 related bugfix patches
I'm working on a talk for the Linux Collab Summit next week; and after that I'm on holiday for about a week. (Actually I'm in Hong Kong for the tail end of Chinese New Year!) At any rate, I won't get a chance to look at this until March at the earliest. -George From: Hongyang Yang [yan...@cn.fujitsu.com] Sent: 13 February 2015 06:56 To: George Dunlap; Wen Congyang Cc: Ian Jackson; Lai Jiangshan; Jiang Yunhong; Eddie Dong; xen devel; Ian Campbell Subject: Re: [Xen-devel] [PATCH 00/17] blktap2 related bugfix patches Hi George, 在 11/03/2014 05:58 PM, George Dunlap 写道: On 10/29/2014 05:49 AM, Wen Congyang wrote: On 10/20/2014 10:25 PM, George Dunlap wrote: On Wed, Oct 15, 2014 at 2:05 AM, Wen Congyang we...@cn.fujitsu.com wrote: On 10/14/2014 11:48 PM, Ian Jackson wrote: Wen Congyang writes ([PATCH 00/17] blktap2 related bugfix patches): These bugs are found when we implement COLO, or rebase COLO to upstream xen. They are independent patches, so post them in separate series. blktap2 is unmaintained AFAICT. In the last year there has been only one commit which shows evidence of someone caring even slightly about tools/blktap2/. The last substantial attention was in March 2013. (I'm disregarding commits which touch tools/blktap2/ to fix up compile problems with new compilers, sort out build system and file rearrangements, etc.) The file you are touching in your 01/17 was last edited (by anyone, at all) in January 2010. Under the circumstances, we should probably take all these changes without looking for anyone to ack them. Perhaps you would like to become the maintainers of blktap2 ? :-) Hmm, I don't have any knowledge about disk format, but blktap2 have such codes(For example: block-vhd.c, block-qcow.c...). I think I can maintain the rest codes. Congyang, were you aware that XenServer has a fork of blktap is actually still under active development and maintainership outside of the main Xen tree? git://github.com/xen-org/blktap.git Both CentOS and Fedora are actually using snapshots of the blktap2 branch in that tree for their Xen RPMs. (I'm sure CentOS is, I believe Fedora is.) It's not unlikely that the bugs you're fixing here have already been fixed in the XenServer fork. I have another question: Why we don't merge the blktap2' branch into xen upstream periodically? I take it you've found blktap 2.5 useful? :-) I've been meaning to write an e-mail about this. The basic reason is that it's normally up to the people doing the development to submit changes upstream. Some years ago XenServer forked the blktap2 codebase but got behind in upstreaming things; at this point there are far too many changes to simply push them upstream. Furthermore, even XenServer isn't 100% sure what they're going to do in the future; as of a year ago they were planning to get rid of blktap entirely in favor of another solution. One of the ideas I'm going to discuss in my e-mail is the idea of treating blktap2.5 (and/or blktap3) as an external upstream project, similar to the way that we treat qemu, seabios, ipxe, and ovmf. That would have a similar effect to what you describe. How is this going? -George . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled
On 02/12/15 21:53, Jordan Justen wrote: I think gEfiPciEnumerationCompleteProtocolGuid should be installed by MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisableBusEnumeration is set. Ray's main feedback seemed to be that we need to make sure PciBusDxe only installs the protocol once. (I'll also reply to the other related patch thread.) First, I now agree that this patch of mine should not go in, hence: Self-NAK Second, I tend to disagree that that gEfiPciEnumerationCompleteProtocolGuid should be installed even if full enumeration was eschewed. This might slightly change the de-facto meaning of the protocol (because no resource allocation took place). In general I think we should not try to touch MdeModulePkg/Bus/Pci/PciBusDxe for our need here. So let's think again what we need. We want to delay the download and installation of ACPI tables on virt platforms until PCI enumeration is complete, *except* in some cases: (1) When OVMF runs on Xen. In that case PcdPciDisableBusEnumeration is TRUE, and the PCI bus driver does not install gEfiPciEnumerationCompleteProtocolGuid (in my opinion: correctly, because no resource allocation takes place, which is the de-facto meaning of the completion protocol). This means that the depex in OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf is no longer correct: [Depex] gEfiAcpiTableProtocolGuid AND gEfiPciEnumerationCompleteProtocolGuid (2) When the platform in question lacks PCI. Right now this means ArmVirtualizationQemu. However, that is about to change (I've mostly ported PCI support to ArmVirtualizationQemu; virtio-pci, USB keyboard, std-VGA work). Importantly, presence of PCI on ARM will become a *dynamic* question, dependent on the QEMU version. Current master QEMU does not provide PCI hardware for arm/mach-virt, but Alex Graf's patches in Peter Maydell's target-arm.next branch do, and so will master soon. This means that the depex in OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf will also break: [Depex] gEfiAcpiTableProtocolGuid [Depex.IA32, Depex.X64] gEfiPciEnumerationCompleteProtocolGuid because on ARM we might or might not want to wait for enumeration completion dependent on whether the DTB ultimately describes a PCI root bridge or not. So here's what I propose. (Again, the above is *all* motivated by OvmfPkg/AcpiPlatformDxe/.) In my PCI-for-ArmVirtualizationQemu patchset, I will introduce a new protocol GUID (with NULL structure) that will simply say OvmfPkg's AcpiPlatformDxe should not wait for PCI enumeration. Then, *both* INF files under OvmfPkg/AcpiPlatformDxe shall receive the following depex: [Depex] gEfiAcpiTableProtocolGuid AND (gEfiPciEnumerationCompleteProtocolGuid OR gOvmfAcpiPlatformNoPciEnumerationProtocolGuid ) Then each particular platform driver shall unblock AcpiPlatformDxe in its own way: - OVMF on QEMU will do nothing special, it'll just go with the usual gEfiPciEnumerationCompleteProtocolGuid, installed by PciBusDxe. - OVMF on Xen will install gOvmfAcpiPlatformNoPciEnumerationProtocolGuid -- Wei, could you post a patch for this later? I think the protocol should be installed in XenBusDxeDriverBindingStart(), when it succeeds. It would be probably prudent to coordinate with Ard, wrt. Ard's series that brings Xen to ArmVirtualizationQemu. - In my PCI-for-ArmVirtualizationQemu series, I'll install gOvmfAcpiPlatformNoPciEnumerationProtocolGuid in case PCI is unavailable on the particular QEMU version. My main point is, our *real* target is OvmfPkg/AcpiPlatformDxe here, and the conditions whether to delay or not to delay its work until PCI enumeration is complete are platform dependent and *dynamic*. We should let all platform-specific drivers decide for themselves, and we should steer clear of drivers that are central to edk2, like PciBusDxe. What do you guys think? Thanks! Laszlo -Jordan On 2015-02-12 04:16:07, Laszlo Ersek wrote: SVN r16411 delayed ACPI table installation until PCI enumeration was complete, because on QEMU the ACPI-related fw_cfg files should only be downloaded after PCI enumeration. However, InitializeXen() in OvmfPkg/PlatformPei/Xen.c sets PcdPciDisableBusEnumeration to TRUE. This causes PciBusDriverBindingStart() in MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c to set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c branch to PciEnumeratorLight(). The installation of EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is not reached. Which means that starting with SVN r16411, AcpiPlatformDxe is never dispatched on Xen. This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a matching protocol registration callback for the PCI enumeration enabled (ie. QEMU) case. When PCI enumeration is disabled (ie. when running on Xen), AcpiPlatformDxe doesn't wait for EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL. Contributed-under: TianoCore
Re: [Xen-devel] [edk2] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled
On Feb 14, 2015, at 1:04 PM, Laszlo Ersek ler...@redhat.com wrote: On 02/14/15 21:03, Jordan Justen wrote: On 2015-02-14 08:38:37, Laszlo Ersek wrote: On 02/12/15 21:53, Jordan Justen wrote: I think gEfiPciEnumerationCompleteProtocolGuid should be installed by MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisableBusEnumeration is set. Ray's main feedback seemed to be that we need to make sure PciBusDxe only installs the protocol once. (I'll also reply to the other related patch thread.) First, I now agree that this patch of mine should not go in, hence: Self-NAK Second, I tend to disagree that that gEfiPciEnumerationCompleteProtocolGuid should be installed even if full enumeration was eschewed. This might slightly change the de-facto meaning of the protocol (because no resource allocation took place). De-facto seems the correct term here, since the PI1.2 spec says very little about the protocol. My interpretation of the protocol is that it is a signal that the EFI knows about the basic PCI topology, and has installed most PciIo instances. Maybe PcdPciDisableBusEnumeration wasn't the best name. Perhaps PcdPciBusPreEnumerated would have been better. At any rate, in the case of Xen, the hypervisor has pre-enumerated the bus. PciBusDxe uses this and 'enumerates' PCI devices by simply scanning the pre-enumerated topology. So, I still think PciBusDxe should install gEfiPciEnumerationCompleteProtocolGuid, because it still seems like it acurately reflects the phase of the boot process. Regarding the ACPI tables issue, would a callback for the ReadyToBoot event work? EFI_EVENT_GROUP_READY_TO_BOOT This event group is notified by the system when the Boot Manager is about to load and execute a boot option. (1) As far as I understand, if you boot a UEFI application, then exit it, and boot something else, then the event group will be signalled each time. We could use a static variable in AcpiPlatformDxe to avoid trying to install again and again, but it wouldn't be nice IMHO. You can always use a global. This is the secondary reason I'm not enthusiastic about EFI_EVENT_GROUP_READY_TO_BOOT. :) (2) The main reason is different: in both OVMF and ArmVirtualizationQemu we can boot a kernel directly, taken from QEMU. That happens without EFI_EVENT_GROUP_READY_TO_BOOT being signalled. However, the kernel booted thus should have both ACPI tables and configured PCI devices (if there is a PCI host). In OVMF this is ensured by: PlatformBdsPolicyBehavior() PlatformBdsConnectSequence() BdsLibConnectAll() TryRunningQemuKernel() where the BdsLibConnectAll() call listed above will cover the enumeration, and trigger the dependent ACPI table installation as well, before we go to the kernel. One idea could be to signal EFI_EVENT_GROUP_READY_TO_BOOT ourselves, That sounds like the right thing to do. before booting the kernel; however this event group seems quite tied to the Boot Manager itself (see again its definition above). The Boot Manager has a few responsibilities in EFI (and few more in PI where it is called the BDS), but in general it is a place where a lot of platform specific policy is enforced. So updating the Boot Manager do do the right thing sees like a good answer. Thanks, Andrew Fish I'll post my patch series soon; my idea that is relevant for this discussion is at its beginning (and a later patch also displays how I mean it to be used). We can discuss it there too if you like. Thanks Laszlo -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ http://goparallel.sourceforge.net/ ___ edk2-devel mailing list edk2-de...@lists.sourceforge.net mailto:edk2-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel https://lists.sourceforge.net/lists/listinfo/edk2-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 34529: regressions - FAIL
flight 34529 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34529/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 13 guest-destroy fail REGR. vs. 34341 test-amd64-i386-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 34341 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34341 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen cb34a7c8d741aa447d79e1b01d71168a4088a4d7 baseline version: xen 001324547356af86875fad5003f679571a6b8f1c People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Don Slutz dsl...@verizon.com George Dunlap george.dun...@eu.citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Paul Durrant paul.durr...@citrix.com Wei Liu wei.l...@citrix.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 fail test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64
Re: [Xen-devel] [edk2] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled
On 2015-02-14 08:38:37, Laszlo Ersek wrote: On 02/12/15 21:53, Jordan Justen wrote: I think gEfiPciEnumerationCompleteProtocolGuid should be installed by MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisableBusEnumeration is set. Ray's main feedback seemed to be that we need to make sure PciBusDxe only installs the protocol once. (I'll also reply to the other related patch thread.) First, I now agree that this patch of mine should not go in, hence: Self-NAK Second, I tend to disagree that that gEfiPciEnumerationCompleteProtocolGuid should be installed even if full enumeration was eschewed. This might slightly change the de-facto meaning of the protocol (because no resource allocation took place). De-facto seems the correct term here, since the PI1.2 spec says very little about the protocol. My interpretation of the protocol is that it is a signal that the EFI knows about the basic PCI topology, and has installed most PciIo instances. Maybe PcdPciDisableBusEnumeration wasn't the best name. Perhaps PcdPciBusPreEnumerated would have been better. At any rate, in the case of Xen, the hypervisor has pre-enumerated the bus. PciBusDxe uses this and 'enumerates' PCI devices by simply scanning the pre-enumerated topology. So, I still think PciBusDxe should install gEfiPciEnumerationCompleteProtocolGuid, because it still seems like it acurately reflects the phase of the boot process. Regarding the ACPI tables issue, would a callback for the ReadyToBoot event work? -Jordan In general I think we should not try to touch MdeModulePkg/Bus/Pci/PciBusDxe for our need here. So let's think again what we need. We want to delay the download and installation of ACPI tables on virt platforms until PCI enumeration is complete, *except* in some cases: (1) When OVMF runs on Xen. In that case PcdPciDisableBusEnumeration is TRUE, and the PCI bus driver does not install gEfiPciEnumerationCompleteProtocolGuid (in my opinion: correctly, because no resource allocation takes place, which is the de-facto meaning of the completion protocol). This means that the depex in OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf is no longer correct: [Depex] gEfiAcpiTableProtocolGuid AND gEfiPciEnumerationCompleteProtocolGuid (2) When the platform in question lacks PCI. Right now this means ArmVirtualizationQemu. However, that is about to change (I've mostly ported PCI support to ArmVirtualizationQemu; virtio-pci, USB keyboard, std-VGA work). Importantly, presence of PCI on ARM will become a *dynamic* question, dependent on the QEMU version. Current master QEMU does not provide PCI hardware for arm/mach-virt, but Alex Graf's patches in Peter Maydell's target-arm.next branch do, and so will master soon. This means that the depex in OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf will also break: [Depex] gEfiAcpiTableProtocolGuid [Depex.IA32, Depex.X64] gEfiPciEnumerationCompleteProtocolGuid because on ARM we might or might not want to wait for enumeration completion dependent on whether the DTB ultimately describes a PCI root bridge or not. So here's what I propose. (Again, the above is *all* motivated by OvmfPkg/AcpiPlatformDxe/.) In my PCI-for-ArmVirtualizationQemu patchset, I will introduce a new protocol GUID (with NULL structure) that will simply say OvmfPkg's AcpiPlatformDxe should not wait for PCI enumeration. Then, *both* INF files under OvmfPkg/AcpiPlatformDxe shall receive the following depex: [Depex] gEfiAcpiTableProtocolGuid AND (gEfiPciEnumerationCompleteProtocolGuid OR gOvmfAcpiPlatformNoPciEnumerationProtocolGuid ) Then each particular platform driver shall unblock AcpiPlatformDxe in its own way: - OVMF on QEMU will do nothing special, it'll just go with the usual gEfiPciEnumerationCompleteProtocolGuid, installed by PciBusDxe. - OVMF on Xen will install gOvmfAcpiPlatformNoPciEnumerationProtocolGuid -- Wei, could you post a patch for this later? I think the protocol should be installed in XenBusDxeDriverBindingStart(), when it succeeds. It would be probably prudent to coordinate with Ard, wrt. Ard's series that brings Xen to ArmVirtualizationQemu. - In my PCI-for-ArmVirtualizationQemu series, I'll install gOvmfAcpiPlatformNoPciEnumerationProtocolGuid in case PCI is unavailable on the particular QEMU version. My main point is, our *real* target is OvmfPkg/AcpiPlatformDxe here, and the conditions whether to delay or not to delay its work until PCI enumeration is complete are platform dependent and *dynamic*. We should let all platform-specific drivers decide for themselves, and we should steer clear of drivers that are central to edk2, like PciBusDxe. What do you guys think? Thanks! Laszlo -Jordan On 2015-02-12 04:16:07, Laszlo Ersek wrote: SVN r16411 delayed ACPI table installation until PCI enumeration was complete, because on QEMU the
[Xen-devel] [rumpuserxen test] 34537: regressions - FAIL
flight 34537 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34537/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 8af836e751ed191f3e2918668649710dd307e0b5 baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net jobs: build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. commit 8af836e751ed191f3e2918668649710dd307e0b5 Author: Martin Lucina mar...@lucina.net Date: Tue Feb 10 10:49:23 2015 +0100 Pull in latest buildrump.sh and src-netbsd For fixes to libc compat symbols missing (issue #21) commit e28e2b9daf7ab2922913889d90ec438b9bee3d56 Author: Ian Jackson ian.jack...@eu.citrix.com Date: Wed Feb 4 16:29:26 2015 + app-tools: Support old -D__RUMPUSER_XEN__ for now Released versions of Xen (Xen 4.5) rely on __RUMPUSER_XEN__ being defined. A patch to change this in Xen upstream exists and will be backported, but until that makes it through to a stable point release of Xen 4.5, we should support both #defines. This commit partially reverts 91d56232d987 Renaming platform macros, app-tools and autoconf target string Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com CC: Martin Lucina mar...@lucina.net CC: Ian Campbell ian.campb...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com commit 05e06b0fe52918d6575e33b7d7551d85c93f7aff Author: Martin Lucina mar...@lucina.net Date: Mon Feb 2 18:01:52 2015 +0100 Sync Travis CI configuration with app-tools rename Signed-off-by: Martin Lucina mar...@lucina.net commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c Author: Martin Lucina mar...@lucina.net Date: Mon Feb 2 18:00:36 2015 +0100 Remove even older rumpxen-app-* variants of app-tools Signed-off-by: Martin Lucina mar...@lucina.net commit 91d56232d987f5df594723ed46b9000b4d43e21a Author: Martin Lucina mar...@lucina.net Date: Mon Feb 2 17:52:41 2015 +0100 Renaming platform macros, app-tools and autoconf target string As discussed at: http://thread.gmane.org/gmane.comp.rumpkernel.user/739 This commit renames the platform macros, app-tools and autoconf target string to be consistent with current naming of the entire stack: app-tools/rumpapp-xen-* - app-tools/rumprun-xen-* $ARCH-rumpxen-netbsd - $ARCH-rumprun-netbsd -D__RUMPUSER_XEN__ -D__RUMPAPP__ - -D__RUMPRUN__ Signed-off-by: Martin Lucina mar...@lucina.net ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled
On 02/14/15 21:03, Jordan Justen wrote: On 2015-02-14 08:38:37, Laszlo Ersek wrote: On 02/12/15 21:53, Jordan Justen wrote: I think gEfiPciEnumerationCompleteProtocolGuid should be installed by MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisableBusEnumeration is set. Ray's main feedback seemed to be that we need to make sure PciBusDxe only installs the protocol once. (I'll also reply to the other related patch thread.) First, I now agree that this patch of mine should not go in, hence: Self-NAK Second, I tend to disagree that that gEfiPciEnumerationCompleteProtocolGuid should be installed even if full enumeration was eschewed. This might slightly change the de-facto meaning of the protocol (because no resource allocation took place). De-facto seems the correct term here, since the PI1.2 spec says very little about the protocol. My interpretation of the protocol is that it is a signal that the EFI knows about the basic PCI topology, and has installed most PciIo instances. Maybe PcdPciDisableBusEnumeration wasn't the best name. Perhaps PcdPciBusPreEnumerated would have been better. At any rate, in the case of Xen, the hypervisor has pre-enumerated the bus. PciBusDxe uses this and 'enumerates' PCI devices by simply scanning the pre-enumerated topology. So, I still think PciBusDxe should install gEfiPciEnumerationCompleteProtocolGuid, because it still seems like it acurately reflects the phase of the boot process. Regarding the ACPI tables issue, would a callback for the ReadyToBoot event work? EFI_EVENT_GROUP_READY_TO_BOOT This event group is notified by the system when the Boot Manager is about to load and execute a boot option. (1) As far as I understand, if you boot a UEFI application, then exit it, and boot something else, then the event group will be signalled each time. We could use a static variable in AcpiPlatformDxe to avoid trying to install again and again, but it wouldn't be nice IMHO. This is the secondary reason I'm not enthusiastic about EFI_EVENT_GROUP_READY_TO_BOOT. :) (2) The main reason is different: in both OVMF and ArmVirtualizationQemu we can boot a kernel directly, taken from QEMU. That happens without EFI_EVENT_GROUP_READY_TO_BOOT being signalled. However, the kernel booted thus should have both ACPI tables and configured PCI devices (if there is a PCI host). In OVMF this is ensured by: PlatformBdsPolicyBehavior() PlatformBdsConnectSequence() BdsLibConnectAll() TryRunningQemuKernel() where the BdsLibConnectAll() call listed above will cover the enumeration, and trigger the dependent ACPI table installation as well, before we go to the kernel. One idea could be to signal EFI_EVENT_GROUP_READY_TO_BOOT ourselves, before booting the kernel; however this event group seems quite tied to the Boot Manager itself (see again its definition above). I'll post my patch series soon; my idea that is relevant for this discussion is at its beginning (and a later patch also displays how I mean it to be used). We can discuss it there too if you like. Thanks Laszlo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 34542: regressions - FAIL
flight 34542 libvirt real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34542/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 13 guest-destroy fail REGR. vs. 34464 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 9 guest-start fail REGR. vs. 34464 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass version targeted for testing: libvirt aee3b77c336b7ae54914e322239ffabee59d74eb baseline version: libvirt a7c9c7a6abfb18db1e6b0da0bd9ee680d915c992 People who touched revisions under test: Daniel P. Berrange berra...@redhat.com Erik Skultety eskul...@redhat.com John Ferlan jfer...@redhat.com Ján Tomko jto...@redhat.com Laine Stump la...@laine.org Luyao Huang lhu...@redhat.com Marek Marczykowski-Górecki marma...@invisiblethingslab.com Martin Kletzander mklet...@redhat.com Michal Privoznik mpriv...@redhat.com Pavel Hrdina phrd...@redhat.com Yue Wenyuan yueweny...@huawei.com@huawei.com Zhang Bo oscar.zhan...@huawei.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 663 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 34536: regressions - FAIL
flight 34536 ovmf real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34536/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33686 test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33686 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 33686 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 12 guest-start.2fail blocked in 33686 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass version targeted for testing: ovmf c0a8cf34f6f83fd6bf90652a1a3f1123ed5796cd baseline version: ovmf 447d264115c476142f884af0be287622cd244423 People who touched revisions under test: Gao, Liming liming@intel.com Long, Qin qin.l...@intel.com Yao, Jiewen jiewen@intel.com Aaron Pop aar...@ami.com Abner Chang abner.ch...@hp.com Alex Williamson alex.william...@redhat.com Anderw Fish af...@apple.com Andrew Fish af...@apple.com Anthony PERARD anthony.per...@citrix.com Ard Biesheuvel ard.biesheu...@linaro.org Ari Zigler a...@mellanox.com Brendan Jackman brendan.jack...@arm.com Bruce Cran bruce.c...@gmail.com Cecil Sheng cecil.sh...@hp.com Chao Zhang chao.b.zh...@intel.com Chao, Zhang chao.b.zh...@intel.com Chen Fan chen.fan.f...@cn.fujitsu.com Chris Phillips chr...@hp.com Chris Ruffin chris.ruf...@intel.com Cinnamon Shia cinnamon.s...@hp.com Daryl McDaniel daryl.mcdan...@intel.com Daryl McDaniel daryl.mcdan...@intel.com daryl.mcdaniel daryl.mcdan...@intel.com daryl.mcdan...@intel.com darylm503 darylm503@Edk2 David Wei david@intel.com David Woodhouse david.woodho...@intel.com Deric Cole deric_c...@phoenix.com Dong Eric eric.d...@intel.com Dong Guo guo.d...@intel.com Dong, Guo guo.d...@intel.com Elvin Li elvin...@intel.com Eric Dong eric.d...@intel.com Erik Bjorge erik.c.bjo...@intel.com Eugene Cohen eug...@hp.com Feng Tian feng.t...@intel.com Feng, Bob C bob.c.f...@intel.com Fu Siyuan siyuan...@intel.com Fu, Siyuan siyuan...@intel.com Gabriel Somlo so...@cmu.edu Gao, Liming liming@intel.com Gao, Liming liming.gao Gao, Liming liming@intel.com Gao, Liming liming@intel.com Garrett Kirkendall garrett.kirkend...@amd.com Gary Lin g...@suse.com Grzegorz Milos gm...@cam.ac.uk Hao Wu hao.a...@intel.com Harry Liebel harry.lie...@arm.com Hess Chen hesheng.c...@intel.com Hot Tian hot.t...@intel.com isakov-sl isakov...@bk.ru isakov...@bk.ru Jaben Carsey jaben.car...@intel.com jcarsey jcarsey jcarsey jcarsey@Edk2 Jeff Bobzin (jeff.bobzin Jeff Bobzin (jeff.bob...@insyde.com) Jeff Bobzin (jeff.bob...@insyde.com) Jeff Fan jeff@intel.com Jiewen Yao jiewen@intel.com Joe Peterson joe.peter...@intel.com Jordan Justen jordan.l.jus...@intel.com jyao1 jyao1 jyao1 jyao1@Edk2 Kinney, Michael D michael.d.kin...@intel.com Larry Cleeton lclee...@microsoft.com Laszlo Ersek ler...@redhat.com Leandro G. Biss Becker lbec...@positivo.com.br Lee Leahy leroy.p.le...@intel.com Leif Lindholm leif.lindh...@linaro.org leroy.p.leahy leroy.p.le...@intel.com leroy.p.le...@intel.com lhauch larry.ha...@intel.com
