headers
Xiao Guangrong | 1 Apr 2012 05:38
Picon

Re: High Level Proof of The Correctness of Dirty Page Tracking

On 03/31/2012 11:12 PM, Takuya Yoshikawa wrote:

> This is what I wanted to read before starting GET_DIRTY_LOG work: about
> possible race between VCPU threads and GET_DIRTY_LOG thread.
> 
> Although most things look trivial, there seem to be some interesting assumptions
> the correctness is based on including mmu lock usage.
> 
> 	Takuya
> 
> ===
> About MMU Page Fault Path:
> 1. Set bit in dirty bitmap
> 2. Make spte writable
> 3. Guest re-execute the write
> 
> If GET_DIRTY_LOG is allowed to write protect the page between step 1 and 2,
> that page will be made writable again at step 2 and the write at step 3 will
> not be caught.  Since the userspace can process that page before step 3, the
> written data may be lost.  To avoid this mmu lock must be held correctly in
> both sides as the current implementation does.
> 

Hmm, according to (*2), if we set the dirty bit after make spte writeable,
it should be safe without holding mmu-lock?

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael S. Tsirkin | 1 Apr 2012 12:57
Picon
Favicon

Re: [Qemu-devel] [PATCH] kvm: deassign irqs in reset path

On Sat, Mar 31, 2012 at 12:15:34AM +0200, Jan Kiszka wrote:
> On 2012-03-30 23:09, Alex Williamson wrote:
> > On Fri, 2012-03-30 at 22:35 +0200, Jan Kiszka wrote:
> >> On 2012-03-30 22:31, Jason Baron wrote:
> >>> On Fri, Mar 30, 2012 at 10:18:31PM +0200, Jan Kiszka wrote:
> >>>>>>> The root cause of the problem is that the 'reset_assigned_device()' code
> >>>>>>> first writes a 0 to the command register. Then, when qemu subsequently does
> >>>>>>> a kvm_deassign_irq() (called by assign_irq(), in the system_reset path),
> >>>>>>> the kernel ends up calling '__msix_mask_irq()', which performs a write to
> >>>>>>> the memory mapped msi vector space. Since, we've explicitly told the device
> >>>>>>> to disallow mmio access (via the 0 write to the command register), we end
> >>>>>>> up with the above 'Unsupported Request'.
> >>>>>>>
> >>>>>>> The fix here is to first call kvm_deassign_irq(), before doing the reset,
> >>>>>>
> >>>>>> s/fix/workaround/. This is a kernel bug if userspace can crash the
> >>>>>> system like this, no? Let's fix the kernel first and then look at what
> >>>>>> needs to be changed here.
> >>>>>>
> >>>>>> Jan
> >>>>>>
> >>>>>
> >>>>> But don't I need special privalege to run the device assignment bits?
> >>>>
> >>>> Yes, but even that might be moderated by a management component like
> >>>> libvirt.
> >>>>
> >>>>> For example, this crash is precipitated by a write of '0' to the pci
> >>>>> device config register from userspace. Surely, not every is allowed to
> >>>>> do that write. So it seems to me, that this patch is in keeping with the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Avi Kivity | 1 Apr 2012 14:38
Picon
Favicon

Re: [GIT PULL] KVM updates for the 3.4 merge window

On 03/30/2012 03:01 PM, Paul Mackerras wrote:
> I just noticed that the branch you asked Linus to pull includes none
> of the patches that Alex sent you in the last batch, in the email with
> subject "[PULL 00/56] ppc patch queue 2012-03-15" sent on March 15,
> where he asked you to pull git://github.com/agraf/linux-2.6.git
> for-upstream.
>
> What happened?  Did they get lost in the re-signing, or is there some
> reason you thought they shouldn't go in?

That pull request was send three days before the merge window opened;
patches are supposed to cook for a while in -next before being merged,
especially large trees like that one.

--

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 12 comments |
headers
Avi Kivity | 1 Apr 2012 14:42
Picon
Favicon

