Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On 9/21/2015 9:36 AM, Linus Torvalds wrote: On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote: Linus, what's your preference? So quite frankly, is there any reason we don't just implement native_read_msr() as just unsigned long long native_read_msr(unsigned int msr)

Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

( We should double check that rdmsr()/wrmsr() results are never left uninitialized, but are set to zero or so, for cases where the return code is not checked. ) It sure looks like native_read_msr_safe doesn't clear the output if the rdmsr fails. I'd suggest to return some poison not

Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 9/17/2015 8:29 AM, Paolo Bonzini wrote: On 17/09/2015 17:27, Arjan van de Ven wrote: ( We should double check that rdmsr()/wrmsr() results are never left uninitialized, but are set to zero or so, for cases where the return code is not checked. ) It sure looks like

Re: Should KVM_GUEST stop depending on PARAVIRT?

On 7/27/2015 11:45 AM, Andy Lutomirski wrote: With PARAVIRT=y it never #GPs: .read_msr = native_read_msr_safe, .write_msr = native_write_msr_safe, I don't remember if it's this way on bare-metal too. Oh, whoops, I missed the _safe. IMO that's just a bug, and I guess KVM

Re: [PATCH v2] core, x86: Add user return notifiers

on user return or context switch fast paths. Ingo/Peter? isn't this like really expensive when used ? -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from

Re: [PATCH] regression: vmalloc easily fail.

for that missing -1 ... -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info

Re: [PATCH 0/9][RFC] stackable dma_ops for x86

with paravirtualized device passthrough or if a hardware IOMMU only handles a subset of available devices). isn't the right answer here to have a per device DMA ops instead ? -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http

Re: [PATCH 0/9][RFC] stackable dma_ops for x86

functions get a device as argument already anyway; just going to bus makes no sense there. Even if you set it the same for the whole bus almost all of the time... the APIs just work per device. (and device assignment clearly is per device as well) -- Arjan van de VenIntel Open Source