Only difference (appart from being rebased) is the memory
barrier patch getting a couple of curly braces where they
were missing.
Cheers,
Ben.
ze of dma_addr_t.
* We add a new helper macro to create device properties which take a
dma_addr_t, currently an alias to DEFINE_PROP_TADDR().
Signed-off-by: David Gibson
Signed-off-by: Benjamin Herrenschmidt
---
dma.h |1 +
hw/qdev-dma.h | 12
2 files change
DMAContext from pci_dma_context(), in
the SysBus case, it uses NULL - i.e. assumes for now that there will
be no IOMMU translation for a SysBus OHCI.
Cc: Gerd Hoffmann
Cc: Michael S. Tsirkin
Signed-off-by: David Gibson
Signed-off-by: Benjamin Herrenschmidt
---
hw/usb/hcd-ohci.c | 93
Signed-off-by: Benjamin Herrenschmidt
---
hw/usb.h |2 +-
hw/usb/hcd-ehci.c |4 ++--
hw/usb/hcd-uhci.c |2 +-
hw/usb/libhw.c| 21 +++--
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/hw/usb.h b/hw/usb.h
index 2a56fe5..a5623d3 100644
this callback.
Cc: Michael S. Tsirkin
Cc: Richard Henderson
Signed-off-by: Eduard - Gabriel Munteanu
Signed-off-by: David Gibson
Signed-off-by: Benjamin Herrenschmidt
---
dma-helpers.c | 172 -
dma.h | 108
ts this code to make use of the new common IOMMU
infrastructure.
We don't yet handle synchronization of map/unmap callbacks vs. invalidations,
this will require some complex interaction with the kernel and is not a
major concern at this stage.
Cc: Alex Graf
Signed-off-by: David Gibson
Sig
pass something else in some cases to allow proper IOMMU
translation in future, but that will be fixed in later patches.
Cc: Kevin Wolf
Cc: Michael S. Tsirkin
Cc: Paolo Bonzini
Signed-off-by: David Gibson
Signed-off-by: Benjamin Herrenschmidt
---
dma-helpers.c | 24
: Benjamin Herrenschmidt
---
dma-helpers.c |2 ++
dma.h | 53 +++--
2 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/dma-helpers.c b/dma-helpers.c
index 2e09ceb..35cb500 100644
--- a/dma-helpers.c
+++ b/dma-helpers.c
@@ -31,6
: Alexey Kardashevskiy
Signed-off-by: David Gibson
Signed-off-by: Benjamin Herrenschmidt
---
hw/spapr.h |1 +
hw/spapr_iommu.c | 40 ++--
hw/spapr_pci.c | 15 +++
hw/spapr_pci.h |1 +
4 files changed, 39 insertions(+), 18 deletions
Munteanu
Signed-off-by: Benjamin Herrenschmidt
---
hw/pci.c |9 +
hw/pci.h |9 +++--
hw/pci_internals.h |2 ++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 5c75f16..99a4304 100644
--- a/hw/pci.c
+++ b/hw
Henderson
Signed-off-by: David Gibson
Signed-off-by: Benjamin Herrenschmidt
---
dma-helpers.c | 16 ++
dma.h | 95 +
hw/pci.h | 21 +++--
3 files changed, 123 insertions(+), 9 deletions(-)
diff -
from pci_dma_context() in the PCI case and
set to NULL in the SysBus case (i.e. we assume for now that a SysBus
AHCI has no IOMMU translation).
Cc: Kevin Wolf
Cc: Michael S. Tsirkin
Signed-off-by: David Gibson
Signed-off-by: Benjamin Herrenschmidt
---
hw/ide/ahci.c |
hash table
to the kernel and for the kernel to be able to impose limits on
the requested size.
Signed-off-by: David Gibson
Signed-off-by: Benjamin Herrenschmidt
---
hw/spapr.c | 88 --
hw/spapr.h |2 +-
target-ppc/kvm.c
On Wed, 2012-06-27 at 22:10 +1000, Benjamin Herrenschmidt wrote:
> From: David Gibson
>
> This adds support for then new "reset htab" ioctl which allows qemu
> to properly cleanup the MMU hash table when the guest is reset. With
> the corresponding kernel support, r
On Wed, 2012-06-27 at 14:30 +0200, Alexander Graf wrote:
> Thanks, applied to ppc-next. Next time, please base on top of a newer
> git base - I had to manually fix the patch to apply.
It was based on top of qemu master from yesterday. As you know that's
what I work on top of. Did you make sure you
On Wed, 2012-06-27 at 16:43 +0200, Alexander Graf wrote:
> On 14.06.2012, at 06:29, Alexey Kardashevskiy wrote:
>
> > The following patches add MSIX support for PCI on POWER.
> > The first aim is virtio-pci so it was tested. It will also support
> > VFIO when it becomes available in public.
>
> W
On Wed, 2012-06-27 at 14:08 +0200, Alexander Graf wrote:
> Ben, mind to push a working SLOF, we we can just enable all of it in
> one go and don't have to commit #if 0'ed code?
>
> Rest looks reasonable to me.
Sure, SLOF was gated by the memop patch but we can push it now. However
I'd rather leav
On Wed, 2012-06-27 at 16:32 +0200, Andreas Färber wrote:
> >> Did you test whether all those paths actually work with ppc? SPICE
> >> didn't support ppc host last time I checked. Does it work on x86
> host?
> > Currently, I test -vga std, it works well.
> > SPICE and curris are not supported on pcc
On Wed, 2012-06-27 at 23:42 +0200, Alexander Graf wrote:
>
> It shouldn't be an #if 0 but an if (cirrus) hw_abort() then though.
> Otherwise we'd just silently ignore the option.
You guys love aborts too much. For a high level option like -vga I'd
rather just fallback to "std" (like afaik some ot
> Doesn't qemu remove an fd handler before closing the fd?
> If not that's the bug right there.
No, it's just marked deleted, removal is deferred. But that doesn't
change the fact that you need to wake up select. Ie. What happens is:
- eventfd gets you fd #x
- thread 1 selects() on it which s
> >> diff --git a/iohandler.c b/iohandler.c
> >> index 3c74de6..54f4c48 100644
> >> --- a/iohandler.c
> >> +++ b/iohandler.c
> >> @@ -77,6 +77,7 @@ int qemu_set_fd_handler2(int fd,
> >> ioh->fd_write = fd_write;
> >> ioh->opaque = opaque;
> >> ioh->deleted = 0;
> >> +
On Mon, 2012-07-02 at 10:06 +1000, Alexey Kardashevskiy wrote:
> > Won't that conflict with the business in coroutine-sigaltstack.c ?
>
> The code which touches SIGUSR2 does not compile on power.
Oh, we don't get the altstack coroutine stuff ? interesting...
> > Hrm... looking at it, it looks li
On Mon, 2012-07-02 at 10:42 +1000, ronnie sahlberg wrote:
>
> Would it be possible to change the set-event-handlers functions to
> automatically call qemu_notify_event() when the descriptos change?
> To eliminate the need to call this function at all ?
That definitely sounds like the right thing
On Mon, 2012-07-02 at 10:06 +1000, Alexey Kardashevskiy wrote:
> I already posted another patch with qemu_notify_event() in this mail
> thread later :)
Yup, just saw that, for some reason I got dropped from the CC list.
BTW. I told you there must be an existing mechanism for that :-)
Cheers,
Ben
On Sun, 2012-07-08 at 23:08 +0800, Li Zhang wrote:
> > Are you sure we want to set these in -nographic or -vga none mode as
> well?
>
> I am not sure about this.
>
> Ben, would you please give more information about this?
Doesn't matter much. They are only useful when there is a vga adapter,
the
On Wed, 2012-06-27 at 22:10 +1000, Benjamin Herrenschmidt wrote:
> From: David Gibson
>
> This adds support for then new "reset htab" ioctl which allows qemu
> to properly cleanup the MMU hash table when the guest is reset. With
> the corresponding kernel support, r
On Tue, 2012-07-10 at 17:25 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-06-27 at 22:10 +1000, Benjamin Herrenschmidt wrote:
> > From: David Gibson
> >
> > This adds support for then new "reset htab" ioctl which allows qemu
> > to properly cleanup
On Tue, 2012-07-10 at 10:55 -0600, Alex Williamson wrote:
>
> I wish you could do this through a MemoryListener like we do on x86.
>
Can you elaborate ? TCE (iommu) manipulation on PAPR is done via
specific hypervisor calls, not sure what a MemoryListener would do
here ...
Cheers,
Ben.
On Tue, 2012-07-10 at 15:48 -0600, Alex Williamson wrote:
> > specific hypervisor calls, not sure what a MemoryListener would do
> > here ...
>
> Hmm, the guest directed iommu updates via hypercalls may not really fit
> the MemoryListener model. I'm just trying to think of ways to avoid
> having
On Wed, 2012-07-11 at 09:55 +1000, Alexey Kardashevskiy wrote:
> On 11/07/12 08:26, Scott Wood wrote:
> > On 07/10/2012 12:51 AM, Alexey Kardashevskiy wrote:
> >> The patch enables VFIO on POWER.
> >>
> >> It literally does the following:
> >>
> >> 1. POWERPC IOMMU support (the kernel counterpart i
On Wed, 2012-07-11 at 10:17 +1000, Alexey Kardashevskiy wrote:
> So the current one would be SPAPR_TCE_32?
No, the iommu type is SPAPR_TCE, but the *window* info you get here is
the 32-bit window. My thinking is add some versionning and a bunch of
reserved fields to that info struct so we can stic
On Wed, 2012-07-11 at 12:54 +1000, Alexey Kardashevskiy wrote:
> > Why do you need this, aren't the extension checks sufficient for this to
> > be a nop for you?
>
>
> It uses ioapic_remove_gsi_eoi_notifier() so it needs some #ifdef anyway. And
> as we do not support
> kvm_irqchip_in_kernel(), t
On Wed, 2013-01-30 at 07:59 -0600, Anthony Liguori wrote:
> An x86 CPU has a MMIO capability that's essentially 65 bits. Whether
> the top bit is set determines whether it's a "PIO" transaction or an
> "MMIO" transaction. A large chunk of that address space is invalid of
> course.
>
> PCI has a
On Wed, 2013-01-30 at 17:54 +0100, Andreas Färber wrote:
>
> That would require polymorphism since we already need to derive from
> PCIDevice or ISADevice respectively for interfacing with the bus...
> Modern object-oriented languages have tried to avoid multi-inheritence
> due to arising complica
On Wed, 2013-01-30 at 18:08 +0100, Paolo Bonzini wrote:
> > Make VGACommonState a proper QOM object and use it as the base class
> for
> > QXL, CirrusVGA, QEMUVGA (std-vga), and VMwareVGA.
>
> I think QXL should have-a VGA rather than being one. It completely
> bypasses the VGA infrastructure if
On Wed, 2013-01-30 at 15:39 -0600, Anthony Liguori wrote:
> Benjamin Herrenschmidt writes:
> > There also exists P2P bridges doing such substractive
> > decoding, this used to be fairly common with transparent bridges used for
> > laptop docking.
>
> I'm not
On Thu, 2013-01-31 at 00:20 +0200, Michael S. Tsirkin wrote:
>
> Well you can have a PCI bridge and a legacy device behind that.
> I think real PCI express devices can not be mapped onto legacy address
> ranges.
In practice they do (VGA at least)
>From a SW modelling standpoint, I don't think it
On Thu, 2013-01-31 at 00:49 +0200, Michael S. Tsirkin wrote:
> > In practice they do (VGA at least)
> >
> > >From a SW modelling standpoint, I don't think it's worth
> differentiating
> > PCI and PCIE.
> >
> > Cheers,
> > Ben.
>
> Interesting.
> Do you have such hardware? Could you please dump
>
On Thu, 2013-01-31 at 12:49 +0200, Michael S. Tsirkin wrote:
> OK but this appears behind a bridge. So the bridge configuration tells
> the root complex where to send accesses to the VGA.
Sort-of, again the root complex isn't "sending" anything targeted here.
PCIe is point to point and any devic
On Thu, 2013-01-31 at 09:34 -0700, Alex Williamson wrote:
> > Luckily guests do not seem to be worried as long as we use ACPI.
>
> Yes, in fact I just figured out last night that Windows is unhappy with
> assigned PCI devices on bus 0 that claim to be an endpoint in their PCIe
> capability rather
On Thu, 2012-09-27 at 11:33 +0200, Alexander Graf wrote:
>
> I think the command line should override anything user specified. So
> basically:
>
> * user defined -boot option (or bootindex magic from Gleb)
> * nvram
> * fallback to default
>
> > Eventually we should try to implement some s
On Thu, 2012-09-27 at 11:51 +0200, Gleb Natapov wrote:
> Yes, forget about -boot. It is deprecated :) You should use bootindex
> (device property) to set boot priority. It constructs OF device path
> and passes it to firmware. There is nothing "blurry" about OF device
> path.
Of course it is ;-)
On Fri, 2012-10-05 at 02:43 +0200, Alexander Graf wrote:
> > We should also be able to get the raw bootindex values for a qdev,
> > yes? I was thinking we could instead copy those values into the
> > device tree when we populate it. The trouble is that we don't
> > actually generate (in qemu) nod
On Fri, 2012-10-05 at 09:42 -0500, Anthony Liguori wrote:
> > - We have a problem with PCI. Currently, the content of the PCI
> > bus(ses) is discovered by SLOF running inside the guest. Not by qemu.
> > It's SLOF that assigns the BARs and create the device-tree nodes for the
> > various PCI devic
On Fri, 2012-10-05 at 08:26 -0700, Erlon Cruz wrote:
> >
> > Why not add a proper RTAS and do this work there?
>
> The RTAS call is how the guest will communicate with the host. It
> doesn't have a way to get interrupted and notified about any changes.
> So
> to start the changing of something,
On Sun, 2012-10-07 at 00:54 +1000, David Gibson wrote:
> I also don't see how it helps in this situation. The hotplug will
> still be initiated by qemu, so we'd have to work out how qemu
> communicates the info to RTAS, and how RTAS communicates it to the
> kernel, doubling the work.
This is not
On Thu, 2012-09-06 at 11:56 +0930, Rusty Russell wrote:
> Excellent. I have applied and pushed this revision.
>
> I was tempted to ask for an explicit endian marker, as switching to
> explicit little endian was high on the TODO list for virtio2. On the
> other hand, we could say virtio2-pci conf
On Wed, 2012-09-12 at 17:53 +0200, Alexander Graf wrote:
> On 09/12/2012 04:54 PM, Erlon Cruz wrote:
> > Hi all,
> >
> > We are planning to implement DLPAR capacity on QEMU pSeries. As we
>
> What is DLPAR? Hotplug support?
Yes.
> > lack of experience in the internals of the arch we would like y
On Thu, 2012-09-13 at 12:15 -0300, Erlon Cruz wrote:
> >> > lack of experience in the internals of the arch we would like you guys
> >> > to give us some design directions
> >> > and confirm if we going in the right direction. Our first idea is:
> >> >
> >> > 1 - to patch 'spapr.c' so it can
of a more interesting approach doing a virtio-vga,
which Anthony and I have been hacking on a bit, but due to time
constraints haven't really finished at this point.
In any case, I'm fine with this patch but does it help anybody ?
Cheers,
Ben.
> Cc: Benjamin Herrenschmidt
> Sig
On Fri, 2013-03-15 at 13:33 +0100, Alexander Graf wrote:
> On 14.03.2013, at 02:53, David Gibson wrote:
>
> > Currently, the pseries machine initializes the cpus, then the XICS
> > interrupt controller. However, to support the upcoming in-kernel XICS
> > implementation we will need to initialize
On Sat, 2013-03-16 at 06:33 +0100, Alexander Graf wrote:
> >> We're changing that notion in the in-kernel XICS discussions. The
> flow will look like this:
> >>
> >> * create vcpus
> >> * create XICS
> >> * foreach (vcpu)
> >> * enable_cap(vcpu, CAP_XICS_SERVER, xics_handle)
> >
> > This
On Sat, 2013-03-16 at 23:11 +1100, Alexey Kardashevskiy wrote:
> > No, LUNs are composed of four 2-byte big-endian values.
>
> I cannot find it in "SCSI Commands References Manual"
> (for example here -
> http://www.seagate.com/staticfiles/support/disc/manuals/Interface%
> 20manuals/100293068c.pd
On Sat, 2013-03-16 at 14:09 +0100, Paolo Bonzini wrote:
> > The confusion comes from the old SCSI protocol LUN as a 2 bytes number
> > identifying a unit for a given bus/device and the "new style" LUN as a
> > more generic concept such as used in SRP (ie vscsi is SRP) which
> > encompass the bus,
On Thu, 2013-08-15 at 16:47 +0200, Andreas Färber wrote:
> When we instantiate a -cpu POWER9 then having one POWER9_vX.Y around to
> back it doesn't really hurt. Unlike ARM's MIDR there doesn't seem to be
> an encoding of IBM vendor or POWER family in the PVR. The macros and
> their new implementat
On Thu, 2013-08-15 at 19:28 -0500, Anthony Liguori wrote:
> On Thu, Aug 15, 2013 at 7:20 PM, Benjamin Herrenschmidt
> wrote:
> > On Thu, 2013-08-15 at 16:47 +0200, Andreas Färber wrote:
> >> comparing values for closest match. So that if you have a v2.4 and QEMU
> >&g
On Tue, 2013-08-20 at 11:09 +0200, Paolo Bonzini wrote:
> > Sorry if I miss anything, but is not it what the patch already
> does? :)
>
> No, you need to expose multitce unconditionally in the device tree.
If I'm not mistaken the multitce kernel side patches are still not
upstream so I disagree.
On Tue, 2013-08-20 at 11:15 +0200, Paolo Bonzini wrote:
>
> - provide the infrastructure to enable/disable it from the command
> line
> (which will be enough design effort alone);
... why do things simply when we can come up with a cathedral
instead ?
> - add pseries-1.6 as a synonym of pseries
On Tue, 2013-08-20 at 11:22 +0200, Paolo Bonzini wrote:
>
> Uhm... I thought Alex and I were the one who proposed the simple things.
> You _will_ need to do the complicated stuff sooner or later, but it's
> probably early enough now to ignore it.
>
> And I'm not saying this out of love for big c
On Tue, 2013-08-20 at 12:14 +0200, Paolo Bonzini wrote:
> > I suppose if RH is going to deploy 3.10 and we aren't going to backport
> > the multitce patches then there *might* be a case for supporting that
> > combo specifically... but it's going to be that bad every time we add
> > a new feature w
On Sun, 2013-08-25 at 17:41 +0100, Alexander Graf wrote:
>
> While I don't think any harm could happen from it, this could lead to
> a potential timing attack where we read and write from different
> locations in memory if the guest swizzles the request while we're
> processing it.
>
> It's certa
On Sun, 2013-08-25 at 19:32 +0100, Alexander Graf wrote:
> > + * At this point we are only interested in reading only bolted
> entries
> > + */
> > +ghf.flags = KVM_GET_HTAB_BOLTED_ONLY;
> > +ghf.start_index = index;
> > +htab_fd = kvm_vm_ioctl(kvm_state, KVM_PPC_GET_HTAB_FD, &g
On Sun, 2013-08-25 at 17:41 +0100, Alexander Graf wrote:
> > +vcap = &req->iu.mad.capabilities;
> > +rc = spapr_vio_dma_read(&s->vdev, be64_to_cpu(vcap->buffer),
> > +&cap,
> be16_to_cpu(vcap->common.length));
>
> While I don't think any harm could happen from i
On Mon, 2013-08-26 at 09:03 +0530, Aneesh Kumar K.V wrote:
>
> because non bolted entries could be invalidated and reused by the time
> we look at the returned hpte values. I am not sure, whether it is ok or
> we need to make sure such a thing doesn't happen. For the use case i am
> looking at, ie
On Mon, 2013-08-26 at 10:02 +0530, Nikunj A Dadhania wrote:
>
> From: Nikunj A Dadhania
>
> This implements capabilities exchange between host and client.
> As at the moment no capability is supported, put zero flags everywhere
> and return.
>
> Signed-off-by: Nikunj A Dadhania
> ---
> hw/sc
On Mon, 2013-08-26 at 06:44 +0100, Alexander Graf wrote:
> > +cap.flags = 0;
> > +cap.migration.ecl = 0;
> > +cap.reserve.type = 0;
> > +cap.migration.common.server_support = 0;
> > +cap.reserve.common.server_support = 0;
>
> My question stands unanswered. Is this just memset(0
On Mon, 2013-08-26 at 10:43 +0200, Alexander Graf wrote:
> Do we ever need to preserve random fields in that struct? Or would it
> be clearer to just set the whole thing to 0 and then go from there?
Yeah sort of, we set/clear bits more/less based on what the guest
put in the first place, it's a bi
On Mon, 2013-08-26 at 15:11 +0200, Alexander Graf wrote:
> On 19.08.2013, at 07:55, Alexey Kardashevskiy wrote:
>
> > From: David Gibson
> >
> > Recent PowerKVM allows the kernel to intercept some RTAS calls from
> the
> > guest directly. This is used to implement the more efficient
> in-kernel
On Mon, 2013-08-26 at 15:37 +0200, Paolo Bonzini wrote:
> There are certainly cases where time-of-check-to-time-of-use
> vulnerability could make QEMU access uninitialized memory (or worse,
> out-of-bounds arrays). For example, you could try racing the host on
> the length of a scatter/gather list
On Mon, 2013-08-26 at 15:43 +0200, Paolo Bonzini wrote:
> Il 23/08/2013 11:23, Alexey Kardashevskiy ha scritto:
> > The existing driver just dropped unsupported requests. This adds error
> > responses to those unhandled requests.
> >
> > Signed-off-by: Alexey Kardashevskiy
> > ---
> > hw/scsi/sp
On Tue, 2013-08-27 at 03:48 +0200, Andreas Färber wrote:
> Also, QEMU is definitely not the only project that has higher
> acceptance
> criteria than patch-works-for-the-patch-author. :)
There's a difference between high acceptance criteria and systematic
bike shed painting including in some case
On Tue, 2013-08-27 at 13:26 +0300, Michael S. Tsirkin wrote:
> e would end up with something like
> >
> > diff --git a/kvm-all.c b/kvm-all.c
> > index 716860f..ca3251e 100644
> > --- a/kvm-all.c
> > +++ b/kvm-all.c
> > @@ -1190,6 +1190,10 @@ int kvm_irqchip_add_msi_route(KVMState *s,
> > MSIMessa
On Thu, 2013-08-29 at 14:52 +1000, Paul Mackerras wrote:
> We are going to need a way to do that for pseries guests. So for
> example if we are running on a POWER8 machine and using KVM, we would
> want to be able to tell qemu that we want a POWER7 machine and have
> qemu put 0x0f03 in the dev
On Fri, 2013-08-30 at 16:34 +0200, Alexander Graf wrote:
> > So - kvmppc_define_rtas_in_kernel() or kvmppc_define_rtas_kernel_token()?
>
> The former probably.
I told him the latter :-) Honestly, your name is gross :-) Mine
describes exactly what the calls does.
> > I would actually though that
On Wed, 2013-09-04 at 21:40 +1000, Alexey Kardashevskiy wrote:
> One of the examples (came from Paul) is:
> the host runs on POWER8, the guest boots a kernel which is capable of
> POWER7 only + POWER7-compat. We do this reboot tweak and boot in
> POWER7-compat mode. Then the guest does "yum update"
On Thu, 2013-09-05 at 11:08 +0200, Alexander Graf wrote:
> On 04.09.2013, at 23:05, Richard Henderson wrote:
>
> > This lets us change "le_mode" to "end_mode" and fold away nearly all
> > of the tests for the current cpu endianness, and removing all of the
> > explicitly generated bswap opcodes.
On Thu, 2013-09-05 at 19:48 +1000, Alexey Kardashevskiy wrote:
> >> I do not have pure guest timebase in QEMU and I need it on the destination.
> >> But I have host timebase + offset to calculate it. And tb_offset is already
> >> in ppc_tb_t. It looked logical to me to send the existing field and a
On Thu, 2013-09-05 at 11:58 +0200, Alexander Graf wrote:
> > Yes. I do not really understand the problem here (and I am not
> playing
> > dump). Do you suggest sending just the guest timebase and do not
> send the
> > host timebase and the offset (one number instead of two)? I can do
> that,
> > m
On Tue, 2014-09-23 at 14:30 +0200, Gerd Hoffmann wrote:
> Hi,
(Adding Mike)
> Series applies on top of the vga patches posted yesterday.
> It adds a mmio register to the pci stdvga cards allowing
> to switch framebuffer endiannness. Ben's patches 1+2 prepare
> for runtime-swicthable endianness
The properties in the CPU nodes for expressing the cache block size
are spelled {d,i}-cache... not {d,i}cache...
Also add the "line" variants in addition to the "block" variants for
completeness (some OSes might require them).
Signed-off-by: Benjamin Herrenschmidt
---
On Wed, 2014-06-11 at 12:47 +0200, Paolo Bonzini wrote:
> Ok, I can buy removing the support for CPU != 0. But still, the
> overengineering remains.
>
> If Alexey needs to trigger the NMI on all CPUs, simply moving the new
> method from CPU to Machine, and blindly using first_cpu in s390 and x8
Hi !
So while trying to solve an issue we have with qemu/kvm and powerpc who
can be both LE and BE nowadays, we thought the ideal solution would be
to have a register in the emulated VGA to control the endian.
Since qemu wishes to remain as much as possible in sync / compatible
with Bochs, I'm po
On Mon, 2014-06-16 at 11:45 +0100, Peter Maydell wrote:
> On 16 June 2014 11:30, Benjamin Herrenschmidt
> wrote:
> > So while trying to solve an issue we have with qemu/kvm and powerpc who
> > can be both LE and BE nowadays, we thought the ideal solution would be
> > t
Hi folks !
WARNING: The patch below is NOT intended for merging for rather obvious
reasons in its current form :-)
So basically, we have a problem we need to solve in qemu powerpc related
to the emulated VGA, as I mentioned in an earlier mail yesterday.
The core issue stems from the fact that gr
On Tue, 2014-06-17 at 06:40 +0200, Paolo Bonzini wrote:
> Il 17/06/2014 05:07, Benjamin Herrenschmidt ha scritto:
> > I've come up with the proof of concept below which changes the various
> > line drawing functions in vga-template to select the right ld/st
> > functio
On Tue, 2014-06-17 at 07:36 +0200, Paolo Bonzini wrote:
> Il 17/06/2014 06:59, Benjamin Herrenschmidt ha scritto:
> > Thanks. I've tried the other approach of adding new functions which
> > means no overhead (hopefully) for the non-swap case and less invasive
> >
On Tue, 2014-06-17 at 12:00 +0200, Greg Kurz wrote:
> There has been a discussion already about virtio endianness: relying on
> a guest system wide setting such as LPCR_ILE has been strongly rejected
> at the time... The consensus for virtio is "device endianness is the
> endianness of the CPU that
On Tue, 2014-06-17 at 11:19 +0100, Peter Maydell wrote:
> On 17 June 2014 11:09, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2014-06-17 at 12:00 +0200, Greg Kurz wrote:
> >> There has been a discussion already about virtio endianness: relying on
> >> a guest system
On Tue, 2014-06-17 at 12:45 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > The core issue stems from the fact that graphic stacks including X and a
> > number of other components along the way are terminally broken if the
> > framebuffer endianness doesn't match the guest endianness. We can
> > discuss
On Tue, 2014-06-17 at 13:40 +0200, Greg Kurz wrote:
> This conclusion was reached while discussing dump support where we
> use LPCR_ILE, and I wanted to add a common helper to be used by
> virtio. Please find the thread in the link below:
>
> https://lists.nongnu.org/archive/html/qemu-devel/2014-0
On Tue, 2014-06-17 at 13:57 +0200, Gerd Hoffmann wrote:
> Ok, it is supposed to work this way:
>
> The virtual graphics card creates a DisplaySurface, which is a pixman
> image under the hood. There are basically two ways to do that:
>
> (1) Use qemu_create_displaysurface(). Allocates host m
On Tue, 2014-06-17 at 23:12 +0100, Peter Maydell wrote:
> On 17 June 2014 22:32, Benjamin Herrenschmidt
> wrote:
> > Additionally, I wouldn't mind of we did a quick "trick" equivalent (but
> > cleaner) to what I did in my patch which is when the pseries guest
On Wed, 2014-06-18 at 01:05 +0200, Alexander Graf wrote:
> Given that, the prerequisite to that interface is to have a guest
> exposed register to flip the endianness in the first place. I think it
> makes most sense to settle on that register first, then talk about
> potential backwards compat
On Wed, 2014-06-18 at 13:18 +0200, Gerd Hoffmann wrote:
> The dispi interface has a versioned id too (VBE_DISPI_IDx) which we
> could use too. Which makes sense IMO if we add the register to the
> bochs dispi registers.
>
> We could also place the register in pci config space, then indicate it
>
On Wed, 2014-06-18 at 14:23 +0200, Gerd Hoffmann wrote:
> With this patch the qemu console core stops using PixelFormat and pixman
> format codes side-by-side, pixman format code is the primary way to
> specify the DisplaySurface format:
>
> * DisplaySurface stops carrying a PixelFormat field.
>
On Thu, 2014-06-19 at 11:36 +0200, Gerd Hoffmann wrote:
> If not -- then I prefer to play save and not use a vbe register to avoid
> ending up with two incompatible bochs interface revisions. If you don't
> like the pci config space option -- the mmio bar has plenty of free
> space left ;)
I'll f
On Sat, 2014-06-21 at 15:37 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-19 at 11:36 +0200, Gerd Hoffmann wrote:
> > If not -- then I prefer to play save and not use a vbe register to avoid
> > ending up with two incompatible bochs interface revisions. If you don
On Mon, 2014-06-16 at 20:30 +1000, Benjamin Herrenschmidt wrote:
> Hi !
>
> So while trying to solve an issue we have with qemu/kvm and powerpc who
> can be both LE and BE nowadays, we thought the ideal solution would be
> to have a register in the emulated VGA to control the en
On Mon, 2014-06-16 at 20:30 +1000, Benjamin Herrenschmidt wrote:
> Hi !
>
> So while trying to solve an issue we have with qemu/kvm and powerpc who
> can be both LE and BE nowadays, we thought the ideal solution would be
> to have a register in the emulated VGA to control the en
On Sun, 2014-06-22 at 12:10 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2014-06-21 at 15:37 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2014-06-19 at 11:36 +0200, Gerd Hoffmann wrote:
> > > If not -- then I prefer to play save and not use a vbe register to avoid
> &
101 - 200 of 1367 matches
Mail list logo
