From: Chris Metcalf <cmetcalf@tilera.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: <linux-kernel@vger.kernel.org>, <kvm@vger.kernel.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
Gleb Natapov <gleb@redhat.com>
Subject: Re: [PATCH v3 3/3] tile: enable VIRTIO support for KVM
Date: Mon, 30 Sep 2013 16:11:24 -0400 [thread overview]
Message-ID: <5249DAEC.2090106@tilera.com> (raw)
In-Reply-To: <522F14F8.2000101@redhat.com>
As I said to Gleb in the previous email - sorry for the delay in
replying to your thoughtful comments!
On 9/10/2013 8:47 AM, Paolo Bonzini wrote:
> Il 28/08/2013 22:58, Chris Metcalf ha scritto:
>> This change enables support for a virtio-based console,
>> network support, and block driver support.
>>
>> We remove some debug code in relocate_kernel_64.S that made raw
>> calls to the hv_console_putc Tilera hypervisor API, since everything
>> now should funnel through the early_hv_write() API.
>>
>> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
> Why couldn't this use the "regular" virtio-mmio interface?
We probably should! We were working with a CentOS 6 style distribution,
which has an older version of qemu; we upgraded slightly to 0.13 in
the thought that minimizing version skew would help distribution compatibility.
That version doesn't have the virtio-mmio stuff. But you're right, we probably
should return the virtio-mmio stuff to the community instead, even if we're
going to keep something like this patch in our local copy of KVM.
>> static void early_hv_write(struct console *con, const char *s, unsigned n)
>> {
>> +#ifdef CONFIG_KVM_GUEST
>> + char buf[512];
>> +
>> + if (n > sizeof(buf) - 1)
>> + n = sizeof(buf) - 1;
>> + memcpy(buf, s, n);
>> + buf[n] = '\0';
>> +
>> + hcall_virtio(KVM_VIRTIO_NOTIFY, __pa(buf));
> How can userspace know the difference between KVM_VIRTIO_NOTIFY with a
> string buffer, and KVM_VIRTIO_NOTIFY with a config space pointer?
>
> In fact, this looks like a completely separate hypercall, why not keep
> hv_console_putc?
Good point. Right now in qemu the virtio hypercall with a KVM_VIRTIO_NOTIFY
reason either does a virtio_queue_notify(), if the address is not in RAM,
or a print, if it is. It does seem we could just have separate calls;
the reason we grouped it in with the KVM_VIRTIO stuff instead of implementing
it with the hv_console_write() API is just that it uses the virtio_console
API to do the work. But we probably could do it the other way too, and
that might arguably make more sense. We'll think about it.
Thanks!
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
next prev parent reply other threads:[~2013-09-30 20:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-12 15:24 [PATCH] tile: support KVM for tilegx Chris Metcalf
2013-08-12 17:08 ` Jan Kiszka
2013-08-12 20:24 ` [PATCH v2] " Chris Metcalf
2013-08-25 11:39 ` Gleb Natapov
2013-08-26 1:26 ` Chris Metcalf
2013-08-26 12:04 ` Gleb Natapov
2013-08-28 19:45 ` [PATCH v3 1/3] tile: support KVM host mode Chris Metcalf
2013-09-10 10:53 ` Gleb Natapov
2013-09-10 11:59 ` Paolo Bonzini
2013-09-30 20:11 ` Chris Metcalf
2013-10-01 15:21 ` Gleb Natapov
2013-08-28 20:57 ` [PATCH v3 2/3] tile: enable building as a paravirtualized KVM_GUEST Chris Metcalf
2013-08-28 20:58 ` [PATCH v3 3/3] tile: enable VIRTIO support for KVM Chris Metcalf
2013-09-10 12:47 ` Paolo Bonzini
2013-09-30 20:11 ` Chris Metcalf [this message]
2013-10-01 6:39 ` Paolo Bonzini
2013-08-29 0:26 ` [PATCH v2] tile: support KVM for tilegx Chris Metcalf
2013-09-03 17:32 ` Chris Metcalf
2013-09-03 17:39 ` Gleb Natapov
2013-09-03 17:46 ` Chris Metcalf
2013-09-03 18:13 ` [PATCH 1/3] tile: clean up relocate_kernel_64 debug code Chris Metcalf
2013-09-03 18:41 ` [PATCH 3/3] tile: parameterize VA and PA space more cleanly Chris Metcalf
2013-09-03 18:45 ` [PATCH 2/3] tile: don't assume user privilege is zero Chris Metcalf
2013-09-03 19:09 ` [PATCH 0/3] tile prerequisites for KVM support Chris Metcalf
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=5249DAEC.2090106@tilera.com \
--to=cmetcalf@tilera.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).