On Mon, 2014-05-05 at 16:43 +0200, Alexander Graf wrote:
Paul mentioned that BOOK3S always had DAR value set on alignment
interrupt. And the patch is to enable/collect correct DAR value when
running with Little Endian PR guest. Now to limit the impact and to
enable Little Endian PR guest,
On Mon, 2014-05-05 at 19:56 +0530, Aneesh Kumar K.V wrote:
Paul mentioned that BOOK3S always had DAR value set on alignment
interrupt. And the patch is to enable/collect correct DAR value when
running with Little Endian PR guest. Now to limit the impact and to
enable Little Endian PR guest,
On Mon, 2014-05-05 at 16:43 +0200, Alexander Graf wrote:
Paul mentioned that BOOK3S always had DAR value set on alignment
interrupt. And the patch is to enable/collect correct DAR value when
running with Little Endian PR guest. Now to limit the impact and to
enable Little Endian PR guest,
On Mon, 2014-03-03 at 11:24 +0800, Gavin Shan wrote:
The problem is specific to the case of BIST issued applied to IPR
adapter on the guest side. After BIST reset, we lose everything
in MSIx table and we never have chance update MSIx messages for
those enabled interrupts to MSIx table.
The
On Mon, 2014-03-03 at 15:43 +1100, Alexey Kardashevskiy wrote:
While it works for our particular problem and seems correct, it has one
flaw - hw/pci/msix.c will not generate this backtrace if masking bit does
not change which can happen in general:
===
static void
On Sun, 2014-03-02 at 21:49 -0700, Alex Williamson wrote:
I understand from talking to Alexey that the BARs are reset by this
BIST, but what about the MSIX capability? If that gets reset to be
disabled, where does it get re-enabled?
The guest will do pci_save/restore_state iirc which will
On Fri, 2014-02-21 at 16:31 +0100, Laurent Dufour wrote:
This fix introduces the H_GET_TCE hypervisor call which is basically the
reverse of H_PUT_TCE, as defined in the Power Architecture Platform
Requirements (PAPR).
The hcall H_GET_TCE is required by the kdump kernel which is calling it
On Fri, 2014-02-21 at 16:31 +0100, Laurent Dufour wrote:
This fix introduces the H_GET_TCE hypervisor call which is basically the
reverse of H_PUT_TCE, as defined in the Power Architecture Platform
Requirements (PAPR).
The hcall H_GET_TCE is required by the kdump kernel which is calling it
On Wed, 2014-01-29 at 17:39 +0100, Alexander Graf wrote:
static inline mfvtb(unsigned long)
{
#ifdef CONFIG_PPC_BOOK3S_64
return mfspr(SPRN_VTB);
#else
BUG();
#endif
}
is a lot easier to read and get right. But reg.h is Ben's call.
Agreed.
Also could you please give me a
On Thu, 2014-01-30 at 09:54 +1100, Benjamin Herrenschmidt wrote:
On Wed, 2014-01-29 at 17:39 +0100, Alexander Graf wrote:
static inline mfvtb(unsigned long)
{
#ifdef CONFIG_PPC_BOOK3S_64
return mfspr(SPRN_VTB);
#else
BUG();
#endif
}
is a lot easier to read and get
On Wed, 2014-01-29 at 17:39 +0100, Alexander Graf wrote:
static inline mfvtb(unsigned long)
{
#ifdef CONFIG_PPC_BOOK3S_64
return mfspr(SPRN_VTB);
#else
BUG();
#endif
}
is a lot easier to read and get right. But reg.h is Ben's call.
Agreed.
Also could you please give me a
On Wed, 2014-01-22 at 17:29 +, Peter Maydell wrote:
Basically if it would be on real bus, get byte value
that corresponds to phys_addr + 0 address place
it into data[0], get byte value that corresponds to
phys_addr + 1 address place it into data[1], etc.
This just isn't how real
On Wed, 2014-01-22 at 11:29 -0800, Victor Kamensky wrote:
I don't see why you so attached to desire to describe
data part of memory transaction as just one of int
types. If we are talking about bunch of hypothetical
cases imagine such bus that allow transaction with
size of 6 bytes. How do
On Wed, 2014-01-22 at 20:02 +, Peter Maydell wrote:
Defining it as being always guest-order would mean that
userspace had to continually look at the guest CPU
endianness bit, which is annoying and awkward.
Defining it as always host-endian order is the most
reasonable option
On Tue, 2014-01-28 at 11:07 +1100, Benjamin Herrenschmidt wrote:
On Thu, 2014-01-23 at 15:33 +, Peter Maydell wrote:
(4) PPC CPUs in BE mode and ARM CPUs in BE mode are not
the same, because in the ARM case it is doing an
internal-to-CPU byteswap, and in the PPC case
On Thu, 2014-01-23 at 15:33 +, Peter Maydell wrote:
(4) PPC CPUs in BE mode and ARM CPUs in BE mode are not
the same, because in the ARM case it is doing an
internal-to-CPU byteswap, and in the PPC case it is not
Aren't they both byte-order invariant ?
In that case they are the
The point is simple, and Peter has made it over and over:
Any consumer of a memory operation sees value, len, address.
This is what KVM_EXIT_MMIO emulates. So just by knowing the ABI
definition and having a pointer to the structure you need to be able to
tell me value, len, address.
But
On Thu, 2014-01-23 at 20:11 -0800, Victor Kamensky wrote:
I would take 50 byteswaps with a clear ABI any day over an obscure
standard that can avoid a single hardware-on-register instruction.
This
is about designing a clean software interface, not about building an
optimized integrated
On Mon, 2014-01-27 at 23:49 +, Peter Maydell wrote:
Er, what? If we make the array be guest's current order
then by definition userspace has to look at the guest's
current endianness. I agree that would be bad. Either
of the two current proposals (host kernel order; guest
CPU's
On Wed, 2014-01-22 at 19:38 -0500, Paul Gortmaker wrote:
Thanks, it was a great help as it uncovered a few issues in fringe arch
that I didn't have toolchains for, and I've fixed all of those up.
I've noticed that powerpc has been un-buildable for a while now; I have
used this hack patch
On Mon, 2014-01-27 at 16:44 -0800, Christoffer Dall wrote:
I'm loosing track of this discussion, Ben, can you explain a bit? You
wrote:
Having a byte array coming in that represents what the CPU does in its
current byte order means you do *NOT* need to query the endianness of
the
On Tue, 2013-12-10 at 15:40 +0100, Alexander Graf wrote:
On 10.12.2013, at 15:21, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We already checked need_resched. So we can call schedule directly
Signed-off-by: Aneesh
On Tue, 2013-12-10 at 23:48 +0100, Peter Zijlstra wrote:
Yeah, I went on holidays and the patch just sat there. I'll prod Ingo
into merging it.
Thanks !
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
On Tue, 2013-12-10 at 15:40 +0100, Alexander Graf wrote:
On 10.12.2013, at 15:21, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We already checked need_resched. So we can call schedule directly
Signed-off-by: Aneesh
On Tue, 2013-12-03 at 23:21 +0100, Andrea Arcangeli wrote:
#ifdef CONFIG_PPC_FSL_BOOK3E
hugepd_free(tlb, hugepte);
^^
This is the culprit
(Alex, you didn't specify this was embedded or did I miss it ?)
#else
pgtable_free_tlb(tlb, hugepte,
On Tue, 2013-12-03 at 23:21 +0100, Andrea Arcangeli wrote:
#ifdef CONFIG_PPC_FSL_BOOK3E
hugepd_free(tlb, hugepte);
^^
This is the culprit
(Alex, you didn't specify this was embedded or did I miss it ?)
#else
pgtable_free_tlb(tlb, hugepte,
On Thu, 2013-11-07 at 09:14 +0100, Alexander Graf wrote:
And ? An explanation isn't going to be clearer than the code in that
case ...
It's pretty non-obvious when you do a git show on that patch in 1 year
from now, as the redundancy is out of scope of what the diff shows.
And ? How would
On Fri, 2013-11-08 at 04:10 +0100, Alexander Graf wrote:
On 08.11.2013, at 03:44, Liu Ping Fan kernelf...@gmail.com wrote:
syscall is a very common behavior inside guest, and this patch
optimizes the path for the emulation of BOOK3S_INTERRUPT_SYSCALL,
so hypervisor can return to guest
On Thu, 2013-11-07 at 08:52 +0100, Alexander Graf wrote:
Am 06.11.2013 um 20:58 schrieb Benjamin Herrenschmidt
b...@kernel.crashing.org:
On Wed, 2013-11-06 at 12:24 +0100, Alexander Graf wrote:
On 05.11.2013, at 08:42, Liu Ping Fan kernelf...@gmail.com wrote:
Signed-off-by: Liu Ping
On Sun, 2013-11-03 at 16:30 +0200, Gleb Natapov wrote:
On Thu, Oct 31, 2013 at 10:18:19PM +0100, Alexander Graf wrote:
From: Bharat Bhushan r65...@freescale.com
This way we can use same data type struct with KVM and
also help in using other debug related function.
Signed-off-by:
On Mon, 2013-11-04 at 07:43 +0100, Alexander Graf wrote:
Yeah, it's what Ben and me agreed on after I waited forever to get a
topic branch created. Oh well, I guess this time we just have to
manually resolve the conflicts and do a better job at communicating
next time.
That specific one was
On Sun, 2013-11-03 at 16:30 +0200, Gleb Natapov wrote:
On Thu, Oct 31, 2013 at 10:18:19PM +0100, Alexander Graf wrote:
From: Bharat Bhushan r65...@freescale.com
This way we can use same data type struct with KVM and
also help in using other debug related function.
Signed-off-by:
On Mon, 2013-11-04 at 07:43 +0100, Alexander Graf wrote:
Yeah, it's what Ben and me agreed on after I waited forever to get a
topic branch created. Oh well, I guess this time we just have to
manually resolve the conflicts and do a better job at communicating
next time.
That specific one was
On Thu, 2013-10-03 at 08:43 +0300, Gleb Natapov wrote:
Why it can be a bad idea? User can drain hwrng continuously making other
users of it much slower, or even worse, making them fall back to another
much less reliable, source of entropy.
Not in a very significant way, we generate entropy at
On Thu, 2013-10-03 at 08:43 +0300, Gleb Natapov wrote:
Why it can be a bad idea? User can drain hwrng continuously making other
users of it much slower, or even worse, making them fall back to another
much less reliable, source of entropy.
Not in a very significant way, we generate entropy at
On Wed, 2013-10-02 at 10:46 +0200, Paolo Bonzini wrote:
Thanks. Any chance you can give some numbers of a kernel hypercall and
a userspace hypercall on Power, so we have actual data? For example a
hypercall that returns H_PARAMETER as soon as possible.
I don't have (yet) numbers at hand
On Wed, 2013-10-02 at 11:11 +0200, Alexander Graf wrote:
Right, and the difference for the patch in question is really whether
we handle in in kernel virtual mode or in QEMU, so the bulk of the
overhead (kicking threads out of guest context, switching MMU
context, etc) happens either way.
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
Yes, I alluded to it in my email to Paul and Paolo asked also. How this
interface is disabled? Also hwrnd is MMIO in a host why guest needs to
use hypercall instead of emulating the device (in kernel or somewhere
else?).
Migration will
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
Yes, I alluded to it in my email to Paul and Paolo asked also. How this
interface is disabled? Also hwrnd is MMIO in a host why guest needs to
use hypercall instead of emulating the device (in kernel or somewhere
else?). Another things is
On Wed, 2013-10-02 at 16:08 +0200, Alexander Graf wrote:
A guest should live on the same permission level as a user space
application. If you run QEMU as UID 1000 without access to /dev/mem,
why should the guest suddenly be able to directly access a memory
location (MMIO) it couldn't access
On Wed, 2013-10-02 at 17:10 +0300, Gleb Natapov wrote:
The hwrng is accessible by host userspace via /dev/mem.
Regular user has no access to /dev/mem, but he can start kvm guest and
gain access to the device.
Seriously. You guys are really trying hard to make our life hell or
what ? That
On Wed, 2013-10-02 at 17:37 +0300, Gleb Natapov wrote:
On Wed, Oct 02, 2013 at 04:33:18PM +0200, Paolo Bonzini wrote:
Il 02/10/2013 16:08, Alexander Graf ha scritto:
The hwrng is accessible by host userspace via /dev/mem.
A guest should live on the same permission level as a user
On Wed, 2013-10-02 at 10:46 +0200, Paolo Bonzini wrote:
Thanks. Any chance you can give some numbers of a kernel hypercall and
a userspace hypercall on Power, so we have actual data? For example a
hypercall that returns H_PARAMETER as soon as possible.
I don't have (yet) numbers at hand
On Wed, 2013-10-02 at 11:11 +0200, Alexander Graf wrote:
Right, and the difference for the patch in question is really whether
we handle in in kernel virtual mode or in QEMU, so the bulk of the
overhead (kicking threads out of guest context, switching MMU
context, etc) happens either way.
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
Yes, I alluded to it in my email to Paul and Paolo asked also. How this
interface is disabled? Also hwrnd is MMIO in a host why guest needs to
use hypercall instead of emulating the device (in kernel or somewhere
else?).
Migration will
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
Yes, I alluded to it in my email to Paul and Paolo asked also. How this
interface is disabled? Also hwrnd is MMIO in a host why guest needs to
use hypercall instead of emulating the device (in kernel or somewhere
else?). Another things is
On Wed, 2013-10-02 at 17:10 +0300, Gleb Natapov wrote:
The hwrng is accessible by host userspace via /dev/mem.
Regular user has no access to /dev/mem, but he can start kvm guest and
gain access to the device.
Seriously. You guys are really trying hard to make our life hell or
what ? That
On Wed, 2013-10-02 at 17:37 +0300, Gleb Natapov wrote:
On Wed, Oct 02, 2013 at 04:33:18PM +0200, Paolo Bonzini wrote:
Il 02/10/2013 16:08, Alexander Graf ha scritto:
The hwrng is accessible by host userspace via /dev/mem.
A guest should live on the same permission level as a user
On Tue, 2013-10-01 at 11:39 +0300, Gleb Natapov wrote:
On Tue, Oct 01, 2013 at 06:34:26PM +1000, Michael Ellerman wrote:
On Thu, Sep 26, 2013 at 11:06:59AM +0200, Paolo Bonzini wrote:
Il 26/09/2013 08:31, Michael Ellerman ha scritto:
Some powernv systems include a hwrng. Guests can
On Tue, 2013-10-01 at 13:19 +0200, Paolo Bonzini wrote:
Il 01/10/2013 11:38, Benjamin Herrenschmidt ha scritto:
So for the sake of that dogma you are going to make us do something that
is about 100 times slower ? (and possibly involves more lines of code)
If it's 100 times slower
On Tue, 2013-10-01 at 11:39 +0300, Gleb Natapov wrote:
On Tue, Oct 01, 2013 at 06:34:26PM +1000, Michael Ellerman wrote:
On Thu, Sep 26, 2013 at 11:06:59AM +0200, Paolo Bonzini wrote:
Il 26/09/2013 08:31, Michael Ellerman ha scritto:
Some powernv systems include a hwrng. Guests can
On Tue, 2013-10-01 at 13:19 +0200, Paolo Bonzini wrote:
Il 01/10/2013 11:38, Benjamin Herrenschmidt ha scritto:
So for the sake of that dogma you are going to make us do something that
is about 100 times slower ? (and possibly involves more lines of code)
If it's 100 times slower
On Thu, 2013-09-26 at 16:31 +1000, Michael Ellerman wrote:
+ pr_info_once(registering arch random hook\n);
Either pr_debug or make it nicer looking :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
On Thu, 2013-09-26 at 16:31 +1000, Michael Ellerman wrote:
+ pr_info(registered powernv hwrng.\n);
First letter of a line should get a capital :-) Also since
it's per-device, at least indicate the OF path or the chip number or
something ...
Cheers,
Ben.
--
To unsubscribe from this
On Thu, 2013-09-26 at 16:31 +1000, Michael Ellerman wrote:
+ pr_info_once(registering arch random hook\n);
Either pr_debug or make it nicer looking :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
On Thu, 2013-09-26 at 16:31 +1000, Michael Ellerman wrote:
+ pr_info(registered powernv hwrng.\n);
First letter of a line should get a capital :-) Also since
it's per-device, at least indicate the OF path or the chip number or
something ...
Cheers,
Ben.
--
To unsubscribe from this
early on, and set the thread priority to the medium level, so that
the interrupt handling code runs at a reasonable speed.
Signed-off-by: Paul Mackerras pau...@samba.org
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Alex, can you take this via your tree ?
Cheers,
Ben
early on, and set the thread priority to the medium level, so that
the interrupt handling code runs at a reasonable speed.
Signed-off-by: Paul Mackerras pau...@samba.org
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Alex, can you take this via your tree ?
Cheers,
Ben
On Fri, 2013-09-13 at 10:17 +1000, Paul Mackerras wrote:
Aneesh and I are currently investigating an alternative approach,
which is much more like the x86 way of doing things. We are looking
at splitting the code into three modules: a kvm_pr.ko module with the
PR-specific bits, a kvm_hv.ko
On Fri, 2013-09-13 at 10:17 +1000, Paul Mackerras wrote:
Aneesh and I are currently investigating an alternative approach,
which is much more like the x86 way of doing things. We are looking
at splitting the code into three modules: a kvm_pr.ko module with the
PR-specific bits, a kvm_hv.ko
On Tue, 2013-09-03 at 13:53 +0300, Gleb Natapov wrote:
Or supporting all IOMMU links (and leaving emulated stuff as is) in on
device is the last thing I have to do and then you'll ack the patch?
I am concerned more about API here. Internal implementation details I
leave to powerpc experts
On Tue, 2013-09-03 at 13:53 +0300, Gleb Natapov wrote:
Or supporting all IOMMU links (and leaving emulated stuff as is) in on
device is the last thing I have to do and then you'll ack the patch?
I am concerned more about API here. Internal implementation details I
leave to powerpc experts
On Fri, 2013-08-30 at 16:01 +0200, Alexander Graf wrote:
- The TM state is offset bu 0x1000. Other than being bigger than
the
SPR space, it's fairly arbitrarily chose.
Make it higher, just in case
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On Tue, 2013-08-27 at 09:40 +0300, Gleb Natapov wrote:
Thanks. Since it's not in a topic branch that I can pull, I'm going to
just cherry-pick them. However, they are in your queue branch, not
next branch. Should I still assume this is a stable branch and that
the numbers aren't going to
On Tue, 2013-08-27 at 09:41 +0300, Gleb Natapov wrote:
Oh and Alexey mentions that there are two capabilities and you only
applied one :-)
Another one is:
[PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for
realmode VFIO
?
Yes, thanks !
Cheers,
Ben.
--
To unsubscribe
On Wed, 2013-08-28 at 10:51 +1000, Alexey Kardashevskiy wrote:
The ioctl I made up is basically a copy of KVM_CREATE_SPAPR_TCE which does
the same thing for emulated devices and it is there for quite a while but
it is not really extensible. And these two ioctls share some bits of code.
Now we
On Tue, 2013-08-27 at 09:40 +0300, Gleb Natapov wrote:
Thanks. Since it's not in a topic branch that I can pull, I'm going to
just cherry-pick them. However, they are in your queue branch, not
next branch. Should I still assume this is a stable branch and that
the numbers aren't going to
On Tue, 2013-08-27 at 09:41 +0300, Gleb Natapov wrote:
Oh and Alexey mentions that there are two capabilities and you only
applied one :-)
Another one is:
[PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for
realmode VFIO
?
Yes, thanks !
Cheers,
Ben.
--
To unsubscribe
On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote:
Gleb, any chance you can put this (and the next one) into a tree to
lock in the numbers ?
Applied it. Sorry for slow response, was on vocation and still go
through the email backlog.
Thanks. Since it's not in a topic branch that I
On Tue, 2013-08-27 at 14:19 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote:
Gleb, any chance you can put this (and the next one) into a tree to
lock in the numbers ?
Applied it. Sorry for slow response, was on vocation and still go
through
On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote:
Gleb, any chance you can put this (and the next one) into a tree to
lock in the numbers ?
Applied it. Sorry for slow response, was on vocation and still go
through the email backlog.
Thanks. Since it's not in a topic branch that I
On Fri, 2013-08-23 at 09:01 +0530, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 22.08.2013, at 12:37, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Isn't this you?
Yes. The patches are generated using git format-patch and sent by
On Mon, 2013-08-19 at 14:02 -0600, Bjorn Helgaas wrote:
I guess. And supply the pci_slot rather than the pci_dev? I'm a
little bit worried because the idea of a slot is not well-defined in
the spec, and we have sort of an ad hoc method of discovering and
managing them, e.g., acpiphp and
On Mon, 2013-08-19 at 14:20 -0600, Alex Williamson wrote:
I try to handle the slot as opaque, only caring that the slot pointer
matches, so I think our implementation is ok... so long as we only get
one driver claiming to manage a slot, but that's not a vfio problem ;)
Thanks,
By why bother
On Mon, 2013-08-19 at 16:59 -0600, Alex Williamson wrote:
On Tue, 2013-08-20 at 08:42 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-08-19 at 14:02 -0600, Bjorn Helgaas wrote:
I guess. And supply the pci_slot rather than the pci_dev? I'm a
little bit worried because the idea
On Wed, 2013-08-14 at 14:34 -0500, Scott Wood wrote:
On Wed, 2013-08-14 at 13:56 +0200, Alexander Graf wrote:
On 07.08.2013, at 04:05, Tiejun Chen wrote:
We enter with interrupts disabled in hardware, but we need to
call SOFT_DISABLE_INTS anyway to ensure that the software state
is
On Wed, 2013-08-14 at 14:34 -0500, Scott Wood wrote:
On Wed, 2013-08-14 at 13:56 +0200, Alexander Graf wrote:
On 07.08.2013, at 04:05, Tiejun Chen wrote:
We enter with interrupts disabled in hardware, but we need to
call SOFT_DISABLE_INTS anyway to ensure that the software state
is
On Thu, 2013-08-01 at 14:44 +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of H_PUT_TCE_INDIRECT and H_STUFF_TCE pseries hypercalls
which support mulptiple DMA map/unmap operations per one call.
Gleb, any chance you can put this (and the next one)
On Fri, 2013-08-02 at 10:36 -0600, Alex Williamson wrote:
Also in some cases, at least for us, we have a problem where the scope
of the reset can be larger than the group ... in this case I think we
need to forbid the reset.
Interesting, I would have ventured to guess that resets are
On Fri, 2013-08-02 at 16:49 -0600, Bjorn Helgaas wrote:
[+cc linux-pci]
On Fri, Aug 2, 2013 at 3:28 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
Right. Another use case is, I know of devices that need a fundamental
reset (PERST) after applying a FW update
On Fri, 2013-08-02 at 17:58 -0500, Scott Wood wrote:
What about 64-bit PTEs on 32-bit kernels?
In any case, this code does not belong in KVM. It should be in the
main
PPC mm code, even if KVM is the only user.
Also don't we do similar things in BookS KVM ? At the very least that
sutff
On Fri, 2013-08-02 at 17:37 -0600, Alex Williamson wrote:
Yes.
We have that similar issue with error handling, when the driver doesn't
have the right hooks, we simulate an unplug, reset, then replug.
Maybe we could provide generic helpers to do that...
Devices going away and
On Sat, 2013-08-03 at 02:58 +, Bhushan Bharat-R65777 wrote:
One of the problem I saw was that if I put this code in
asm/pgtable-32.h and asm/pgtable-64.h then pte_persent() and other
friend function (on which this code depends) are defined in pgtable.h.
And pgtable.h includes
On Sat, 2013-08-03 at 03:11 +, Bhushan Bharat-R65777 wrote:
Could you explain why we need to set dirty/referenced on the PTE, when we
didn't
need to do that before? All we're getting from the PTE is wimg.
We have MMU notifiers to take care of the page being unmapped, and we've
On Fri, 2013-08-02 at 17:58 -0500, Scott Wood wrote:
What about 64-bit PTEs on 32-bit kernels?
In any case, this code does not belong in KVM. It should be in the
main
PPC mm code, even if KVM is the only user.
Also don't we do similar things in BookS KVM ? At the very least that
sutff
On Sat, 2013-08-03 at 02:58 +, Bhushan Bharat-R65777 wrote:
One of the problem I saw was that if I put this code in
asm/pgtable-32.h and asm/pgtable-64.h then pte_persent() and other
friend function (on which this code depends) are defined in pgtable.h.
And pgtable.h includes
On Sat, 2013-08-03 at 03:11 +, Bhushan Bharat-R65777 wrote:
Could you explain why we need to set dirty/referenced on the PTE, when we
didn't
need to do that before? All we're getting from the PTE is wimg.
We have MMU notifiers to take care of the page being unmapped, and we've
On Thu, 2013-08-01 at 16:18 -0600, Alex Williamson wrote:
vfio-pci needs to support an interface to do hot resets (PCI parent
bridge secondary bus reset). We need this to support reset of
co-assigned devices where one or more of the devices does not support
function level reset. In
On Fri, 2013-07-26 at 11:16 +0530, Bharat Bhushan wrote:
If the page is RAM then map this as cacheable and coherent (set M bit)
otherwise this page is treated as I/O and map this as cache inhibited
and guarded (set I + G)
This helps setting proper MMU mapping for direct assigned device.
On Fri, 2013-07-26 at 15:03 +, Bhushan Bharat-R65777 wrote:
Will not searching the Linux PTE is a overkill?
That's the best approach. Also we are searching it already to resolve
the page fault. That does mean we search twice but on the other hand
that also means it's hot in the cache.
On Fri, 2013-07-26 at 15:03 +, Bhushan Bharat-R65777 wrote:
Will not searching the Linux PTE is a overkill?
That's the best approach. Also we are searching it already to resolve
the page fault. That does mean we search twice but on the other hand
that also means it's hot in the cache.
On Wed, 2013-07-24 at 15:43 -0700, Andrew Morton wrote:
For what? The three lines of comment in page-flags.h? ack :)
Manipulating page-_count directly is considered poor form. Don't
blame us if we break your code ;)
Actually, the manipulation in realmode_get_page() duplicates the
On Wed, 2013-07-24 at 15:43 -0700, Andrew Morton wrote:
For what? The three lines of comment in page-flags.h? ack :)
Manipulating page-_count directly is considered poor form. Don't
blame us if we break your code ;)
Actually, the manipulation in realmode_get_page() duplicates the
On Mon, 2013-07-15 at 10:20 +0800, tiejun.chen wrote:
What about SOFT_IRQ_DISABLE? This is close to name
hard_irq_disable() :) And
then remove all DISABLE_INTS as well?
Or RECONCILE_IRQ_STATE...
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
On Mon, 2013-07-15 at 10:20 +0800, tiejun.chen wrote:
What about SOFT_IRQ_DISABLE? This is close to name
hard_irq_disable() :) And
then remove all DISABLE_INTS as well?
Or RECONCILE_IRQ_STATE...
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a
On Fri, 2013-07-12 at 12:54 +0800, tiejun.chen wrote:
Is the following fine?
powerpc: to access local paca after hard irq disabled
We can access paca directly after hard interrupt disabled, and
this can avoid accessing wrong paca when using get_paca() in
preempt case.
Signed-off-by:
On Fri, 2013-07-12 at 12:50 -0500, Scott Wood wrote:
[1] SOFT_DISABLE_INTS seems an odd name for something that updates the
software state to be consistent with interrupts being *hard* disabled.
I can sort of see the logic in it, but it's confusing when first
encountered. From the
On Fri, 2013-07-12 at 12:50 -0500, Scott Wood wrote:
[1] SOFT_DISABLE_INTS seems an odd name for something that updates the
software state to be consistent with interrupts being *hard* disabled.
I can sort of see the logic in it, but it's confusing when first
encountered. From the
On Thu, 2013-07-11 at 11:49 +0200, Alexander Graf wrote:
Ben, is soft_enabled == 0; hard_enabled == 1 a valid combination that
may ever occur?
Yes of course, that's what we call soft disabled :-) It's even the
whole point of doing lazy disable...
Ben.
--
To unsubscribe from this list: send
On Thu, 2013-07-11 at 11:52 +0200, Alexander Graf wrote:
Where exactly (it is rather SPAPR_TCE_IOMMU but does not really
matter)?
Select it on KVM_BOOK3S_64? CONFIG_KVM_BOOK3S_64_HV?
CONFIG_KVM_BOOK3S_64_PR? PPC_BOOK3S_64?
I'd say the most logical choice would be to check the Makefile
101 - 200 of 689 matches
Mail list logo
