+cc Gleb, KVM guys, On 12/09/2014 12:38 AM, Peter Maydell wrote: > On 8 December 2014 at 15:38, Igor Mammedov <imammedo@xxxxxxxxxx> wrote: >> On Mon, 8 Dec 2014 10:50:21 +0000 >> Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >>> Why can't the kernel handle our just destroying the vcpu and >>> later recreating it if necessary? That seems the more logical >>> approach than trying to keep fds hanging around in userspace >>> for reuse. >> >> It's somewhat complex approach and it was suggested on KVM list to go >> parking route. for more details see thread >> https://www.mail-archive.com/kvm@xxxxxxxxxxxxxxx/msg102839.html > > If the kernel can't cope with userspace creating and destroying > vCPUs dynamically then that seems like a kernel bug to me. Yes, it's a flaw. > It seems better to me to fix that directly rather than make > non-x86 architectures change things around to help with working > around that bug... Agree. But as we discussed before: "CPU array is accessed locklessly in a lot of places, so it will have to be RCUified. There was attempt to do so 2 year or so ago, but it didn't go anyware. Adding locks is to big a price to pay for ability to free a little bit of memory by destroying vcpu." We worry about the regression if we add lock in a lot of places. I'm not very familiar with non-x86 architectures. So I'm not sure how long we need to go to help "vcpu hot-unplug" working with parking route. Gleb, Is any guys still working on the RCUing CPUarray access? Is there any plan for this issue, or just leave it as it is? Thanks, Gu > > thanks > -- PMM > . > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
