On 21/04/2019 23:26, Mathieu Tarral wrote: Answering out of order.
> I discussed this bug on IRC with andyhpp, who convinced me to move the > discussion on the mailing list. > Apparently the singlestepping in Xen was in a poor quality state because of > multiple layers of refactoring. What I said was that x86 is a complete mess. Various aspects of debug behaviour aren't even documented, and have had to be reversed engineered after finding security vulnerabilities with how software handles them (caused by a lack of documentation). > I'm running on Xen packaged by Fedora 29: 4.11.1, in a nested virt > environment on top of KVM. I didn't realise you were nested on top of KVM. That definitely isn't helping things, and there is an equal chance that you've hit a nested virt bug in KVM. Please try and reproduce it without KVM, to rule out some of the complexity. > The funny thing is that it's always at the same instruction that it fails, > the 106th singlestep, > at 0x806d32dc: > > [0x7c90e514]> s 0x806d32dc > [0x806d32dc]> pd 10 > 0x806d32dc 890d8000feff mov dword [0xfffe0080], ecx This is a read of the APIC TPR, which is very commonly an operation accelerated by hardware (because without it, virtualising windows XP is exceedingly slow). What is your CPU, and how exactly are you trying to singlestep. Is it with MTF, or using the trap flag inside the guest? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
