I recently left Freescale/NXP, and even before that it'd been a few years
since I was actively involved in KVM/QEMU work.
Signed-off-by: Scott Wood
---
Sorry for the resend -- fixed mailing list address.
MAINTAINERS | 3 ---
1 file changed, 3 deletions(-)
diff --git a/MAINTAIN
On 06/23/2016 04:01 PM, alar...@ddci.com wrote:
> On 17 Jun 2016 22:55:47 Scott Wood wrote:
> On 06/17/2016 05:13 PM, Aaron Larson wrote:
>
> AL> The root cause is that the function computing the size of the TLB
> AL> entry, namely booke206_page_size_to_tlb ... [is wron
On 06/19/2016 09:13 PM, da...@gibson.dropbear.id.au wrote:
> On Fri, Jun 17, 2016 at 10:55:47PM +0000, Scott Wood wrote:
>> On 06/17/2016 05:13 PM, Aaron Larson wrote:
>>> When e500 PPC is booted multi-core, the non-boot cores are started via
>>> the spin table. ppce5
On 06/17/2016 05:13 PM, Aaron Larson wrote:
> When e500 PPC is booted multi-core, the non-boot cores are started via
> the spin table. ppce500_spin.c:spin_kick() calls
> mmubooke_create_initial_mapping() to allocate a 64MB TLB entry, but
> the created TLB entry is only 256KB.
>
> The root cause i
This is not a bug. MMU v2 (implemented in e6500) extended the TSIZE field so
that 1K <<
TSIZE is correct. The extension was on the LSB side so that it works
fine as long as the low bit of the new TSIZE (which is reserved on
e500v2/mc) is zero.
** Changed in: qemu
Status: New => Invalid
On Mon, 2015-03-30 at 11:21 +, WGH wrote:
> Public bug reported:
>
> http://cache.freescale.com/files/32bit/doc/ref_manual/E500CORERM.pdf - see
> 2.12.5.2 MAS Register 1 (MAS1), p. 2-41
> http://cache.freescale.com/files/32bit/doc/ref_manual/E500MCRM.pdf - see
> 2.16.6.2 MAS Register 1 (MAS1
On Wed, 2015-02-18 at 15:43 +0100, Markus Armbruster wrote:
> Scott, can you review?
>
> Markus Armbruster writes:
>
> > We call ppce500_init_mpic_kvm() to create a "kvm-openpic". If it
> > fails, we call ppce500_init_mpic_qemu() to fall back to plain
> > "openpic".
> >
> > ppce500_init_mpic_kv
On Wed, 2014-09-03 at 14:36 -0400, Bogdan Purcareata wrote:
> This is done due to the fact that the kvm-openpic region_{add,del} callbacks
> can be invoked for sections generated from other memory regions as well. These
> callbacks should handle only requests for the kvm-openpic memory region.
>
>
On Wed, 2014-09-03 at 14:36 -0400, Bogdan Purcareata wrote:
> Adding this function would allow a MemoryRegion to compute its start address
> within the AddressSpace. This is done recursively based on mr->container.
>
> Signed-off-by: Bogdan Purcareata
> ---
> include/exec/memory.h |8 +++
On Wed, 2014-07-02 at 19:59 +0200, Alexander Graf wrote:
> On 02.07.14 19:52, Scott Wood wrote:
> > On Wed, 2014-07-02 at 19:30 +0200, Alexander Graf wrote:
> >> On 02.07.14 19:26, Scott Wood wrote:
> >>> On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote:
> &
On Wed, 2014-07-02 at 19:30 +0200, Alexander Graf wrote:
> On 02.07.14 19:26, Scott Wood wrote:
> > On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote:
> >> On 02.07.14 00:50, Scott Wood wrote:
> >>> Plus, let's please not hardcode any more addresses that
On Wed, 2014-07-02 at 19:24 +0200, Alexander Graf wrote:
> On 02.07.14 00:56, Scott Wood wrote:
> > On Tue, 2014-07-01 at 23:49 +0200, Alexander Graf wrote:
> >> This patch adds support to expose eTSEC devices in the dynamically created
> >> guest facing device tree. Thi
On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote:
> On 02.07.14 00:50, Scott Wood wrote:
> > Plus, let's please not hardcode any more addresses that are going to be
> > a problem for giving guests a large amount of RAM (yes, CCSRBAR is also
> > blocking th
On Tue, 2014-07-01 at 23:49 +0200, Alexander Graf wrote:
> For e500 our approach to supporting dynamically spawned sysbus devices is to
> create a simple bus from the guest's point of view within which we map those
> devices dynamically.
>
> We allocate memory regions always within the "platform"
On Tue, 2014-07-01 at 23:49 +0200, Alexander Graf wrote:
> This patch adds support to expose eTSEC devices in the dynamically created
> guest facing device tree. This allows us to expose eTSEC devices into guests
> without changes in the machine file.
>
> Because we can now tell the guest about eT
On Thu, 2014-03-20 at 01:17 +1100, Alexey Kardashevskiy wrote:
> This adds printing of all SPR registers registered for a CPU.
>
> This removes "SPR_" prefix from SPR name to reduce the output.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
>
>
> Now it should look like below. Before the user h
.
>
> Signed-off-by: Alexander Graf
Acked-by: Scott Wood
-Scott
On Thu, 2014-01-23 at 11:40 +0100, Alexander Graf wrote:
> On 23.01.2014, at 01:23, Scott Wood wrote:
>
> > On Mon, 2014-01-20 at 00:44 +0100, Alexander Graf wrote:
> >> Almost all platforms QEMU emulates have some sort of firmware they can load
> >> to expose a
On Thu, 2014-01-23 at 12:34 +0100, Alexander Graf wrote:
> On 23.01.2014, at 01:08, Scott Wood wrote:
>
> > On Mon, 2014-01-20 at 00:44 +0100, Alexander Graf wrote:
> >> The GUTS device is used by system software to find out about hardware
> >> details of the curr
On Mon, 2014-01-20 at 00:44 +0100, Alexander Graf wrote:
> Almost all platforms QEMU emulates have some sort of firmware they can load
> to expose a guest environment that closely resembles the way it would look
> like on real hardware.
>
> This patch introduces such a firmware on our e500 platfor
On Mon, 2014-01-20 at 00:44 +0100, Alexander Graf wrote:
> In addition to the L1 data cache configuration register L1CFG0 there is
> also another one for the L1 instruction cache called L1CFG1.
>
> Emulate that one with the same values as the data one.
>
> Signed-off-by: Alexander Graf
> ---
>
On Mon, 2014-01-20 at 11:04 +0100, Alexander Graf wrote:
>
> > Am 20.01.2014 um 01:17 schrieb Peter Maydell :
> >
> >> On 19 January 2014 23:44, Alexander Graf wrote:
> >> This adds a special build of u-boot tailored for the e500 platforms we
> >> emulate. It is based on patches that are current
On Mon, 2014-01-20 at 00:44 +0100, Alexander Graf wrote:
> The GUTS device is used by system software to find out about hardware
> details of the current system.
>
> We only emulate the bare minimum to be able to reboot a guest which is
> not sufficient to make u-boot happy.
>
> Add a few more re
On Thu, 2014-01-09 at 16:34 +1100, Alexey Kardashevskiy wrote:
> On POWERPC, only a whole CPU core can be assigned to a KVM.
s/POWERPC/POWER/
-Scott
On Fri, 2014-01-03 at 13:24 -0600, Tom Musta wrote:
> On 12/27/2013 6:30 PM, Scott Wood wrote:
> > These instructions are phased-in on embedded, and unlike bpermd are not
> > present on e5500/e6500 which are 64-bit ISA 2.06 implementations.
> > Wasn't the conclusion i
On Wed, 2013-12-18 at 14:48 -0600, Tom Musta wrote:
> This patch adds the Bit Permute Doubleword (bpermd) instruction,
> which was introduced in Power ISA 2.06 as part of the base 64-bit
> architecture.
Technically it's "Category: Embedded.Phased-in, Server" rather than
"Category: Base". e5500 do
On Wed, 2013-12-18 at 14:48 -0600, Tom Musta wrote:
> This patch adds the Divide Doubleword Extended Unsigned
> instructions. This instruction requires dividing a 128-bit
> value by a 64 bit value. Since 128 bit integer division is
> not supported in TCG, a helper is used, providing a
> repeated
On Tue, 2013-12-24 at 07:17 -0800, Richard Henderson wrote:
> On 12/18/2013 12:48 PM, Tom Musta wrote:
> > +DEF_HELPER_3(bpermd, i64, env, i64, i64)
>
> Should be DEF_HELPER_FLAGS_2(bpermd, TCG_CALL_NO_RWG_SE, i64, i64, i64)
>
> > +uint64_t helper_bpermd(CPUPPCState *env, uint64_t rs, uint64_t rb
On Thu, 2013-12-19 at 09:35 -0600, Tom Musta wrote:
> It turns out that all of the instructions added in this series are *not*
> implemented
> in e500mc. So the patch, as is, is correct for e500mc as well as P7/P8.
That may be true for e500mc (for some reason it didn't look that way
when I check
On Wed, 2013-12-18 at 23:09 +0100, Alexander Graf wrote:
> On 18.12.2013, at 23:02, Scott Wood wrote:
>
> > On Mon, 2013-12-09 at 09:46 -0600, Tom Musta wrote:
> >> This patch adds a flag for base instruction additions to Power ISA
> >> 2.06B. The flag will be used
On Mon, 2013-12-09 at 09:46 -0600, Tom Musta wrote:
> This patch adds a flag for base instruction additions to Power ISA
> 2.06B. The flag will be used to identify/select basic Book I and
> Book II instructions that were newly added in that revision of the
> architecture. The flag will not be use
On Wed, 2013-12-11 at 13:56 +, Peter Maydell wrote:
> On 11 December 2013 13:23, Alexander Graf wrote:
> > The guest expects that its data and instruction cache view of the world
> > is 100% consistent when it initially boots. This works just fine on
> > initial rom population for the first bo
On Thu, 2013-12-12 at 10:29 +0100, Alexander Graf wrote:
> We use the rom infrastructure to write firmware and/or initial kernel
> blobs into guest address space. So we're basically emulating the cache
> off phase on very early system bootup.
>
> That phase is usually responsible for clearing the
On Tue, 2013-11-05 at 07:00 +0100, Alexander Graf wrote:
>
> Am 05.11.2013 um 02:48 schrieb Scott Wood :
>
> > On Tue, 2013-11-05 at 12:26 +1100, Alexey Kardashevskiy wrote:
> >> On 11/05/2013 06:42 AM, Scott Wood wrote:
> >>> On Mon, 2013-11-04 at 10:41 +010
On Tue, 2013-11-05 at 12:26 +1100, Alexey Kardashevskiy wrote:
> On 11/05/2013 06:42 AM, Scott Wood wrote:
> > On Mon, 2013-11-04 at 10:41 +0100, Alexander Graf wrote:
> >> What we really have are 3 semantically separate entities:
> >>
> >> * QEMU internal
On Mon, 2013-11-04 at 10:41 +0100, Alexander Graf wrote:
> What we really have are 3 semantically separate entities:
>
> * QEMU internal cpu id
> * KVM internal cpu id
> * DT exposed cpu id
>
> As you have noted, it's a good idea to keep the QEMU internal cpu id
> linear, thus completely se
On Wed, 2013-07-24 at 07:50 -0500, Anthony Liguori wrote:
> I will be hosting a key signing party at this year's KVM Forum.
>
> http://wiki.qemu.org/KeySigningParty2013
>
> Starting for the 1.7 release (begins in December), I will only accepted
> signed pull requests so please try to attend this
On Thu, 2013-09-12 at 16:23 -0500, Alexander Graf wrote:
> On 12.09.2013, at 13:10, Scott Wood wrote:
>
> > On Thu, 2013-09-12 at 04:18 -0500, Bhushan Bharat-R65777 wrote:
> >> and device disabling is not a standard like PCI. Do you think that we
> >> might need t
On Thu, 2013-09-12 at 16:48 -0500, Alexander Graf wrote:
> On 12.09.2013, at 16:45, Scott Wood wrote:
>
> > On Thu, 2013-09-12 at 16:23 -0500, Alexander Graf wrote:
> >> On 12.09.2013, at 13:10, Scott Wood wrote:
> >>
> >>> On Thu, 2013-09-12 a
x27;; 'Antonios Motakis'; 'Christoffer Dall'; 'kim.phill...@linaro.org'
> > > > Cc: kvm...@lists.cs.columbia.edu; 'kvm-...@vger.kernel.org'; 'qemu-
> > > > de...@nongnu.org'
> > > > Subject: vfio for platform devic
On Wed, 2013-09-11 at 11:42 -0500, Yoder Stuart-B08248 wrote:
> One thing we didn't discuss needs to be considered (probably by
> Kim who is looking at the 'binding device' issue) is around
> returning a passthru device back to the host.
>
> After a platform device has been bound to vfio and is in
On 07/22/2013 01:56:32 PM, Alexander Graf wrote:
On 22.07.2013, at 20:26, Peter Maydell wrote:
> On 22 July 2013 18:50, Alexander Graf wrote:
>> We want to be able to spawn a serial console on the platform bus.
Create
>> a small platbus wrapper device very similar to the ISA one.
>
> Why no
On 07/23/2013 04:44:02 PM, Alexander Graf wrote:
Am 23.07.2013 um 23:19 schrieb Scott Wood :
> On 07/23/2013 04:15:59 PM, Alexander Graf wrote:
>> On 23.07.2013, at 21:38, Scott Wood wrote:
>> > On 07/22/2013 10:28:17 AM, Alexander Graf wrote:
>> >> Today we ge
On 07/23/2013 04:15:59 PM, Alexander Graf wrote:
On 23.07.2013, at 21:38, Scott Wood wrote:
> On 07/22/2013 10:28:17 AM, Alexander Graf wrote:
>> Today we generate the device tree once on machine initialization
and then
>> store the finalized blob in memory to reload it on re
On 07/22/2013 10:28:17 AM, Alexander Graf wrote:
Today we generate the device tree once on machine initialization and
then
store the finalized blob in memory to reload it on reset.
This is bad for 2 reasons. First we potentially waste a bunch of RAM
for no
good reason, as we have all informa
On 07/19/2013 04:22:46 AM, Fabien Chouteau wrote:
On 07/18/2013 10:37 PM, Scott Wood wrote:
> On 07/18/2013 04:27:50 AM, Fabien Chouteau wrote:
>> The BD is full, we will have to put the rest of padding in the
next one.
>
> What rest of padding? I thought you said rx_padding
On 07/18/2013 04:27:50 AM, Fabien Chouteau wrote:
On 07/17/2013 11:02 PM, Scott Wood wrote:
> On 07/17/2013 05:17:06 AM, Fabien Chouteau wrote:
>> On 07/16/2013 07:50 PM, Scott Wood wrote:
>> > On 07/16/2013 10:28:28 AM, Fabien Chouteau wrote:
>> >> On 07/16/2
On 07/17/2013 05:17:06 AM, Fabien Chouteau wrote:
On 07/16/2013 07:50 PM, Scott Wood wrote:
> On 07/16/2013 10:28:28 AM, Fabien Chouteau wrote:
>> On 07/16/2013 04:06 AM, Scott Wood wrote:
>> > On 07/10/2013 12:10:02 PM, Fabien Chouteau wrote:
>> >> +
On 07/16/2013 10:28:28 AM, Fabien Chouteau wrote:
On 07/16/2013 04:06 AM, Scott Wood wrote:
> On 07/10/2013 12:10:02 PM, Fabien Chouteau wrote:
>> This implementation doesn't include ring priority, TCP/IP
Off-Load, QoS.
>>
>> Signed-off-by: Fabien Chouteau
>
>
On 07/16/2013 11:15:51 AM, Fabien Chouteau wrote:
On 07/16/2013 05:37 PM, Alexander Graf wrote:
> On 07/16/2013 05:28 PM, Fabien Chouteau wrote:
>> On 07/16/2013 04:06 AM, Scott Wood wrote:
>>> On 07/10/2013 12:10:02 PM, Fabien Chouteau wrote:
>>>> This imple
On 07/10/2013 12:10:02 PM, Fabien Chouteau wrote:
> This implementation doesn't include ring priority, TCP/IP Off-Load, QoS.
>
> Signed-off-by: Fabien Chouteau
>From the code comments I gather this has been tested on VxWorks. Has it
been tested on Linux, or anywhere else?
> ---
> default-conf
On 07/10/2013 03:55:46 PM, Programmingkid wrote:
On Jul 10, 2013, at 4:17 PM, Scott Wood wrote:
> On 07/10/2013 02:54:19 PM, Programmingkid wrote:
>> On Jul 10, 2013, at 3:03 PM, Scott Wood wrote:
>> > Maybe the user doesn't mind -- but maybe they do mind and would
r
On 07/10/2013 02:54:19 PM, Programmingkid wrote:
On Jul 10, 2013, at 3:03 PM, Scott Wood wrote:
> On 07/09/2013 10:36:37 PM, Programmingkid wrote:
>> On Jul 9, 2013, at 1:32 PM, Scott Wood wrote:
>> > On 07/04/2013 09:58:04 AM, Programmingkid wrote:
>> >> On Ju
On 07/09/2013 10:36:37 PM, Programmingkid wrote:
On Jul 9, 2013, at 1:32 PM, Scott Wood wrote:
> On 07/04/2013 09:58:04 AM, Programmingkid wrote:
>> On Jul 4, 2013, at 10:51 AM, Stefan Hajnoczi wrote:
>> > On Thu, Jul 4, 2013 at 4:45 PM, Alexander Graf
wrote:
>> &g
On 07/04/2013 09:58:04 AM, Programmingkid wrote:
On Jul 4, 2013, at 10:51 AM, Stefan Hajnoczi wrote:
> On Thu, Jul 4, 2013 at 4:45 PM, Alexander Graf
wrote:
>>
>> On 04.07.2013, at 16:40, Programmingkid wrote:
>>
>>> We have made a lot of progress in the last month with making Mac
OS X ru
On 06/21/2013 04:22:55 AM, Alexey Kardashevskiy wrote:
Signed-off-by: Alexey Kardashevskiy
---
target-ppc/kvm.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index d6da146..e72c335 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1973,6 +19
On 06/20/2013 01:58:55 PM, Anthony Liguori wrote:
Alexander Graf writes:
> Am 20.06.2013 um 17:42 schrieb Anthony Liguori
:
>
>> Andreas Färber writes:
>>
>>> The functions are called spapr_hcall*() but the protocol uses
>>> papr_hypercall?
>>
>> The discrepancy is inherited in the KVM vs.
On 06/16/2013 02:11:58 PM, Andreas Färber wrote:
Am 15.06.2013 00:57, schrieb Scott Wood:
> ...which of those would make me think "hmm, there's something in
here
> that I need to read before submitting patches for in-kernel mpic"?
>
> I'm not trying to be diffi
On 06/16/2013 02:25:04 PM, Andreas Färber wrote:
Subject is misleading: it's intc/openpic_kvm, not kvm/openpic. Alex,
please fix when squashing.
I meant it as a general description of the functional area, not as a
literal pathname. It looks like that format is more of a Linux kernel
thing
On 06/14/2013 09:59:18 AM, Andreas Färber wrote:
Am 13.06.2013 19:32, schrieb Scott Wood:
> On 06/13/2013 06:01:49 AM, Andreas Färber wrote:
>> Am 12.06.2013 22:32, schrieb Scott Wood:
>> > +typedef struct KVMOpenPICState {
>> > +SysBusDevice busdev;
>>
&
On 06/13/2013 01:31:48 PM, Anthony Liguori wrote:
Alexander Graf writes:
> On 17.05.2013, at 09:42, Andreas Färber wrote:
>
>> Am 17.05.2013 06:25, schrieb David Gibson:
>>> Currently, for qemu-system-ppc64, the default machine type is
'mac99'.
>>> Since the mac99 machine is not being activel
On 06/13/2013 06:01:49 AM, Andreas Färber wrote:
Am 12.06.2013 22:32, schrieb Scott Wood:
> +typedef struct KVMOpenPICState {
> +SysBusDevice busdev;
SysBusDevice parent_obj; please!
http://wiki.qemu.org/QOMConventions
The word "QOMConventions" doesn't exist once in
On 06/12/2013 04:23:09 PM, Alexander Graf wrote:
On 12.06.2013, at 23:21, Scott Wood wrote:
> The patch that added kvm_irqchip_commit_routes was originally
> meant to come after the in-kernel mpic patch, and thus it updated
> hw/intc/openpic_kvm.c. However, it was applied before the
The patch that added kvm_irqchip_commit_routes was originally
meant to come after the in-kernel mpic patch, and thus it updated
hw/intc/openpic_kvm.c. However, it was applied before the in-kernel
mpic patch (which creates hw/intc/openpic_kvm.c), and thus this hunk
got lost.
Signed-off-by: Scott
On 06/12/2013 08:01:06 AM, Alexander Graf wrote:
On 01.05.2013, at 03:48, Scott Wood wrote:
> +static void kvm_openpic_region_add(MemoryListener *listener,
> + MemoryRegionSection *section)
> +{
> +KVMOpenPICState *opp = container
that function would do for us in the in-kernel device init
handler.
Signed-off-by: Scott Wood
---
v2: fix "llx" -> PRI_x64, and remove some broken leftover code
involving reg_base.
---
default-configs/ppc-softmmu.mak |1 +
default-configs/ppc64-softmmu.mak |1 +
hw/
On 06/12/2013 08:04:55 AM, Alexander Graf wrote:
On 01.05.2013, at 03:48, Scott Wood wrote:
> From: Alexander Graf
>
> On PPC, we don't support MP state. So far it's not necessary and I'm
> not convinced yet that we really need to support it ever.
>
> Howeve
On 06/08/2013 02:24:21 AM, Michael Tokarev wrote:
06.06.2013 07:59, Alexey Kardashevskiy wrote:
> From: Scott Wood
>
> The common KVM code insists on calling kvm_arch_init_irq_routing()
> as soon as it sees kernel header support for it (regardless of
whether
> QEMU supports
On 06/10/2013 09:26:18 AM, Alexander Graf wrote:
On 06/10/2013 02:47 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Andreas Färber [mailto:afaer...@suse.de]
Sent: Monday, June 10, 2013 5:43 PM
To: Bhushan Bharat-R65777
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; ag...@su
On 06/06/2013 06:44:31 AM, Andreas Färber wrote:
Am 26.05.2013 19:41, schrieb Julio Guerra:
> MPC86xx processors are based on the e600 core, which is not the case
> in qemu where it is based on the 7400 processor.
>
> This patch creates the e600 core and instantiates the MPC86xx
> processors base
On 06/05/2013 10:59:06 PM, Alexey Kardashevskiy wrote:
From: Scott Wood
The common KVM code insists on calling kvm_arch_init_irq_routing()
as soon as it sees kernel header support for it (regardless of whether
QEMU supports it). Provide a dummy function to satisfy this.
Unlike x86, PPC does
On 05/30/2013 04:25:33 AM, Alexey Kardashevskiy wrote:
This adds an empty stub to make the compiler happy.
Signed-off-by: Alexey Kardashevskiy
---
target-ppc/kvm.c |4
1 file changed, 4 insertions(+)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 3ab2946..2bbc3b8 100644
--- a
From: Alexander Graf
The usual MSI injection mechanism writes msi.data into memory using an
le32 wrapper. So on big endian guests, this swaps msg.data into the
expected byte order.
For irqfd however, we don't swap the payload right now, rendering
in-kernel MPIC emulation broken on PowerPC.
Swap
From: Alexander Graf
The current logic updates KVM's view of our interrupt map every time we
change it. While this is nice and bullet proof, it slows things down
badly for me. QEMU spends about 3 seconds on every start telling KVM what
news it has on its routing maps.
Instead, let's just synchro
that function would do for us in the in-kernel device init
handler.
Signed-off-by: Scott Wood
---
default-configs/ppc-softmmu.mak |1 +
default-configs/ppc64-softmmu.mak |1 +
hw/intc/Makefile.objs |1 +
hw/intc/openpic_kvm.c |
...for use by the KVM in-kernel irqchip stub.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
hw/intc/openpic.c| 40 ++--
include/hw/ppc/openpic.h | 11 +++
2 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/hw
Headers are imported from commit
4cee4b72f1e2600e19779a14d4d9a4f4016ce49f
in the next branch of git://git.kernel.org/pub/scm/virt/kvm/kvm.git
Signed-off-by: Scott Wood
---
linux-headers/asm-arm/kvm.h | 12 +++---
linux-headers/asm-powerpc/kvm.h | 77
From: Alexander Graf
On PPC, we can have different types of interrupt controllers, so we really
only know that we are going to use one when we created it.
Export kvm_init_irq_routing() to common code, so that we don't have to call
kvm_irqchip_create().
Signed-off-by: Alexander Graf
---
includ
KVM in-kernel MPIC support is going to expand this even more,
so let's keep it contained.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
hw/ppc/e500.c | 56 ++--
1 file changed, 34 insertions(+), 22 deletions(-)
diff --
stick here. Even if you ignore the routes themselves,
which even on x86 are not set up in this function, the initial XICS
kernel implementation will not support IRQ routing, so it's best to
leave even the general feature flags up to the specific irqchip code.
Signed-off-by: Scott Wood
anymore.
Let's split up the two cases into two different variables. That way
PPC can expose an in-kernel PIC, while not implementing MP state.
Signed-off-by: Alexander Graf
CC: Jan Kiszka
Signed-off-by: Scott Wood
---
v1 -> v2:
- use kvm_halt_in_kernel() instead
v2 -> v3:
On 04/30/2013 06:03:54 PM, Chen, Tiejun wrote:
> -Original Message-
> From: Scott Wood [mailto:scottw...@freescale.com]
> Sent: Tuesday, April 30, 2013 3:19 AM
> To: Chen, Tiejun
> Cc: ag...@suse.de; qemu-...@nongnu.org; qemu-devel@nongnu.org
> Subject: Re: [Qemu-ppc] [
On 04/30/2013 06:31:41 PM, Chen, Tiejun wrote:
> function that gets called later. The comment doesn't make
Are you saying I should replace cpu_to_be64(params->ram_size) with
cpu_to_be64(ram_size) directly in ppce500_load_device_tree()?
No, I'm saying to reword (or eliminate) the confusing c
On 04/28/2013 05:30:09 AM, Tiejun Chen wrote:
We should sync params->ram_size after we fixup memory size on
a alignment boundary. Otherwise Guest would exceed the actual
memory region.
Signed-off-by: Tiejun Chen
---
hw/ppc/e500.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/ppc/
On 04/29/2013 02:10:14 PM, Bhushan Bharat-R65777 wrote:
> The caller needs both the "tsize"
> and the size in bytes, and you only call this wrapper once, so let
the caller do
> the conversion instead.
Caller does not need to know both. It only need to know the size in
bytes.
I think git
On 04/29/2013 09:40:56 AM, Bharat Bhushan wrote:
ePAPR defines the initial values of cpu registers.
This patch initialize the GPRs as per ePAPR specification.
This resolves the issue of guest reboot/reset (guest hang on reboot).
Signed-off-by: Bharat Bhushan
---
v1-->v2
- Dynemic seting of in
On 04/26/2013 01:59:10 AM, Alexander Graf wrote:
On 26.04.2013, at 08:51, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Friday, April 26, 2013 11:51 AM
>> To: Bhushan Bharat-R65777
>> Cc: qemu-...@nongnu.org; qemu-devel@no
On 04/16/2013 03:25:50 AM, Peter Maydell wrote:
On 16 April 2013 00:19, Scott Wood wrote:
> This is useful for when a user of the memory region API needs to
> communicate the absolute bus address to something outside QEMU
> (in particular, KVM).
>
> Signed-off-by: Scott Wood
&g
KVM in-kernel MPIC support is going to expand this even more,
so let's keep it contained.
Signed-off-by: Scott Wood
---
hw/ppc/e500.c | 56 ++--
1 file changed, 34 insertions(+), 22 deletions(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e
This depends on RFC kernel interfaces proposed at:
http://patchwork.ozlabs.org/patch/236285/
http://patchwork.ozlabs.org/patch/236288/
http://patchwork.ozlabs.org/patch/236290/
TODO: use KVM_IRQ_LINE
Signed-off-by: Scott Wood
---
hw/kvm/Makefile.objs |1 +
hw/kvm/openpic.c | 259
These headers have not yet been merged into Linux -- this is an RFC
patchset.
Signed-off-by: Scott Wood
---
linux-headers/asm-powerpc/kvm.h | 16
linux-headers/linux/kvm.h | 34 ++
2 files changed, 50 insertions(+)
diff --git a/linux
...for use by the KVM in-kernel irqchip stub.
Signed-off-by: Scott Wood
---
hw/openpic.c | 40 ++--
hw/openpic.h | 11 +++
2 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/hw/openpic.c b/hw/openpic.c
index 03a7075..b655381 100644
This is useful for when a user of the memory region API needs to
communicate the absolute bus address to something outside QEMU
(in particular, KVM).
Signed-off-by: Scott Wood
---
TODO: Use add/del memory listeners later in the patchset, which would
eliminate the need for this patch
This allows QEMU to use the in-kernel KVM MPIC on some PPC platforms.
Scott Wood (6):
kvm: update linux-headers
kvm: use hw/kvm/Makefile.objs consistently for all relevant
architectures
memory: add memory_region_to_address()
openpic: factor out some common defines into openpic.h
PPC
Signed-off-by: Scott Wood
---
Build tested on ppc and x86, but not arm as I currently lack a suitable
toolchain.
Maybe TARGET_I386 should be set on x86_64, instead of needing to
test TARGET_BASE_ARCH in Makefile.objs? It seems odd that it's set
for x86_64 in C code, but not in the make
On 04/11/2013 07:56:59 AM, Joerg Roedel wrote:
On Tue, Apr 09, 2013 at 01:22:15AM +, Yoder Stuart-B08248 wrote:
> > What happens if a normal unmap call is done on the MSI iova? Do
we
> > need a separate unmap?
>
> I was thinking a normal unmap on an MSI windows would be an
error...but
>
On 04/06/2013 04:01:32 AM, Alexander Graf wrote:
Am 06.04.2013 um 01:00 schrieb Scott Wood :
> On 04/04/2013 06:59:24 AM, Alexander Graf wrote:
>> On 04.04.2013, at 13:53, Andreas Färber wrote:
>> > For PReP, Fabien has not stated what his use case actually is (in
>
On 04/04/2013 06:59:24 AM, Alexander Graf wrote:
On 04.04.2013, at 13:53, Andreas Färber wrote:
> For PReP, Fabien has not stated what his use case actually is (in
> particular which hardware?), so it's hard for me to comment on what
the
> hardware actually does and I thus won't accept rando
On 04/04/2013 05:10:27 PM, Yoder Stuart-B08248 wrote:
/*
* VFIO_IOMMU_PAMU_UNMAP_MSI_BANK
*
* Unmaps the MSI bank at the specified iova.
* Caller provides struct vfio_pamu_msi_bank_unmap with all fields
set.
* Operates on VFIO file descriptor (/dev/vfio/vfio).
* Return: 0 on success, -er
On 04/04/2013 04:38:44 PM, Yoder Stuart-B08248 wrote:
> > /*
> > * VFIO_PAMU_MAP_MSI_BANK
> > *
> > * Maps the MSI bank at the specified index and iova. User space
must
> > * call this ioctl once for each MSI bank (count of banks is
returned by
> > * VFIO_IOMMU_GET_MSI_BANK_COUNT).
>
1 - 100 of 456 matches
Mail list logo
