On Mon, Apr 18, 2011 at 05:25:48PM -0500, Scott Wood wrote:
> 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
Read them via KVM_GET_SREGS in kvm_arch_get_registers(),
and display them in "info registers".
Also get CR and PID from the existing KVM_GET_REGS.
Signed-off-by: Scott Wood
---
hw/ppc.c | 12 +
monitor.c | 71 +++-
target
On Fri, 29 Apr 2011 14:05:23 +0200
Jan Kiszka wrote:
> On 2011-04-28 23:01, Scott Wood wrote:
> > +#ifdef KVM_CAP_PPC_BOOKE_SREGS
> > +if (kvm_check_extension(env->kvm_state, KVM_CAP_PPC_BOOKE_SREGS)) {
>
> You probably want to cache the result of this syscall duri
Read them via KVM_GET_SREGS in kvm_arch_get_registers(),
and display them in "info registers".
Also get CR and PID from the existing KVM_GET_REGS.
Signed-off-by: Scott Wood
---
v2: fix a couple style oversights, and cache kvm caps as requested
This version depen
On Tue, 3 May 2011 13:02:40 +0200
Alexander Graf wrote:
>
> On 30.04.2011, at 00:10, Scott Wood wrote:
>
> > Read them via KVM_GET_SREGS in kvm_arch_get_registers(),
> > and display them in "info registers".
> >
> > Also get CR and PID from the ex
On Tue, 3 May 2011 19:32:00 +0200
"Edgar E. Iglesias" wrote:
> On Tue, May 03, 2011 at 08:13:04PM +0300, Avi Kivity wrote:
> > On 05/03/2011 08:09 PM, Jan Kiszka wrote:
> > > >
> > > > Reluctant ack.
> > >
> > > What downsides do you see?
> >
> > The usual "it shouldn't be this way". Every oth
On Mon, 2 May 2011 17:03:21 +0200
Alexander Graf wrote:
> Most of the code to support e500 style MMUs is already in place, but
> we're missing on some of the special TLB0-TLB1 handling code and slightly
> different TLB modification.
>
> This patch adds support for the FSL style MMU.
>
> Signed-
On Fri, 6 May 2011 12:01:11 +0200
Alexander Graf wrote:
> >> +for (i = env->nb_tlbs[0]; i < env->nb_tlb; i++) {
> >> +tlb = &env->tlb[i].tlbe;
> >> +ret = mmubooke_check_tlb(env, tlb, &raddr, &ctx->prot, address,
> >> rw,
> >> + access_type, i)
On Fri, 6 May 2011 20:33:24 +0200
Alexander Graf wrote:
> On 06.05.2011, at 19:40, Scott Wood wrote:
>
> > OK, it looked like it was being limited to only FSL. I missed that
> > PPC_BOOKE and PPC2_BOOKE_FSL are the same "kind" of flags despite being in
> > di
On Fri, 6 May 2011 14:00:35 +0200
Alexander Graf wrote:
> +static inline void booke206_flush_tlb_one(ppc_tlb_t *tlb, int num)
> +{
> +int i;
> +
> +for (i = 0; i < num; i++) {
> +if ((tlb[i].tlbe.prot & PAGE_VALID) &&
> + !(tlb[i].tlbe.attr & MAS1_IPROT)) {
> +
On Sat, 7 May 2011 23:36:29 +0200
Alexander Graf wrote:
> On 07.05.2011, at 00:25, Scott Wood wrote:
> >> +void helper_booke206_tlbsx(target_ulong address_hi, target_ulong
> >> address_lo)
> >
> > What is address_hi?
> >
> > From gen_tlbsx
On Mon, 9 May 2011 21:36:12 +0200
Alexander Graf wrote:
>
> On 09.05.2011, at 21:27, Scott Wood wrote:
>
> > On Sat, 7 May 2011 23:36:29 +0200
> > Alexander Graf wrote:
> >
> >> On 07.05.2011, at 00:25, Scott Wood wrote:
> >>>>
On Thu, Nov 17, 2011 at 01:22:17PM -0700, Alex Williamson wrote:
> On Wed, 2011-11-16 at 11:52 -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 11, 2011 at 03:10:56PM -0700, Alex Williamson wrote:
> > What would be the return value if somebody tried to unmask an edge one?
> > Should that be docu
On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
> Hmm, that might be cleaner than eliminating the size with just using
> _IO(). So we might have something like:
>
> #define VFIO_IOMMU_MAP_DMA _IOWR(';', 106, struct vfio_dma_map)
> #define VFIO_IOMMU_MAP_DMA_V2
On 11/22/2011 01:16 PM, Alex Williamson wrote:
> On Fri, Nov 18, 2011 at 2:09 PM, Scott Wood wrote:
>> On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
>>> Ugh, I suppose you're thinking of an ILP64 platform with ILP32 compat
>>> mode.
>>
&
On 11/24/2011 03:27 PM, Peter Maydell wrote:
> If it doesn't make sense to hand off cp15 accesses that's fine,
> though -- I want to do this refactoring for the A15 system mode
> implementation in qemu anyway, because I really don't think we
> should try to shoehorn in yet another cpu implementatio
On 12/02/2011 12:11 PM, Bhushan Bharat-R65777 wrote:
> How do we determine whether guest is ready or not? There can be multiple
> device get ready at different time.
The guest makes a hypercall with a device handle -- at least that's how
we do it in Topaz.
> Further if guest have given the devic
On 12/02/2011 08:40 AM, Stuart Yoder wrote:
> 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
On 12/02/2011 12:45 PM, Bhushan Bharat-R65777 wrote:
> Scott, I am not sure if there is any real use case where device needed to
> assigned beyond 2 level (host + immediate guest) in nested virtualization.
Userspace drivers in the guest is a more likely scenario than nested
virtualization, at lea
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 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 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 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: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: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 07/12/2012 03:52 AM, Alexey Kardashevskiy wrote:
> +/* API for POWERPC IOMMU */
> +
> +#define POWERPC_IOMMU 2
> +
> +struct tce_iommu_info {
> +__u32 argsz;
> +__u32 dma32_window_start;
> +__u32 dma32_window_size;
> +};
> +
> +#define POWERPC_IOMMU_GET_IN
On 08/01/2012 12:27 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Wednesday, August 01, 2012 7:57 AM
>> To: Bhushan Bharat-R65777
>> Cc: qemu-...@nongnu.org List; kvm-...@vger.kernel.org; Bhushan Bharat-R65777;
>> qemu-d
On 08/02/2012 10:56 AM, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: Wood Scott-B07421
>> Sent: Wednesday, August 01, 2012 11:31 PM
>> To: Bhushan Bharat-R65777
>> Cc: Alexander Graf; qemu-...@nongnu.org List; kvm-...@vger.kernel.org; qemu-
>> devel qemu-devel; KVM list
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
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/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 Tue, 26 Oct 2010 22:34:51 +0200
Gleb Natapov wrote:
> On Tue, Oct 26, 2010 at 07:57:00PM +, Blue Swirl wrote:
> > On Tue, Oct 26, 2010 at 7:35 PM, Gleb Natapov wrote:
> > > But looking elsewhere I found some description of DTS. It is very
> > > elaborate and looks like this:
> > >
> > > /
This will deadlock when the I/O thread is used, since the
CPU thread is blocked waiting for qemu_system_ready.
The synchronization is unnecessary since this is before
cpu_synchronize_all_post_init().
Signed-off-by: Scott Wood
---
hw/ppc440_bamboo.c |2 --
hw/ppce500_mpc8544ds.c |2
This fixes an observed failure to detect madvise() on Linux.
To avoid similar issues, all other tests that use NULL but don't already
have stddef.h are also fixed.
Signed-off-by: Scott Wood
---
configure |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/conf
On Tue, 5 Oct 2010 10:03:35 +0200
Markus Armbruster wrote:
> Scott Wood writes:
>
> > This fixes an observed failure to detect madvise() on Linux.
> >
> > To avoid similar issues, all other tests that use NULL but don't already
> > have stddef.h are also f
This fixes an observed failure to detect madvise() on Linux.
To avoid similar issues, all other tests that use NULL but don't already
have stddef.h (or another header that is defined to provide NULL,
such as stdio.h, unistd.h, or time.h) are also fixed.
Signed-off-by: Scott Wood
---
On Mon, Oct 04, 2010 at 04:15:58PM -0500, Scott Wood wrote:
> This will deadlock when the I/O thread is used, since the
> CPU thread is blocked waiting for qemu_system_ready.
>
> The synchronization is unnecessary since this is before
> cpu_synchronize_all_post_init().
>
>
On Thu, 10 Mar 2011 22:46:34 +0100
Carl-Daniel Hailfinger wrote:
> Auf 10.03.2011 13:06, Jan Kiszka schrieb:
> > I'm thinking beyond this use case, beyond firmware flashes, beyond x86.
> >
>
> If you're thinking beyond x86, most flash is probably using SPI nowadays
> because the reduced PCB f
On Fri, 1 Apr 2011 18:43:33 +0200
Alexander Graf wrote:
> Howdy,
>
> this is the current patch queue for PowerPC. I'm very excited this time,
> as we finally have a real PPC64 target machine available to play with!
How about http://patchwork.ozlabs.org/patch/66743/?
-Scott
On Fri, 1 Apr 2011 19:49:35 +0200
Alexander Graf wrote:
>
> On 01.04.2011, at 19:44, Scott Wood wrote:
>
> > On Fri, 1 Apr 2011 18:43:33 +0200
> > Alexander Graf wrote:
> >
> >> Howdy,
> >>
> >> this is the current patch queue for PowerP
On Wed, 2 Feb 2011 22:33:41 +0100
Alexander Graf wrote:
>
> On 02.02.2011, at 21:33, Yoder Stuart-B08248 wrote:
>
> > Below is a proposal for a new API for PPC to allow KVM clients
> > to set MMU state in a vcpu.
> >
> > BookE processors have one or more software managed TLBs and
> > currently
On Thu, 3 Feb 2011 10:19:06 +0100
Alexander Graf wrote:
> On 02.02.2011, at 23:08, Scott Wood wrote:
> > On Wed, 2 Feb 2011 22:33:41 +0100
> > Alexander Graf wrote:
> >> This seems to fine-grained. I'd prefer a list of all TLB entries to be
> >>
On Mon, 7 Feb 2011 16:43:02 +0100
Alexander Graf wrote:
> On 04.02.2011, at 23:33, Scott Wood wrote:
>
> > On Thu, 3 Feb 2011 10:19:06 +0100
> > Alexander Graf wrote:
> >
> >> Makes sense. So we basically need an ioctl that tells KVM the MMU type and
>
On Mon, 7 Feb 2011 14:03:50 -0200
Marcelo Tosatti wrote:
> Is there any other issue that prevents turning CONFIG_IOTHREAD on by
> default?
>
This patch is needed for ppce500_mpc8544ds and ppc440_bamboo to work with
I/O thread enabled:
http://patchwork.ozlabs.org/patch/66743/
-Scott
On Mon, 7 Feb 2011 17:49:51 +0100
Alexander Graf wrote:
>
> On 07.02.2011, at 17:40, Yoder Stuart-B08248 wrote:
>
> > Suggested change to this would be to have Qemu set tlb_type as
> > an _input_ argument. If KVM supports it, that type gets used,
> > else an error is returned.This would
On Wed, 9 Feb 2011 18:21:40 +0100
Alexander Graf wrote:
>
> On 07.02.2011, at 21:15, Scott Wood wrote:
>
> > That's pretty much what the proposed API does -- except it uses a void
> > pointer instead of uint64_t *.
>
> Oh? Did I miss something there? T
On Thu, 3 Feb 2011 10:19:06 +0100
Alexander Graf wrote:
> Yeah, that one's tricky. Usually the way the memory resolver in qemu works is
> as follows:
>
> * kvm goes to qemu
> * qemu fetches all mmu and register data from kvm
> * qemu runs its mmu resolution function as if the target was emul
On Thu, 10 Feb 2011 08:16:15 +
Peter Maydell wrote:
> On 10 February 2011 07:47, Anthony Liguori wrote:
> > So very concretely, I'm suggesting we do the following to target-i386:
>
> > 2) get rid of the entire concept of machines. Creating a i440fx is
> > essentially equivalent to creating
On Thu, 10 Feb 2011 12:45:38 +0100
Alexander Graf wrote:
> Ok, thinking about this a bit more. You're basically proposing a list of
> tlb set calls, with each array field identifying one tlb set call. What
> I was thinking of was a full TLB sync, so we could keep qemu's internal
> TLB representat
On Thu, 10 Feb 2011 19:22:38 +
Peter Maydell wrote:
> On 10 February 2011 19:17, Scott Wood wrote:
> > On Thu, 10 Feb 2011 08:16:15 +
> > Peter Maydell wrote:
> >> On 10 February 2011 07:47, Anthony Liguori wrote:
> >> > So very concretely, I'm
On Fri, 11 Feb 2011 02:41:35 +0100
Alexander Graf wrote:
> >> Maybe we should go with Avi's proposal after all and simply keep the full
> >> soft-mmu synced between kernel and user space? That way we only need a
> >> setup call at first, no copying in between and simply update the user
> >> sp
On Fri, 11 Feb 2011 22:07:11 +0100
Alexander Graf wrote:
>
> On 11.02.2011, at 21:53, Scott Wood wrote:
>
> > On Fri, 11 Feb 2011 02:41:35 +0100
> > Alexander Graf wrote:
> >
> >>>> Maybe we should go with Avi's proposal after all and simpl
On Sun, 13 Feb 2011 23:43:40 +0100
Alexander Graf wrote:
> > struct kvmppc_book3e_tlb_entry {
> > union {
> > __u64 mas8_1;
> > struct {
> > __u32 mas8;
> > __u32 mas1;
> > };
> > };
> > __u64 mas2;
> > un
On Mon, 14 Feb 2011 21:19:19 +0100
Alexander Graf wrote:
> There's no nack here :). The only thing that needs to change is the anonymous
> part, as that's a gnu extension. Just name the structs and unions and all is
> well.
Ah, I thought it was an aesthetic objection -- didn't realize it was a
On Tue, 15 Feb 2011 00:39:51 +0100
Alexander Graf wrote:
> On 14.02.2011, at 22:16, Scott Wood wrote:
>
> > On Mon, 14 Feb 2011 21:19:19 +0100
> > Alexander Graf wrote:
> >>>> The struct name should also have
> >>>> a version indicator -
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
401 - 456 of 456 matches
Mail list logo