Re: [PATCH 04/13] KVM: MMU: introduce FNAME(get_sp_gpa)

On 03/30/2012 08:01 AM, Xiao Guangrong wrote:
> On 03/29/2012 09:07 PM, Avi Kivity wrote:
>
> > On 03/29/2012 11:22 AM, Xiao Guangrong wrote:
> >> It can calculate the base gpa of the specified shadow page on any level,
> >> let it instead of FNAME(get_level1_sp_gpa)
> >>
> >>
> >> +static gpa_t FNAME(get_sp_gpa)(struct kvm_mmu_page *sp)
> >> +{
> > 
> > Maybe worth adding a pte index and calling it get_spte_gpa(), depends on
> > the next patches I guess.
> > 
>
>
> Yes.
>
> But FNAME(get_sp_gpa) is still needed by FNAME(sync_page) path which sync
> all sptes. I will introduce get_spte_gpa() as you mentioned which will be
> used in invlpg path and in the later patch.
>
>
> >> +	int offset, shift;
> >> +
> >> +	shift = PAGE_SHIFT - (PT_LEVEL_BITS - PT64_LEVEL_BITS) * sp->role.level;
> >> +	offset = sp->role.quadrant << shift;
> > 
> > if you add '& ~PAGE_MASK' the compiler may be smart enough to drop the
> > whole thing for 64-bit ptes.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Apr 2012 16:15

[Bug 42779] KVM domain hangs after loading initrd with Xenomai kernel

https://bugzilla.kernel.org/show_bug.cgi?id=42779

--- Comment #22 from Avi Kivity <avi <at> redhat.com>  2012-04-01 14:15:51 ---
No guarantees of course, but this is just 3.3-rc5 with a few patches on top. 
It should be fine for a short test.

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Avi Kivity | 1 Apr 2012 17:53
Picon
Favicon

Re: [PATCH 09/13] KVM: MMU: get expected spte out of mmu-lock

On 03/29/2012 11:25 AM, Xiao Guangrong wrote:
> It depends on PTE_LIST_WRITE_PROTECT bit in rmap which let us quickly know
> whether the page is writable out of mmu-lock
>
> Signed-off-by: Xiao Guangrong <xiaoguangrong <at> linux.vnet.ibm.com>
> ---
>  arch/x86/kvm/mmu.c         |   17 +++++++++++++----
>  arch/x86/kvm/paging_tmpl.h |    2 +-
>  2 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 3887a07..c029185 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
>  <at>  <at>  -1148,6 +1148,12  <at>  <at>  static int rmap_write_protect(struct kvm *kvm, u64 gfn)
>
>  	*rmapp |= PTE_LIST_WRITE_PROTECT;
>
> +	/*
> +	 * Setting PTE_LIST_WRITE_PROTECT bit before doing page
> +	 * write-protect.
> +	 */
> +	smp_mb();
> +

wmb only needed.

Would it be better to store this bit in all the sptes instead?  We're
touching them in any case.  More work to clear them, but
un-write-protecting a page is beneficial anyway as it can save a fault.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Avi Kivity | 1 Apr 2012 18:23
Picon
Favicon

Re: [PATCH 11/13] KVM: MMU: fast path of handling guest page fault

On 03/29/2012 11:27 AM, Xiao Guangrong wrote:
> If the the present bit of page fault error code is set, it indicates
> the shadow page is populated on all levels, it means what we do is only
> modify the access bit which can be done out of mmu-lock
>
> The tricks in this patch is avoiding the race between fast page fault
> path and write-protect path, write-protect path is a read-check-modify
> path:
> read spte, check W bit, then clear W bit. What we do is populating a
> identification in spte, if write-protect meets it, it modify the spte
> even if the spte is readonly. See the comment in the code to get more
> information
>
> +
> +static bool page_fault_can_be_fast(struct kvm_vcpu *vcpu, gfn_t gfn,
> +				   u32 error_code)
> +{
> +	unsigned long *rmap;
> +	bool write = error_code & PFERR_WRITE_MASK;
> +
> +	/*
> +	 * #PF can be fast only if the shadow page table is present, that
> +	 * means we just need change the access bits (e.g: R/W, U/S...)
> +	 * which can be done out of mmu-lock.
> +	 */
> +	if (!(error_code & PFERR_PRESENT_MASK))
> +		return false;
> +
> +	if (unlikely(vcpu->vcpu_id > max_vcpu_spte()))
> +		return false;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Benjamin Herrenschmidt | 1 Apr 2012 23:02

Re: [GIT PULL] KVM updates for the 3.4 merge window

On Sun, 2012-04-01 at 15:38 +0300, Avi Kivity wrote:
> On 03/30/2012 03:01 PM, Paul Mackerras wrote:
> > I just noticed that the branch you asked Linus to pull includes none
> > of the patches that Alex sent you in the last batch, in the email with
> > subject "[PULL 00/56] ppc patch queue 2012-03-15" sent on March 15,
> > where he asked you to pull git://github.com/agraf/linux-2.6.git
> > for-upstream.
> >
> > What happened?  Did they get lost in the re-signing, or is there some
> > reason you thought they shouldn't go in?
> 
> That pull request was send three days before the merge window opened;
> patches are supposed to cook for a while in -next before being merged,
> especially large trees like that one.

These are all powerpc specific patches that have been cooking in Alex
tree for a while and elsewhere before that. They almost only affect
arch/powerpc/kvm, and as such don't really need a lot of integration
testing in -next. A bit for sure but not necessarily monthes.

The current process is such that it takes absolutely forever for our
patches to get in, which is a major PITA for something in such state of
active development.

Why don't we have Alex tree go straight to -next like I do with Kumar
for example ? That way I don't need to have his branch sit in my tree
for weeks before I push it out to Linus.

Cheers,
Ben.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Paul Mackerras | 2 Apr 2012 00:45
Picon
Favicon

Re: [GIT PULL] KVM updates for the 3.4 merge window

On Sun, Apr 01, 2012 at 03:38:37PM +0300, Avi Kivity wrote:
> On 03/30/2012 03:01 PM, Paul Mackerras wrote:
> > I just noticed that the branch you asked Linus to pull includes none
> > of the patches that Alex sent you in the last batch, in the email with
> > subject "[PULL 00/56] ppc patch queue 2012-03-15" sent on March 15,
> > where he asked you to pull git://github.com/agraf/linux-2.6.git
> > for-upstream.
> >
> > What happened?  Did they get lost in the re-signing, or is there some
> > reason you thought they shouldn't go in?
> 
> That pull request was send three days before the merge window opened;
> patches are supposed to cook for a while in -next before being merged,
> especially large trees like that one.

OK.  Then there are about six commits from that string that are small,
simple fixes for bugs introduced in earlier patches, that only affect
arch/powerpc.  They should go into Linus' tree as soon as possible.

How do you want to handle those?  Do you want them as patches or as a
git tree, and if the latter, what do you prefer that I base them on?
Or should I send them in via Ben?

Paul.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 2 Apr 2012 01:38

[Bug 42779] KVM domain hangs after loading initrd with Xenomai kernel

https://bugzilla.kernel.org/show_bug.cgi?id=42779

--- Comment #23 from madengineer10 <at> gmail.com  2012-04-01 23:38:21 ---
Now it dies in a different place, still with a movq instruction (movq  
(%edx),%mm0). I think the difference is because of a configuration change or
package update since the last test, because the fault happens at the same
address and same instruction under both the patched 3.3rc5 and 3.0.20.
Unfortunately I've no idea what the configuration change might have been, and I
didn't think to save a VM disk image from the previous tests.

I also got a more recent trace-cmd built and installed, so there is usable
trace output now. Still huge, so I'll post the last 10k lines as before.

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane