Fix some miscellaneous bugs, and enable basic MPIC v4.2 support.
Scott Wood (5):
openpic: fix remaining issues from idr-to-destmask conversion
openpic: fix timer address decoding
openpic: add basic support for MPIC v4.2
PPC: e500: fix mpic_iack address
PPC: e500: Select MPIC v4.2 on
MPIC+0xa0 is IACK for the current CPU. MPIC+0x200a0 is IACK for CPU 0.
This fix allows EPR to work with an SMP target.
Signed-off-by: Scott Wood
---
hw/ppc/e500.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index 9ccf4d1..530f929 100644
directly.
Save/restore destmask when serializing, as due to the IPI change it
cannot be reproduced from idr.
Signed-off-by: Scott Wood
---
hw/openpic.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/hw/openpic.c b/hw/openpic.c
index d414f47..ae5bea0 100644
The timer memory range begins at 0x10f0, so that address 0x1120 shows
up as 0x30, 0x1130 shows up as 0x40, etc. However, the address
decoding (other than TFRR) is not adjusted for this, causing the
wrong registers to be accessed.
Signed-off-by: Scott Wood
---
hw/openpic.c | 10 +++---
1
The compatible string is changed to fsl,mpic on all e500 platforms, to
advertise the existence of BRR1. This matches what the device tree will
have on real hardware.
With MPIC v4.2 max_cpu can be increased from 15 to 32.
Signed-off-by: Scott Wood
---
hw/ppc/e500.c |4 ++--
hw/ppc
).
Just as the code was already not a full implementation of MPIC v2.0,
this is not a full implementation of MPIC v4.2 -- e.g. it still has only
one bank of MSIs.
Signed-off-by: Scott Wood
---
hw/openpic.c | 338 +++---
hw/openpic.h |1 +
2
On 01/22/2013 11:04:59 PM, David Gibson wrote:
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 2f4f068..e84b993 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -60,7 +60,7 @@ static int cap_booke_sregs;
static int cap_ppc_smt;
static int cap_ppc_rma;
static int cap_spapr_tce;
-s
On 01/22/2013 11:05:00 PM, David Gibson wrote:
Currently qemu does not get and put the state of the floating point
and
vector registers to KVM. This is obviously a problem for savevm, as
well
as possibly being problematic for debugging of FP-using guests.
This patch fixes this by using new
On 01/23/2013 04:05:56 PM, David Gibson wrote:
On Wed, Jan 23, 2013 at 11:56:04AM -0600, Scott Wood wrote:
> I don't see where you check a capability, so users of pre-one-reg
> KVM now get (at least) 33 warning messages every time context gets
> synchronized?
Given that a bunc
On 01/23/2013 04:41:27 PM, David Gibson wrote:
On Wed, Jan 23, 2013 at 11:52:54AM -0600, Scott Wood wrote:
> On 01/22/2013 11:04:59 PM, David Gibson wrote:
> >-cap_hior = kvm_check_extension(s, KVM_CAP_PPC_HIOR);
> >+/* This capability is misnamed - it was intr
On 03/21/2013 03:41:19 AM, Alexander Graf wrote:
On 14.02.2013, at 07:32, Scott Wood wrote:
> +DeviceState *kvm_openpic_create(BusState *bus, int model)
> +{
> +KVMState *s = kvm_state;
> +DeviceState *dev;
> +struct kvm_create_device cd = {0};
> +int
On 03/21/2013 04:29:02 PM, Alexander Graf wrote:
Am 21.03.2013 um 21:50 schrieb Scott Wood :
> On 03/21/2013 03:41:19 AM, Alexander Graf wrote:
>> Can't all the stuff above here just simply go into the qdev init
function?
>
> Not if you want platform code to be able to
On 03/21/2013 06:51:57 AM, Alexander Graf wrote:
On 21.03.2013, at 12:49, Alexander Graf wrote:
>
> On 21.03.2013, at 12:44, Peter Maydell wrote:
>
>> On 21 March 2013 11:38, Alexander Graf wrote:
>>>
>>> On 21.03.2013, at 12:32, Peter Maydell wrote:
>>>
On 21 March 2013 11:29, Alexander
On 03/22/2013 08:08:57 AM, Peter Maydell wrote:
On 21 March 2013 22:43, Scott Wood wrote:
> What if the update is to a parent memory region, not to the one
directly
> associated with the device?
>
> Or does add() get called for all child regions (recursively) in
such cases?
On 03/21/2013 06:45:31 PM, Alexander Graf wrote:
On 21.03.2013, at 22:59, Scott Wood wrote:
> On 03/21/2013 04:29:02 PM, Alexander Graf wrote:
>> Am 21.03.2013 um 21:50 schrieb Scott Wood
:
>> > On 03/21/2013 03:41:19 AM, Alexander Graf wrote:
>> >> Can&#
On 03/23/2013 06:24:49 AM, Peter Maydell wrote:
On 22 March 2013 22:05, Scott Wood wrote:
> On 03/22/2013 08:08:57 AM, Peter Maydell wrote:
>> The memory API flattens the tree of memory regions down into a flat
>> view of the address space. These callbacks get called for the
>
On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote:
Alex,
We are in the process of implementing vfio-pci support for the
Freescale
IOMMU (PAMU). It is an aperture/window-based IOMMU and is quite
different
than x86, and will involve creating a 'type 2' vfio implementation.
For each devic
On 04/02/2013 03:38:42 PM, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood
wrote:
> On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote:
>>
>> Alex,
>>
>> We are in the process of implementing vfio-pci support for the
Freescale
>> IOMMU
On 04/02/2013 03:32:17 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 17:32 +, Yoder Stuart-B08248 wrote:
> 2. MSI window mappings
>
>The more problematic question is how to deal with MSIs. We need
to
>create mappings for up to 3 MSI banks that a device may need to
target
>
On 04/02/2013 04:08:27 PM, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood
wrote:
>> This could also be done as another "type2" ioctl extension.
>
>
> Again, what is "type2", specifically? If someone else is adding
their own
> IOMMU t
On 04/02/2013 04:16:11 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 15:54 -0500, Stuart Yoder wrote:
> The number of windows is always power of 2 (and max is 256). And
to reduce
> PAMU cache pressure you want to use the fewest number of windows
> you can.So, I don't see practically ho
On 04/02/2013 04:32:04 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 15:57 -0500, Scott Wood wrote:
> On 04/02/2013 03:32:17 PM, Alex Williamson wrote:
> > On x86 the interrupt remapper handles this transparently when MSI
> > is enabled and userspace never gets direct acces
On 04/02/2013 04:38:45 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 16:08 -0500, Stuart Yoder wrote:
> On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood
wrote:
> >> >C. Explicit mapping using normal DMA map. The last idea
is that
> >> >we would introdu
On 04/03/2013 01:32:26 PM, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 5:50 PM, Scott Wood
wrote:
> On 04/02/2013 04:38:45 PM, Alex Williamson wrote:
>>
>> On Tue, 2013-04-02 at 16:08 -0500, Stuart Yoder wrote:
>> > VFIO_IOMMU_MAP_MSI(iova, size)
>
>
> N
On 04/03/2013 02:09:45 PM, Stuart Yoder wrote:
> Would is be possible for userspace to simply leave room for MSI bank
> mapping (how much room could be determined by something like
> VFIO_IOMMU_GET_MSI_BANK_COUNT) then document the API that userspace
can
> DMA_MAP starting at the 0x0 address o
On 04/03/2013 02:09:45 PM, Stuart Yoder wrote:
> Would is be possible for userspace to simply leave room for MSI bank
> mapping (how much room could be determined by something like
> VFIO_IOMMU_GET_MSI_BANK_COUNT) then document the API that userspace
can
> DMA_MAP starting at the 0x0 address o
On 04/03/2013 02:43:06 PM, Stuart Yoder wrote:
On Wed, Apr 3, 2013 at 2:18 PM, Scott Wood
wrote:
> On 04/03/2013 02:09:45 PM, Stuart Yoder wrote:
>>
>> > Would is be possible for userspace to simply leave room for MSI
bank
>> > mapping (how much room could be d
On 04/02/2013 10:37:20 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 17:50 -0500, Scott Wood wrote:
> On 04/02/2013 04:38:45 PM, Alex Williamson wrote:
> > On Tue, 2013-04-02 at 16:08 -0500, Stuart Yoder wrote:
> > > On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood
> >
On 04/02/2013 10:12:31 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 17:44 -0500, Scott Wood wrote:
> On 04/02/2013 04:32:04 PM, Alex Williamson wrote:
> > On Tue, 2013-04-02 at 15:57 -0500, Scott Wood wrote:
> > > On 04/02/2013 03:32:17 PM, Alex Williamson wrote:
> >
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).
>
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 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/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 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
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 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/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/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/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
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: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
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 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
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/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/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 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 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/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/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 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/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/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/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/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/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/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/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/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/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 05/09/2012 05:54 AM, Fabien Chouteau wrote:
> On 05/07/2012 06:28 PM, Alexander Graf wrote:
>> Hi Fabien,
>>
>> Could you please elaborate a bit on the case that broke for you with these?
>> The patches shouldn't change any guest facing behavior :o.
>>
>>
>
> My bad,
>
> The problem comes fro
On 05/15/2012 11:50 AM, Fabien Chouteau wrote:
> On 05/15/2012 05:28 PM, Scott Wood wrote:
>> On 05/09/2012 05:54 AM, Fabien Chouteau wrote:
>>> On 05/07/2012 06:28 PM, Alexander Graf wrote:
>>>> Hi Fabien,
>>>>
>>>> Could you please elaborate
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/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/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/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 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
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 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
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 09/19/2011 06:35 AM, Alexander Graf wrote:
>
> On 17.09.2011, at 19:40, Blue Swirl wrote:
>
>> On Sat, Sep 17, 2011 at 5:15 PM, Alexander Graf wrote:
>>>
>>> Am 17.09.2011 um 18:58 schrieb Blue Swirl :
>>>
On Sparc32, there is no need for a PV device. The CPU is woken up from
halted
On 09/17/2011 11:59 AM, Blue Swirl wrote:
> On Wed, Sep 14, 2011 at 8:42 AM, Alexander Graf wrote:
>> diff --git a/linux-headers/linux/kvm_para.h b/linux-headers/linux/kvm_para.h
>> index 7bdcf93..b315e27 100644
>> --- a/linux-headers/linux/kvm_para.h
>> +++ b/linux-headers/linux/kvm_para.h
>> @@
On 09/19/2011 10:16 AM, Alex Williamson wrote:
> On Fri, 2011-09-09 at 08:11 -0500, Stuart Yoder wrote:
>> 2. Header
>>
>> The header is located at offset 0x0 in the device fd
>> and has the following format:
>>
>> struct devfd_header {
>> __u32 magic;
>> __u32 version;
>>
On 09/19/2011 04:07 PM, Alex Williamson wrote:
> On Mon, 2011-09-19 at 14:37 -0500, Scott Wood wrote:
>>> A DTPATH as a record, an INTERRUPT as a sub-record, etc.
>>
>> Same as any other unrecognized (sub)record type, you ignore it -- but
>> the kernel should no
On 09/24/2011 05:00 AM, Alexander Graf wrote:
> On 24.09.2011, at 10:44, Blue Swirl wrote:
>> On Sat, Sep 24, 2011 at 8:03 AM, Alexander Graf wrote:
>>> On 24.09.2011, at 09:41, Blue Swirl wrote:
>>>> On Mon, Sep 19, 2011 at 4:12 PM, Scott Wood
>>>>
On 09/26/2011 01:34 PM, Alex Williamson wrote:
> The other obvious possibility is a pure ioctl interface. To match what
> this proposal is trying to describe, plus the runtime interfaces, we'd
> need something like:
>
> /* :0 - PCI devices, :1 - Devices path device, 63:2 - reserved */
> #define V
On 09/26/2011 02:57 PM, Stuart Yoder wrote:
> On Mon, Sep 26, 2011 at 2:51 AM, David Gibson
>> Um, not to put too fine a point on it, this is madness.
>>
>> Yes, it's very flexible and can thereby cover a very wide range of
>> cases. But it's much, much too complex. Userspace has to parse a
>> co
On 09/27/2011 07:45 AM, Alexander Graf wrote:
> On 27.09.2011, at 10:17, Liu Yu wrote:
>> ---
>> hw/ppce500_pci.c | 26 --
>> 1 files changed, 16 insertions(+), 10 deletions(-)
>>
>> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
>> index 2db365d..3e24e85 100644
>> --- a/
On 09/27/2011 12:01 PM, Alexander Graf wrote:
>
> On 27.09.2011, at 18:52, Scott Wood wrote:
>
>> On 09/27/2011 07:45 AM, Alexander Graf wrote:
>>> So this is the main change, right? Why the -1? A guest could potentially
>>> access pib[-1] using this, no?
>&
On 09/27/2011 12:03 PM, Alexander Graf wrote:
> On 27.09.2011, at 18:53, Blue Swirl wrote:
>> On Tue, Sep 27, 2011 at 3:59 PM, Alexander Graf wrote:
>>> On 27.09.2011, at 17:50, Blue Swirl wrote:
>>>> On Mon, Sep 26, 2011 at 11:19 PM, Scott Wood
>>>> wr
On 09/26/2011 07:45 PM, Alex Williamson wrote:
> On Mon, 2011-09-26 at 18:59 -0500, Scott Wood wrote:
>> On 09/26/2011 01:34 PM, Alex Williamson wrote:
>>> /* Reset the device */
>>> #define VFIO_DEVICE_RESET _IO(, ,)
>>
>> What generi
On 09/24/2011 02:32 AM, Alexander Graf wrote:
>
> On 16.09.2011, at 21:05, Stuart Yoder wrote:
>
>> From: Stuart Yoder
>>
>> make install now compiles dtb
>
> It doesn't when you don't have dtb installed, breaking the e500
> target for build environments that don't have dtb. I don't think
> tha
On 09/28/2011 09:45 AM, Jan Kiszka wrote:
> On 2011-09-28 16:26, Alexander Graf wrote:
>>
>> On 28.09.2011, at 16:23, Jan Kiszka wrote:
>>
>>> Alex,
>>>
>>> we have this diff in qemu-kvm:
>>>
>>> diff --git a/exec.c b/exec.c
>>> index c1e045d..f188549 100644
>>> --- a/exec.c
>>> +++ b/exec.c
>>> @@
On 09/28/2011 04:02 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2011-09-28 at 12:27 -0500, Scott Wood wrote:
>
>> Why would it need to be synchronous? Even if it's asynchronous emulated
>> DMA, we don't want it sitting around only in a data cache that
>&g
On 10/03/2011 03:43 PM, Stefan Weil wrote:
> qemu_cache_utils_init() is only used by ppc / ppc64 tcg targets
> to initialize the cache before flush_icache_range() is called.
>
> This patch moves the code to tcg/ppc and tcg/ppc64.
> Initialisation is called from tcg_target_init() there.
>
> Signed
On 10/03/2011 04:10 PM, Stefan Weil wrote:
> Am 03.10.2011 22:52, schrieb Scott Wood:
>> On 10/03/2011 03:43 PM, Stefan Weil wrote:
>>> qemu_cache_utils_init() is only used by ppc / ppc64 tcg targets
>>> to initialize the cache before flush_icache_range() is called.
&
On 10/03/2011 04:36 PM, Alexander Graf wrote:
> With TCG, we're never executing guest code directly, but always go
> through TCG to emulate it. So the only case where we actually need to
> flush the icache is in TCG code generation, never outside, right?
Right.
> For KVM, I agree. We need some in
On 10/03/2011 04:43 PM, Alexander Graf wrote:
>
> On 03.10.2011, at 23:40, Scott Wood wrote:
>
>> On 10/03/2011 04:10 PM, Stefan Weil wrote:
>>> Am 03.10.2011 22:52, schrieb Scott Wood:
>>>> On 10/03/2011 03:43 PM, Stefan Weil wrote:
>>>>> qemu
On 10/03/2011 05:06 PM, Alexander Graf wrote:
>
> On 03.10.2011, at 23:50, Scott Wood wrote:
>
>> On 10/03/2011 04:36 PM, Alexander Graf wrote:
>>> With TCG, we're never executing guest code directly, but always go
>>> through TCG to emulate it. So t
On 10/04/2011 12:55 AM, Stefan Weil wrote:
> Am 03.10.2011 23:40, schrieb Scott Wood:
>> The interface isn't powerpc-specific. It just happens to be the only
>> arch so far that qemu supports that needs the implementation to do
>> something (or possibly just the only on
basename prints a missing-argument error when sdlconfig is empty
and we're cross-compiling.
Signed-off-by: Scott Wood
---
configure |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index ae97e11..c5b85fe 100755
--- a/configure
+++ b/conf
This is required so that the guest does not execute any stale
instructions.
qemu-kvm does this in cpu_physical_memory_rw, but not in
cpu_physical_memory_write_rom.
Signed-off-by: Scott Wood
---
exec.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/exec.c
basename prints a missing-argument error when sdlconfig is empty
and we're cross-compiling.
Signed-off-by: Scott Wood
---
v2: quote the input to basename rather than introduce an extra test,
as suggested by Stefan.
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On Fri, 8 Apr 2011 15:06:57 -0500
Anthony Liguori wrote:
> On 04/08/2011 01:56 PM, Stefan Hajnoczi wrote:
> > On Fri, Apr 08, 2011 at 11:33:49AM -0500, Scott Wood wrote:
> >> diff --git a/configure b/configure
> >> index ae97e11..c5b85fe 100755
> >>
, especially if SoC devices
are being directly assigned.
Signed-off-by: Scott Wood
---
target-ppc/kvm.c | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 2cfb24b..5401536 100644
--- a/target-ppc/kvm
Signed-off-by: Scott Wood
---
hw/ppce500_pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
index 11edd03..2fc8792 100644
--- a/hw/ppce500_pci.c
+++ b/hw/ppce500_pci.c
@@ -198,7 +198,7 @@ static int mpc85xx_pci_map_irq(PCIDevice
, especially if SoC devices
are being directly assigned.
Signed-off-by: Scott Wood
---
v2: Use a runtime check for booke, at least for now.
target-ppc/kvm.c | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/target-ppc/kvm.c b/target-
On Sat, 9 Apr 2011 02:18:34 +0200
Alexander Graf wrote:
> > -int kvm_arch_init_vcpu(CPUState *cenv)
> > +static int kvm_arch_sync_sregs(CPUState *cenv)
>
> huh? So what about the previous caller of this?
It's a new function. kvm_arch_init_vcpu still exists as a public
function, "introduced" la
Linux doesn't use USPRG0 (now renamed VRSAVE in the architecture, even
when Altivec isn't involved), but a guest might.
Signed-off-by: Scott Wood
---
arch/powerpc/include/asm/kvm_host.h |1 +
arch/powerpc/kernel/asm-offsets.c |1 +
arch/powerpc/kvm/booke_interrupts.S |
Signed-off-by: Scott Wood
---
Documentation/kvm/api.txt |6 +-
arch/powerpc/include/asm/kvm.h | 184 +++
arch/powerpc/include/asm/kvm_44x.h |1 -
arch/powerpc/include/asm/kvm_e500.h |1 +
arch/powerpc/include/asm/kvm_host.h |3
301 - 400 of 456 matches
Mail list logo
