All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carsten Otte <cotte@de.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: Marcelo Tossati <mtosatti@redhat.com>,
	borntrae@linux.vnet.ibm.com, heicars2@linux.vnet.ibm.com,
	mschwid2@linux.vnet.ibm.com, huckc@linux.vnet.ibm.com,
	KVM <kvm@vger.kernel.org>
Subject: Re: [patch 2/2] [PATCH] kvm-s390: pseudo page fault support
Date: Thu, 17 Nov 2011 14:38:39 +0100	[thread overview]
Message-ID: <4EC50E5F.6040202@de.ibm.com> (raw)
In-Reply-To: <4EC5098B.70101@redhat.com>

On 17.11.2011 14:18, Avi Kivity wrote:
>> +	copy_from_guest(vcpu,&pfault_token, vcpu->arch.pfault_token,
>> +			8);
>
> Missing error check?
Good catch, will fix.

>> +	init = kzalloc(sizeof(*init), GFP_ATOMIC);
>> +	if (!init)
>> +		return;
>> +
>> +	done = kzalloc(sizeof(*done), GFP_ATOMIC);
>> +	if (!done)
>> +		goto out_init;
>> +
>> +	event = kzalloc(sizeof(*event), GFP_ATOMIC);
>> +	if (!event)
>> +		goto out_done;
>
> Three allocs?  Maybe combine them?  Even if their lifetimes are not
> exactly the same.
The interrupt stack frees the interrupt info types for done and
init in context of the target vcpu thread when delivering. Thus,
as far as I can see, these cannot be easily converged.

> Is this duplicating virt/kvm/async_pf.c?
We intend to be able to backport this to 2.6.32 for RHEL6. async_pf.c
relies on asynchonous work items which is not available on RHEL6. Thus
we decided to go forward with our own implementation first, and move 
towards an aproach similar to async_pf.c as soon as we find time for
it. I think in the end both pathes can and should be converged. The
implementation in async_pf.c clearly has advantages over this approach.

  reply	other threads:[~2011-11-17 13:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-17 11:19 [patch 0/2] kvm-s390: asnychronous page faults Carsten Otte
2011-11-17 11:19 ` [patch 1/2] [PATCH] kvm: nowait retry for asynchronous " Carsten Otte
2011-11-17 11:19 ` [patch 2/2] [PATCH] kvm-s390: pseudo page fault support Carsten Otte
2011-11-17 13:18   ` Avi Kivity
2011-11-17 13:38     ` Carsten Otte [this message]
2011-11-17 14:18       ` Avi Kivity
2011-11-17 14:50         ` Carsten Otte
2011-11-17 15:13     ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EC50E5F.6040202@de.ibm.com \
    --to=cotte@de.ibm.com \
    --cc=avi@redhat.com \
    --cc=borntrae@linux.vnet.ibm.com \
    --cc=heicars2@linux.vnet.ibm.com \
    --cc=huckc@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=mschwid2@linux.vnet.ibm.com \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.