On Tue, Aug 7, 2012 at 1:30 AM, Bhushan Bharat-R65777
wrote:
>
>
>> -Original Message-
>> From: Alex Williamson [mailto:alex.william...@redhat.com]
>> Sent: Monday, August 06, 2012 9:27 PM
>> To: Bhushan Bharat-R65777
>> Cc: qemu-devel@nongnu.org; Avi Kivity
>> Subject: Re: Running KVM gue
From: Stuart Yoder
If the host kernel supports the idle hcall, then advertise
that to the guest kernel via the device tree.
Signed-off-by: Stuart Yoder
---
hw/ppce500_mpc8544ds.c |5 +
target-ppc/kvm.c | 26 +++---
target-ppc/kvm_ppc.h |1 +
3 files
On Wed, Jun 27, 2012 at 6:51 PM, Scott Wood wrote:
> This gives the kernel a paravirtualized machine to target, without
> requiring both sides to pretend to be targeting a specific board
> that likely has little to do with the host in KVM scenarios. This
> avoids the need to add new boards to QEM
From: Stuart Yoder
Signed-off-by: Stuart Yoder
---
-note: this patch requires a kernel headers update
for the pvinfo idle flag. See Bharat Bhushan's
recent patch "Synchronized the linux headers"
---
hw/ppc/e500.c|4
target-ppc/k
From: Stuart Yoder
Previous check in configure's endian test was to determine if
this is a cross-compile build by testing whether --cross-prefix
was used. This does not work for cross build environments
like Yocto that may set CC instead of --cross-prefix.
Instead, test whether host com
From: Stuart Yoder
Remove the runtime check for endianness, and for platforms
that can be bit or little endian do a compile time check.
This resolves an issue encountered building QEMU
under Yocto which was not setting --cross-prefix.
Signed-off-by: Stuart Yoder
---
-v2: removed the dynamic
From: Stuart Yoder
the host pkg-config tool should be used with the location to
pkg-config *.pc files being specified via the PKG_CONFIG_PATH
Signed-off-by: Stuart Yoder
---
The Freescale cross build environment is multilib which
means there are special library paths for different
cpu
From: Stuart Yoder
When overriding a tool name via a shell variable, don't
tack on the cross-prefix. This specifically allows the
pkg-config command to be overridden and work where it
does not exist in some cross build environments.
Signed-off-by: Stuart Yoder
---
configure |
I'm trying to solve a problem where bringing up a virtio network
device in a KVM guest hangs the guest.
Start QEMU with these options:
-net nic,model=virtio -net tap,script=/root/qemu-ifup
The qemu-ifup script is pretty simple, just adds the interface passed
in to a bridge:
#!/bin/sh
bridg
On Tue, Nov 1, 2011 at 9:22 AM, Jan Kiszka wrote:
> Hi there,
>
> I'm generating some slides on guest debugging via kvm. What's the
> current state for Book-E and Book-S? Works out of box, mostly usable, or
> to be implemented? Is anyone using it?
Are you talking about guest debug using the QEMU
On Thu, Nov 3, 2011 at 2:14 PM, Jan Kiszka wrote:
> On 2011-11-03 19:59, Stuart Yoder wrote:
>> On Tue, Nov 1, 2011 at 9:22 AM, Jan Kiszka wrote:
>>> Hi there,
>>>
>>> I'm generating some slides on guest debugging via kvm. What's the
>>>
Based on the discussions over the last couple of weeks
I have updated the device fd file layout proposal and
tried to specify it a bit more formally.
===
1. Overview
This specification describes the layout of device files
used in t
PCI_BAR_INDEX sub-record type
-updated magic numbers
Stuart
On Fri, Sep 9, 2011 at 8:11 AM, Stuart Yoder wrote:
> Based on the discussions over the last couple of weeks
> I have updated the device fd file layout proposal and
> tried to specify it a bit more
From: Stuart Yoder
also adds configure options to enable/disable installing DTBs
and override location of dtc
Signed-off-by: Stuart Yoder
---
Makefile | 17 +++--
configure | 24
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/Makefile
From: Stuart Yoder
make install now compiles dtb
Signed-off-by: Stuart Yoder
---
apply after 'support compiling and installing DTBs'
pc-bios/mpc8544ds.dtb | Bin 2277 -> 0 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 pc-bios/mpc8544ds.dtb
diff --
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, April 10, 2014 10:57 AM
> To: Peter Maydell
> Cc: Juan Quintela; KVM devel mailing list; qemu list; Yoder Stuart-
> B08248; Alistair Francis; Peter Crosthwaite; Christoffer Dall
> Subject: Re: [Qemu-devel
From: Stuart Yoder
Signed-off-by: Stuart Yoder
---
target-ppc/cpu-models.c | 64 +--
target-ppc/cpu-models.h | 30 --
2 files changed, 90 insertions(+), 4 deletions(-)
diff --git a/target-ppc/cpu-models.c b/target-ppc/cpu
From: Stuart Yoder
-for KVM we always want the cpu to be that of the
host system, so make that the default
-for TGC mode, the emulated cpu type should be explicitly
set
Signed-off-by: Stuart Yoder
---
hw/ppc/e500.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a
; On 14.02.14 20:22, Stuart Yoder wrote:
> > From: Stuart Yoder
> >
> > Signed-off-by: Stuart Yoder
> > ---
> > target-ppc/cpu-models.c | 64
> +--
> > target-ppc/cpu-models.h | 30 --
> >
Hi Gerd,
In the "USB 2.0 Quick Start" write-up you said about USB
passthrough:
> (2) hostbus+hostport -- match for a specific physical port in the
> host, any device which is plugged in there gets passed to the
> guest
A customer is asking what happens if a USB hub is plugged into
the
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, June 05, 2014 2:59 AM
> To: sonia verma
> Cc: Paolo Bonzini; abhishek jain; qemu-...@nongnu.org; qemu-devel; Yoder
> Stuart-B08248
> Subject: Re: [Qemu-ppc] qemu does not support PAPR
>
>
>
> > Am 05.0
> From: sonia verma [mailto:soniaverma9...@gmail.com]
> Sent: Thursday, June 05, 2014 12:13 PM
> To: Yoder Stuart-B08248
> Cc: abhishek jain; Alexander Graf; qemu-...@nongnu.org; qemu-devel; Paolo
> Bonzini
> Subject: RE: [Qemu-ppc] qemu does not support PAPR
>
> Hi Stuart.
> Thanks for the info
buntu.
Can you help me regarding that?
On Thu, Jun 5, 2014 at 11:10 PM, Stuart Yoder
mailto:stuart.yo...@freescale.com>> wrote:
> From: sonia verma
> [mailto:soniaverma9...@gmail.com<mailto:soniaverma9...@gmail.com>]
> Sent: Thursday, June 05, 2014 12:13 PM
> To: Yoder Stua
> /* read()-like version */
> ssize_t read_targphys(const char *name,
>int fd, hwaddr dst_addr, size_t nbytes)
> @@ -113,6 +146,12 @@ int load_image_targphys(const char *filename,
> }
> if (size > 0) {
> rom_add_file_fixed(filename, addr, -1);
> +
On Wed, Nov 14, 2012 at 2:28 PM, Olivia Yin wrote:
> Signed-off-by: Olivia Yin
> ---
> hw/loader.c | 64 ++
> 1 files changed, 46 insertions(+), 18 deletions(-)
>
> diff --git a/hw/loader.c b/hw/loader.c
> index a8a0a09..1a909d0 100644
>
On Wed, Nov 21, 2012 at 8:38 AM, Olivia Yin wrote:
> Signed-off-by: Olivia Yin
> ---
> hw/elf_ops.h |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/hw/elf_ops.h b/hw/elf_ops.h
> index b346861..9c76a75 100644
> --- a/hw/elf_ops.h
> +++ b/hw/elf_ops.h
> @@ -178,6 +17
From: Stuart Yoder
Signed-off-by: Stuart Yoder
---
hw/ppc/e500plat.c |5 +
1 file changed, 5 insertions(+)
diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
index 25ac4b1..2cd7cad 100644
--- a/hw/ppc/e500plat.c
+++ b/hw/ppc/e500plat.c
@@ -16,6 +16,7 @@
#include "sysemu/device_t
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 (PAMU). It is an aperture/window-based IOMMU and is quite different
>> than x86, and will i
On Tue, Apr 2, 2013 at 3:32 PM, Alex Williamson
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
>>to generate interrupts. The Linux MSI driver can alloc
On Tue, Apr 2, 2013 at 3:47 PM, Scott Wood wrote:
> 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,
>
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 that is kind of, sort of like PAMU, how would they know if it's close
> enough? What assumption
>> > Type1 is arbitrary. It might as well be named "brown" and this one
>> > can be
>> > "blue".
>>
>> The difference is that "type1" seems to refer to hardware that can do
>> arbitrary 4K page mappings, possibly constrained by an aperture but
>> nothing else. More than one IOMMU can reasonably
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:
>> > On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood
>> > wrote:
>> > >> >C. Expli
> 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 of the aperture, growing up, and
> VFIO will map bank
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 determined by something like
>> > VFIO_IOMMU_G
On Mon, Sep 26, 2011 at 2:51 AM, David Gibson
wrote:
> On Fri, Sep 09, 2011 at 08:11:54AM -0500, Stuart Yoder wrote:
>> Based on the discussions over the last couple of weeks
>> I have updated the device fd file layout proposal and
>> tried to specify i
>
> 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 VFIO_DEVICE_GET_FLAGS _IOR(,
>
> BTW, github now has updated trees:
>
> git://github.com/awilliam/linux-vfio.git vfio-next-2029
> git://github.com/awilliam/qemu-vfio.git vfio-ng
Hi Alex,
Have been looking at vfio a bit. A few observations and things
we'll need to figure out as it relates to the Freescale iommu.
__vfio
On Tue, Nov 29, 2011 at 5:44 PM, Alex Williamson
wrote:
> On Tue, 2011-11-29 at 17:20 -0600, Stuart Yoder wrote:
>> >
>> > BTW, github now has updated trees:
>> >
>> > git://github.com/awilliam/linux-vfio.git vfio-next-2029
>> > git://github.
>> The attributes are not intrinsic features of the domain. User space will
>> need to set them. But in thinking about it a bit more I think the attributes
>> are more properties of the domain rather than a per map() operation
>> characteristic. I think a separate API might be appropriate. Defi
On Thu, Dec 1, 2011 at 3:25 PM, Alex Williamson
wrote:
> On Thu, 2011-12-01 at 14:58 -0600, Stuart Yoder wrote:
>> One other mechanism we need as well is the ability to
>> enable/disable a domain.
>>
>> For example-- suppose a device is assigned to a VM, the
>>
In the vfio RFC thread there seemed to be convergence that some new
iommu_ops API is needed to set some platform specific aspects of an
iommu domain.
On Wed, Nov 30, 2011 at 10:58 AM, Alex Williamson
wrote:
[cut]
> In that case, you should definitely be following what Alexey is thinking
> about w
On Wed, Dec 7, 2011 at 10:38 AM, Joerg Roedel wrote:
> On Wed, Dec 07, 2011 at 09:54:39AM -0600, Stuart Yoder wrote:
>> Alex, Alexey I'm wondering if you've had any new thoughts on this over
>> the last week.
>>
>> For Freescale, our iommu domain
43 matches
Mail list logo
