| Message ID | 20221128043623.1745708-1-npiggin@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [RFC] Disable Book-E KVM support? | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/github-powerpc_ppctests | success | Successfully ran 8 jobs. |
| snowpatch_ozlabs/github-powerpc_selftests | success | Successfully ran 8 jobs. |
| snowpatch_ozlabs/github-powerpc_sparse | success | Successfully ran 4 jobs. |
| snowpatch_ozlabs/github-powerpc_clang | success | Successfully ran 6 jobs. |
| snowpatch_ozlabs/github-powerpc_kernel_qemu | success | Successfully ran 24 jobs. |
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., > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html > > 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. 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 -Crystal
On Thu Dec 1, 2022 at 6:45 AM AEST, 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., > > > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html > > > > 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. > > 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. Well I could be wrong about it, but it doesn't look it implements LPIDR or GSPRs. The only use of MSR_GS seems to be a couple of places including an instruction that aborts because no HV implementation. It does have an MMU index selector but before d764184ddb22 that apparently didn't really work. QEMU probably should be able to run BookE KVM in PR mode at least. > 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. :-) Do you have a KVM setup on it? And it works with recentish upstream? > 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 Yeah that was probably reasonable at the time, that was the common way to do it and thie patch avoids an unnecessary expensive write to MSR (which my patch retains). I think it must have always clobbered r4 though. It's possible it wasn't tested with the right build option, or the right tracer active, or maybe the call was simple enough that it was lucky and the compiler didn't use r4. Easy bug to miss when it's not obvious that macro can call into C. Thanks, Nick
Am 1. Dezember 2022 06:06:16 UTC schrieb Nicholas Piggin <npiggin@gmail.com>: >On Thu Dec 1, 2022 at 6:45 AM AEST, 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., >> > >> > https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html >> > >> > 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. >> >> 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. Thanks for CCing! No, I'm not using KVM on e500. The goal of my patches is to run software in QEMU on an x86_64 host rather than on a real PPC machine to optimize our development process. Best regards, Bernhard >Well I could be wrong about it, but it doesn't look it implements LPIDR >or GSPRs. The only use of MSR_GS seems to be a couple of places >including an instruction that aborts because no HV implementation. It >does have an MMU index selector but before d764184ddb22 that apparently >didn't really work. > >QEMU probably should be able to run BookE KVM in PR mode at least. > >> 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. :-) > >Do you have a KVM setup on it? And it works with recentish upstream? > >> 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 > >Yeah that was probably reasonable at the time, that was the common way >to do it and thie patch avoids an unnecessary expensive write to MSR >(which my patch retains). > >I think it must have always clobbered r4 though. It's possible it wasn't >tested with the right build option, or the right tracer active, or maybe >the call was simple enough that it was lucky and the compiler didn't use >r4. Easy bug to miss when it's not obvious that macro can call into C. > >Thanks, >Nick
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., >> >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html >> >> 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 in emulated mode in an use case similar to what Bernhard described in his reply (run 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 without too much drama from our side. Cedric, do you have any opinions about it? Daniel > > 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 > > -Crystal > >
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., >>> >>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html >>> >>> 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 in > emulated mode in an use case similar to what Bernhard described in his reply (run > 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 without > 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 : https://lore.kernel.org/all/R4OPHT$7F12C66D1107397991E0E4C978FE6AF1@locati.it/ 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. Thanks, C. > > > > Daniel > > >> >> 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 >> >> -Crystal >> >>
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index a9f57dad6d91..6c9458741cb3 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -191,6 +191,7 @@ config KVM_EXIT_TIMING config KVM_E500V2 bool "KVM support for PowerPC E500v2 processors" + depends on false depends on PPC_E500 && !PPC_E500MC depends on !CONTEXT_TRACKING_USER select KVM @@ -207,6 +208,7 @@ config KVM_E500V2 config KVM_E500MC bool "KVM support for PowerPC E500MC/E5500/E6500 processors" + depends on false depends on PPC_E500MC depends on !CONTEXT_TRACKING_USER select KVM