[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] Disable Book-E KVM support?

From: Cédric Le Goater
Subject: Re: [RFC PATCH] Disable Book-E KVM support?
Date: Fri, 2 Dec 2022 12:38:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0

On 12/2/22 12:04, Daniel Henrique Barboza wrote:

On 11/30/22 17:45, Crystal Wood wrote:
On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote:
BookE KVM is in a deep maintenance state, I'm not sure how much testing
it gets. I don't have a test setup, and it does not look like QEMU has
any HV architecture enabled. It hasn't been too painful but there are
some cases where it causes a bit of problem not being able to test, e.g.,


Time to begin removal process, or are there still people using it? I'm
happy to to keep making occasional patches to try keep it going if
there are people testing upstream. Getting HV support into QEMU would
help with long term support, not sure how big of a job that would be.

Not sure what you mean about QEMU not having e500 HV support?  I don't know if
it's bitrotted, but it's there.

AFAIK all QEMU ppc boards, aside from pSeries and the Mac ones, are always used 
emulated mode in an use case similar to what Bernhard described in his reply 
in x86 due to lack of ppc hardware).

I am not aware of e500 KVM support in QEMU since I never attempted it. But yes,
it is present, but poorly tested - if tested at all. And the reason why there's
no push on our side to removed it from QEMU is because its code is so entwined
with pSeries KVM that it would take too much effort.

Do not take the presence of e500 KVM support in QEMU as a blocker to disabled 
it in
the kernel. As far as the current QEMU usage goes e500 KVM can be removed 
too much drama from our side.

Cedric, do you have any opinions about it?

I can not tell how much e500 KVM is used. The last report we had
on the topic was :


and the last commit mentioning e500 VMs I could find is cb3778a045,
which brings us back to QEMU 2.2 or so.

It would be nice to 'quickly' check the state of the KVM stack on
such boards and, may be, plan for more cleanups.




I don't know whether anyone is still using this, but if they are, it's
probably e500mc and not e500v2 (which involved a bunch of hacks to get almost-
sorta-usable performance out of hardware not designed for virtualization).  I
do see that there have been a few recent patches on QEMU e500 (beyond the
treewide cleanup type stuff), though I don't know if they're using KVM.  CCing
them and the QEMU list.

I have an e6500 I could occasionally test on, if it turns out people do still
care about this.  Don't count me as the use case, though. :-)

FWIW, as far as the RECONCILE_IRQ_STATE issue, that used to be done in
kvmppc_handle_exit(), but was moved in commit 9bd880a2c882 to be "cleaner and
faster". :-P


reply via email to

[Prev in Thread] Current Thread [Next in Thread]