From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58104)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1WW38D-00011a-BH
	for qemu-devel@nongnu.org; Fri, 04 Apr 2014 08:22:08 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1WW385-0008AY-Ru
	for qemu-devel@nongnu.org; Fri, 04 Apr 2014 08:22:01 -0400
Message-ID: <533EA3E1.8060006@suse.de>
Date: Fri, 04 Apr 2014 14:21:53 +0200
From: Alexander Graf <agraf@suse.de>
MIME-Version: 1.0
References: <1396530891-6352-1-git-send-email-aik@ozlabs.ru>
	<1396530891-6352-3-git-send-email-aik@ozlabs.ru>
	<533D5FED.4000905@suse.com> <533E4D85.8010803@ozlabs.ru>
In-Reply-To: <533E4D85.8010803@ozlabs.ru>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 2/4] spapr: Enable DABRX special register
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Alexander Graf <agraf@suse.com>

On 04/04/2014 08:13 AM, Alexey Kardashevskiy wrote:
> On 04/04/2014 12:19 AM, Alexander Graf wrote:
>> On 03.04.14 15:14, Alexey Kardashevskiy wrote:
>>> This advertises Data Address Breakpoint Register Extension (DABRX) to
>>> the guest via hyperrtas list and enables it to migrate.
>> Do all CPUs we support (970 anyone) have DABRX support?
> 970MP and 970FX do. Support them too? Who cares? :)

Well, we do support running KVM on these and for KVM we default to -cpu 
host, so they're important to keep in mind.

>
>> Also who handles this hcall in the TCG case?
> Good point...
>
>> What about older host kernels that don't
>> support xdabr yet?
> They will ignore FW_FEATURE_XDABR, no?

How does a host kernel ignore anything here? We're telling the guest 
that we support an hcall without asking the host at all.

>
>> What about PR KVM?
> Oh. Nothing. And we do not want to make this "hcall-xdabr" conditional,
> right? Drop the whole patch? I am really confused now.

I think we should properly check whether we can handle this hcall and/or 
implement a handler for TCG and hosts which don't handle it themselves.


Alex