From: Amit Shah <amit.shah@qumranet.com>
To: Glauber Costa <gcosta@redhat.com>
Cc: kvm-devel@lists.sourceforge.net,
virtualization@lists.linux-foundation.org, muli@il.ibm.com,
BENAMI@il.ibm.com, chrisw@redhat.com, dor.laor@qumranet.com,
allen.m.kay@intel.com, avi@qumranet.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM x86: Handle hypercalls for assigned PCI devices
Date: Tue, 29 Apr 2008 21:28:51 +0530 [thread overview]
Message-ID: <200804292128.52268.amit.shah@qumranet.com> (raw)
In-Reply-To: <48173440.304@redhat.com>
On Tuesday 29 April 2008 20:14:16 Glauber Costa wrote:
> Amit Shah wrote:
> > +static struct kvm_pv_dma_map*
> > +find_pci_pv_dmap(struct list_head *head, dma_addr_t dma)
> > +{
>
> might be better to prefix those functions with kvm? Even though they are
> static, it seems to be the current practice.
The function names are long enough already. Prefixing everything with kvm_
could hurt the eye as well.
> > + host_page = gfn_to_page(vcpu->kvm, page_gfn);
>
> you need mmap_sem held for read to use gfn_to_page.
Yes; it's going to trickle down soon.
> > + /* FIXME: guest should send the direction */
> > + r = dma_ops->map_sg(NULL, sg, npages, PCI_DMA_BIDIRECTIONAL);
> > + if (r) {
> > + r = npages;
> > + *hcall_page = sg[0].dma_address | (*hcall_page & ~PAGE_MASK);
> > + }
> > +
> > + out_unmap:
> > + if (!r)
> > + *hcall_page = bad_dma_address;
> > + kunmap(host_page);
> > + out:
> > + ++vcpu->stat.hypercall_map;
> > + return r;
> > + out_unmap_sg_dmap:
> > + kfree(dmap);
> > + out_unmap_sg:
> > + kfree(sg);
> > + goto out_unmap;
>
> those backwards goto are very clumsy. Might be better to give it a
> further attention in order to avoid id.
It does keep everything nicely in one place though. You're right though. Some
more attention is needed.
> > +static int free_dmap(struct kvm_pv_dma_map *dmap, struct list_head
> > *head) +{
> > + int i;
> > +
> > + if (!dmap)
> > + return 1;
>
> that's ugly.
>
> it's better to keep the free function with free-like semantics: just a
> void function that plainly returns if !dmap, and check in the caller.
I was lazy and used the return value from here to propagate it down further.
But this kicked me to modify that.
> > + if (is_error_page(host_page)) {
> > + printk(KERN_INFO "%s: gfn %p not valid\n",
> > + __func__, (void *)page_gfn);
> > + r = -1;
>
> r = -1 is not really informative. Better use some meaningful error.
The error's going to the guest. The guest, as we know, has already done a
successful DMA allocation. Something went wrong in the hypercall, and we
don't know why (bad page). Any kind of error here isn't going to be
intelligible to the guest anyway. It's mostly a host thing if we ever hit
this.
> > + if (find_pci_pt_dev(&vcpu->kvm->arch.pci_pt_dev_head,
> > + &pci_pt_info, 0, KVM_PT_SOURCE_ASSIGN))
> > + r++; /* We have assigned the device */
> > +
> > + kunmap(host_page);
>
> better use atomic mappings here.
We can't use atomic mappings for guest pages. They can be swapped out.
next prev parent reply other threads:[~2008-04-29 15:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 10:37 PV DMA for PCI passthrough devices for KVM Amit Shah
2008-04-29 10:37 ` [PATCH] x86 DMA: Handle devices assigned to the guest by the host Amit Shah
2008-04-29 10:37 ` [PATCH] KVM x86: Handle hypercalls for assigned PCI devices Amit Shah
2008-04-29 10:37 ` [PATCH] KVM PV Guest: Implement paravirtualized DMA Amit Shah
2008-04-29 13:31 ` Andi Kleen
2008-04-29 13:59 ` Amit Shah
2008-04-29 14:44 ` [PATCH] KVM x86: Handle hypercalls for assigned PCI devices Glauber Costa
2008-04-29 15:58 ` Amit Shah [this message]
2008-04-29 22:48 ` Avi Kivity
2008-04-30 6:05 ` Muli Ben-Yehuda
2008-05-01 13:18 ` Amit Shah
2008-04-29 13:14 ` [PATCH] x86 DMA: Handle devices assigned to the guest by the host Andi Kleen
2008-04-29 13:49 ` Amit Shah
2008-04-30 6:29 ` Muli Ben-Yehuda
2008-04-29 13:15 ` PV DMA for PCI passthrough devices for KVM Andi Kleen
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=200804292128.52268.amit.shah@qumranet.com \
--to=amit.shah@qumranet.com \
--cc=BENAMI@il.ibm.com \
--cc=allen.m.kay@intel.com \
--cc=avi@qumranet.com \
--cc=chrisw@redhat.com \
--cc=dor.laor@qumranet.com \
--cc=gcosta@redhat.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=muli@il.ibm.com \
--cc=virtualization@lists.linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®