On Mon, 2013-07-22 at 08:30 +0200, Paolo Bonzini wrote:
I suggest you check in the relevant part of the vscsi spec how you are
supposed to send back errors (FUNCTION REJECTED, INCORRECT LUN).
Once you do that, implementing the query TMFs is trivial.
The vscsi spec is just the transport around
On Sun, 2013-07-21 at 20:04 +1000, Alexey Kardashevskiy wrote:
At the moment the guest kernel issues two types of task management requests
to the hypervisor - task about and lun reset. This adds handling for
these tasks.
My worry is that the specification calls for all of them, and we don't
On Mon, 2013-07-22 at 10:20 +1000, Alexey Kardashevskiy wrote:
May be. But there was no way to get this callback called till I started
calling scsi_req_cancel in this patch so I would not split.
You probably still should. The smaller each individual patch, the better
(in part because that makes
On Mon, 2013-07-22 at 10:57 +1000, Alexey Kardashevskiy wrote:
On 07/22/2013 10:23 AM, Benjamin Herrenschmidt wrote:
On Mon, 2013-07-22 at 10:20 +1000, Alexey Kardashevskiy wrote:
May be. But there was no way to get this callback called till I started
calling scsi_req_cancel in this patch
On Wed, 2013-07-17 at 19:46 +1000, Alexey Kardashevskiy wrote:
Current hcd-ohci does not handle DMA errors which can actually
happen.
However it is not clear what approach should be used here -
for example, get_dwords returns positive number saying that there
is no error as all the callers
On Wed, 2013-07-17 at 14:31 +0200, Alexander Graf wrote:
On 17.07.2013, at 13:15, Benjamin Herrenschmidt wrote:
On Wed, 2013-07-17 at 19:46 +1000, Alexey Kardashevskiy wrote:
Current hcd-ohci does not handle DMA errors which can actually
happen.
However it is not clear what approach
On Tue, 2013-07-16 at 10:32 +0200, Alexander Graf wrote:
Did I miss anything here?
No, I don't think so. The patch looks good.
... and will break all Mac targets again, no? Not to speak of non-ppc
devices.
Do you know why it breaks ? Can you suggest what's wrong and how to fix
it
On Mon, 2013-07-15 at 09:01 -0500, Anthony Liguori wrote:
On PPC, le_mode only really affects load/stores and instruction
decoding. Any shared data structures between the CPU and OS remain big
endian.
Translation:
On ppc with the specific machine type pseries which emulates a
paravirtualized
On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote:
We model a single system wide io space today and access to that one
happens through you pci host controller. I just messed up the
terminology here.
Single system wide IO space is broken. We have separate IO space per
PHB. That was
On Fri, 2013-07-12 at 19:04 +0200, Hervé Poussineau wrote:
When PowerPC little-endian is in effect but before system's
little-endian is in effect, the address munge becomes effective. If we
need to access system endian port (byte) address, say 0x8092, the
program needs to issue
On Fri, 2013-07-12 at 12:49 -0500, Anthony Liguori wrote:
Unless they are completely broken (and those exist, don't get me wrong,
though mostly they are a thing of a past long gone), bridges and busses
have no effect on endianness.
That's simply not true. There are programmable PCI
On Fri, 2013-07-12 at 19:26 +0100, Peter Maydell wrote:
It's not wrong when the hardware actually does a byteswap at
some level in the memory hierarchy. You can see this for instance
on ARMv7M systems, where byteswapping for bigendian happens at
an intermediate level that not all accesses go
On Fri, 2013-07-12 at 14:06 -0500, Anthony Liguori wrote:
In the light of this, I think there should only be one endianness
for
all memory accesses (which could be changed at runtime),
We already do this, it's host native endian.
The simple fact that you used the word endian makes it
On Sat, 2013-07-13 at 00:10 +0100, Peter Maydell wrote:
The block marked byteswap here does byte invariant bigendian,
so byte accesses are unchanged, 16 bit accesses have the two words
of data flipped, and 32 bit accesses have the four bytes flipped;
this happens as the data passes through;
On Thu, 2013-07-11 at 15:28 +0200, Alexander Graf wrote:
So IIUC before cpu_inw and inl were doing portio accesses in host
native endianness. Now with this change they do little endian
accesses. All sensible callers of cpu_inX assume that data is passed
in native endianness though and already
On Thu, 2013-07-11 at 15:28 +0200, Alexander Graf wrote:
Semantically having your PCI host bridge do the endianness conversion
is the correct way of handling it, as that's where the conversion
happens. If it makes life easier to do it in the isa bridging code,
that's fine for me too though.
On Tue, 2013-07-09 at 17:21 +1000, David Gibson wrote:
Did you mean missing typedef?
I think he means the kernel_style_struct_name instead of the
QemuStyleStudlyCapsStructName.
Looks like we missed the mandatory MakeCodeFugly rule of qemu :-)
Cheers,
Ben.
On Tue, 2013-07-09 at 08:58 -0500, Anthony Liguori wrote:
There's nothing gross about making the things that are devices
devices.
But there is no such thing as the XICS ...
The XICS is just the combination of ICP's and ICS... so XICS *is* the
device...
Cheers,
Ben.
On Wed, 2013-07-10 at 01:11 +1000, David Gibson wrote:
More precisely, DCRs are only needed on the BookE CPUs which have
them. They can be added later without breaking compatibility, and
would be best added by someone working on the BookE stuff who can test
it properly.
DCRs are also not in
On Mon, 2013-07-08 at 13:39 -0500, Anthony Liguori wrote:
+.fields = (VMStateField []) {
+/* Sanity check */
+VMSTATE_UINT32_EQUAL(liobn, sPAPRTCETable),
+VMSTATE_UINT32_EQUAL(window_size, sPAPRTCETable),
+
+/* IOMMU state */
+
On Mon, 2013-07-08 at 13:45 -0500, Anthony Liguori wrote:
I vaguely recall making the suggestion to use a live section like
this. How large is the HTAB typically?
Depends on how much RAM you put in your VM. The default is around 16M
but it can get bigger.
Cheers,
Ben.
On Mon, 2013-07-08 at 17:15 -0500, Anthony Liguori wrote:
Hypercall arguments are passed in CPU endianness so what's being stored
in the tce table is CPU endianness.
Since VBUFFER just does a blind write() of the full array of uint64s,
what goes on the wire will be CPU endianness.
So if
On Tue, 2013-07-09 at 13:40 +1000, Alexey Kardashevskiy wrote:
No, why? It is a per CPU state of XICS controller, never exists apart
from XICS.
ICP is. ICS is ... different but can mostly be considered to be the
XICS itself.
Anthony, we could be completely anal about it and create a gigantic
On Thu, 2013-07-04 at 07:54 +0200, Andreas Färber wrote:
Am 27.06.2013 08:45, schrieb Alexey Kardashevskiy:
From: Prerna Saxena pre...@linux.vnet.ibm.com
This patch enables QEMU to launch VM guests on POWER8 chip. I have tested
this to work with BML kernel on P8 dd1 chip.
On Sun, 2013-06-30 at 10:59 +1000, Alexey Kardashevskiy wrote:
1) A PCI bus function to do the MSI - virq mapping
2) On x86 (and e500), this is implemented by calling
kvm_irqchip_add_msi_route()
3) On pseries, this just returns msi-data
Perhaps (2) can just be the default PCI bus
On Sun, 2013-06-23 at 17:07 +0300, Michael S. Tsirkin wrote:
Yes I think that's fine really.
Basically devices all speak MSIMessage as they should -
this is what the PCI spec says.
On all normal systems guests also speak MSIMessage so
the API which uses these makes sense for kvm.
On Sun, 2013-06-23 at 10:02 -0500, Anthony Liguori wrote:
It doesn't make a lot of sense to have Power do MSI decoding in
userspace while x86 does it in the kernel. I assume the kernel
doesn't have enough information to do the translation on Power?
Well, it would need the host bridge which it
On Fri, 2013-06-21 at 00:03 -0600, Alex Williamson wrote:
On Fri, 2013-06-21 at 15:12 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-06-20 at 22:46 -0600, Alex Williamson wrote:
Maybe you could add a device parameter to kvm_irqchip_add_msi_route so
that it can be implemented on POWER
On Fri, 2013-06-21 at 12:31 +0200, Alexander Graf wrote:
On 21.06.2013, at 11:22, Alexey Kardashevskiy wrote:
Previously every PCI host bridge implemented its own MSI memory window
in order to catch msi_notify()/msix_notify() calls from various QEMU
MSI-capable devives such as virtio-pci
On Fri, 2013-06-21 at 12:33 +0200, Alexander Graf wrote:
+int kvm_arch_irqchip_add_msi_route(KVMState *s, MSIMessage msg)
+{
+if (!kvm_msi_via_irqfd_allowed)
+return -1;
+
+msg.address -= spapr-msi_win_addr;
+return (msg.address 2) + msg.data;
This breaks
On Fri, 2013-06-21 at 06:58 -0500, Anthony Liguori wrote:
I do not understand the question, really. Here we are emulating pHyp which
is not real hardware and never pretended to be. Our guests do not touch MSI
records in the config space and use RTAS MSI calls instead.
But RTAS is
On Fri, 2013-06-21 at 14:05 +0200, Alexander Graf wrote:
Oh, I thought that was obvious. BookE also has in-kernel emulation and
also does set kvm_msi_via_irqfd_allowed. The code above is spapr
specific and would simply rewrite valid BookE MPIC addresses into
something broken.
In fact, where
On Fri, 2013-06-21 at 15:46 +0200, Alexander Graf wrote:
Not sure. We could just declare a direct virq==irq mode in which
msi.data == virq == irq. No need for any translation then.
Maybe. Beware that MSI data is only 16-bit on the wire but we may not
care here.
One thing I'm not 100% certain
On Sat, 2013-06-22 at 00:12 +0200, Alexander Graf wrote:
On 21.06.2013, at 23:54, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-21 at 15:46 +0200, Alexander Graf wrote:
Not sure. We could just declare a direct virq==irq mode in which
msi.data == virq == irq. No need for any translation
On Fri, 2013-06-21 at 17:10 -0600, Alex Williamson wrote:
MSI-X is rather ugly. As you suggest, we trap accesses to the MSI-X
table. We don't know how many vectors the guest is going to use, so we
incrementally add them by disabling and re-enabling with a new vector
count. The host decides
On Thu, 2013-06-20 at 22:46 -0600, Alex Williamson wrote:
Maybe you could add a device parameter to kvm_irqchip_add_msi_route so
that it can be implemented on POWER without this pci_bus_map_msi
interface that seems very unique to POWER. Thanks,
You mean unique to all non-x86 ? :-)
I believe
On Wed, 2013-06-19 at 23:28 +0200, Alexander Graf wrote:
On 19.06.2013, at 22:40, Anthony Liguori wrote:
The creatively named reg field is a hypervisor assigned global
identifier for a virtual device. Despite the fact that no device
is assigned a reg of 0, guests still use it to refer to
On Fri, 2013-06-14 at 16:28 +0200, Andreas Färber wrote:
I would still love to see -M mac99 emulate a proper U2 or U1 based
system for 32bit. And I would also love to see a real U4 based
emulation model come up for qemu-system-ppc64. But I doubt I'll have
time to work on either :).
Uninorth
On Wed, 2013-06-12 at 10:00 -0400, Paolo Bonzini wrote:
The only bug we have is not a performance bug related to compression;
it's that writing zero pages breaks overcommit. Let's fix that, and
only that.
Right, do we have a way to madvise throw away these instead ? Or do we
have a way to
On Mon, 2013-06-10 at 19:10 +1000, Alexey Kardashevskiy wrote:
I would prefer not to completely drop the patch since it saves bandwidth and
resources.
I would like migration to do what it should do - send pages no matter what,
this is exactly what migration is for. If there any many, many
On Sun, 2013-06-09 at 12:34 +1000, Alexey Kardashevskiy wrote:
It is _live_ migration, the source sends changes, same pages can change and
be sent several times. So we would need to turn tracking on on the
destination to know if some page was received from the source or changed by
the
On Sun, 2013-06-09 at 10:16 +0800, Wenchao Xia wrote:
If an page was not received and destination knows that page should
exist according to total size, fill it with zero at destination, would
it solve the problem?
The easiest way to do that is to not write to those pages at the
destination
On Mon, 2013-06-03 at 15:46 +1000, Alexey Kardashevskiy wrote:
Ok. I implemented {save|load}_request for IBMVSCSI, started testing -
the
destination system behaves very unstable, sometime it is a fault in
_raw_spin_lock or it looks okay but any attempt to read the filesystem
leads to 100% cpu
On Fri, 2013-05-31 at 15:58 +1000, Alexey Kardashevskiy wrote:
And another question (sorry I am not very familiar with terminology but
cc:Ben is :) ) - what happens with indirect requests if migration happened
in the middle of handling such a request? virtio-scsi does not seem to
handle this
On Fri, 2013-05-31 at 12:41 +0200, Paolo Bonzini wrote:
It may be halfway through, but it is always restarted on the destination.
restarted as in the whole transfer is restarted if any right ? So we
can essentially consider as a new request for which we just did
scsi_req_enqueue() ?
IE. We
On Fri, 2013-05-17 at 09:42 +0200, 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 actively maintained, and shows quite
a few signs of bitrot,
Please be more
On Fri, 2013-05-17 at 14:25 +1000, David Gibson wrote:
Because the pseries machine type is optional (it is only built when libfdt
is available), this can result in a build with no default machine. In that
case vl.c will print a No machine found message. This seems reasonable,
given that as
On Thu, 2013-05-02 at 13:10 +0200, Alexander Graf wrote:
This patch is (in a modified, extended form) already in the tree:
Ah yes, it wasn't upstream when I started hacking on that stuff and
so I missed it. Just drop mine.
Cheers,
Ben.
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 b...@kernel.crashing.org
---
diff
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.pdf
).
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, ID and
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 the irq
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 is stupid. Why have
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 device
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 than
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 65 bit
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
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 not in
On Wed, 2013-01-30 at 15:39 -0600, Anthony Liguori wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org 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 sure I understand how
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
the output of
On Thu, 2012-11-22 at 11:25 +0100, Paolo Bonzini wrote:
Again, from memory, you were volunteered to do the initial x86
change so
we could piggy back on it :-) Or do I remember wrong ?
Please suggest an API, then we can work out the x86 changes. I can
volunteer myself, but I wasn't in the
Hi Jan !
David (CC) want to make some progress with our in-kernel PIC. From
memory, one of the outcomes of the BOF was that we need to move the
existing enable in-kernel PIC from generic KVM init to machine init in
order to be able to add an argument indicating the model use by the
arch/platform
On Mon, 2012-11-19 at 17:22 +0100, Alexander Graf 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 the irq controller before the
vcpus. This patch
On Wed, 2012-10-31 at 12:32 +0200, Avi Kivity wrote:
This has nothing to do with device endianness; we're translating from a
byte buffer (address_space_rw()) to a uint64_t
(MemoryRegionOps::read/write()) so we need to take host endianess into
account.
This code cleverly makes use of memory
On Tue, 2012-10-30 at 19:11 +, Blue Swirl wrote:
Why couple this with host endianness? I'd expect IOMMU to operate at
target bus endianness, for example LE for PCI on PPC guest.
I'm not sure about putting the iommu in charge of endianness ...
On one hand it's fishy. It should be
On Fri, 2012-10-19 at 09:21 -0500, Anthony Liguori wrote:
That's true to an extent. However, I vehemently disagree that it's
arbitrary which one gets the new option. Neither -boot nor bootindex=
alter any persistent data now and they should not suddenly start doing
so.
That's not
On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote:
That's horrible; if you use -boot just once it will clobber a
persistent NVRAM's boot order. I see that a means of changing the
default boot order from management tools is desirable, but that
shouldn't be the normal behaviour of
On Tue, 2012-10-16 at 14:55 -0500, Anthony Liguori wrote:
4) If -boot is specified, the parameter should alter the contents of
NVRAM to change the boot order to what is specified by -boot.
5) If ,bootorder is specified, it should take predence over -boot.
6) ,bootorder= should also
On Mon, 2012-10-15 at 12:45 +0200, Avi Kivity wrote:
I haven't had a chance to review in details yet, but one thing I
noticed
is that you basically have a single read/write protection
information
for a translation.
This is a loss of functionality to some extent (well, maybe not from
On Sat, 2012-10-13 at 09:30 +, Blue Swirl wrote:
The problem with map and unmap is invalidations. How do you convey to
the devices having done a map that the guest has invalidated a
translation entry.
Also in Sparc32, IOMMU uses a table in RAM which the guest can change,
so a
On Thu, 2012-10-11 at 15:26 +0200, Avi Kivity wrote:
These patches add IOMMU support to the memory core. IOMMUs can be added
anywhere in
the memory hierarchy, and may be arranged in series.
I haven't had a chance to review in details yet, but one thing I noticed
is that you basically have a
On Thu, 2012-10-11 at 15:42 +0200, Paolo Bonzini wrote:
Il 11/10/2012 15:26, Avi Kivity ha scritto:
+struct MemoryRegionIOMMUOps {
+/* Returns a TLB entry that contains a given address. */
+IOMMUTLBEntry (*translate)(MemoryRegion *iommu, target_phys_addr_t
addr,
+
On Thu, 2012-10-11 at 15:57 +0200, Avi Kivity wrote:
Map/unmap is supported via address_space_map(), which calls
-translate(). I don't see how a lower-level map/unmap helps,
unless
the hardware supplies such a function.
Yep, it's just the map/unmap callbacks that are not supported
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 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) nodes for
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 devices.
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, the
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 sort of
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 ;-) They
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 b...@kernel.crashing.org
Signed-off
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 dynamically
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 you guys
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 config
On Thu, 2012-08-16 at 09:29 +0800, Li Zhang wrote:
Yes, that's pretty much what I was asking for (here and for the
mac99 u3 machine). Just base your patch on ppc-next. My patches are in
there.
That's great. Thanks a lot!
Note that you missed the hard freeze for qemu 1.2, it was today.
So
Hi hard a brain fart when coding that function, it will
fail to set the memory beyond the first 512 bytes. This
is in turn causing guest crashes in ibmveth (spapr_llan.c
on the qemu side) due to the receive queue not being
properly initialized.
Signed-off-by: Benjamin Herrenschmidt b
On Tue, 2012-08-14 at 13:04 +0200, Alexander Graf wrote:
Thanks, applied to ppc-next without the USB bits. I also get the
following warning now:
$ ./ppc64-softmmu/qemu-system-ppc64 -nographic -M pseries -kernel
/boot/vmlinux -initrd /boot/initrd -enable-kvm -m 1G -append
root=/dev/null
On Wed, 2012-08-15 at 09:10 +1000, David Gibson wrote:
I see. I will redo this patch. Send out it later. :)
Thanks for your comments.
When you do that, please also change the default to make spapr _not_
have usb.
FYI, I originally asked for USB as default ... however it looks like at
this
Only just saw this bug, I assume the problem still exist ? I have
somebody look at it next week
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1013691
Title:
ppc64 + virtio-scsi: only first scsi
On Tue, 2012-08-07 at 07:30 +0200, Gerd Hoffmann wrote:
On 08/06/12 23:16, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 15:20 +0200, Gerd Hoffmann wrote:
There are discussions about re-doing the guest/host interface (command
rings etc) now and then, by adding a qxl2 device (or maybe
On Tue, 2012-08-07 at 11:05 +0200, Alexander Graf wrote:
This patch therefore changes to ret = 0, which is both a bugfix and a small
optimization.
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Thanks, applied to ppc-next.
When do you plan to send your queue to Anthony ?
On Tue, 2012-08-07 at 16:41 +1000, David Gibson wrote:
qemu_system_reset() function always performs the same basic actions on
all machines. This includes running all the reset handler hooks,
however the order in which these will run is not always easily predictable.
This patch splits the
On Fri, 2012-08-03 at 17:01 +0200, Andreas Färber wrote:
I have posted a suggestion where CPU reset is triggered by the
machine
as an abstract concept (needs a bit of tweaking still, but the
general
idea is there).
Based on that, shouldn't it be rather easy to add a Notifier similar
to
On Mon, 2012-08-06 at 14:03 +0200, Gerd Hoffmann wrote:
Hacked up something like that a while back (patch attached). Doesn't
use DRM though, just plain old fbdev. Maybe you can reuse some bits
nevertheless.
/me wonders what the advantage of using drm is for non-3D hardware?
Thanks. Yeah
On Mon, 2012-08-06 at 16:02 +0200, Gerd Hoffmann wrote:
A vbe rom isn't a big deal. You probably want support the 0x01CE and
0x01CF ports (on x86) so the vgabios running in real mode can easily
reach the bochs interface registers without a protected mode round
trip
for mmio access.
I
On Mon, 2012-08-06 at 15:20 +0200, Gerd Hoffmann wrote:
There are discussions about re-doing the guest/host interface (command
rings etc) now and then, by adding a qxl2 device (or maybe even extend
stdvga), dropping a bunch of backward compatibility stuff in qxl.c.
Sending the spice commands
On Thu, 2012-08-02 at 17:17 +0200, Paolo Bonzini wrote:
On x86 we do not pre-load the kernel. Neither the kernel/initramfs
and
the option ROM that loads the kernel are written in memory, they are
passed to the guest via fw_cfg. Then the option ROM is loaded by the
BIOS, and loads the
On Wed, 2012-08-01 at 11:16 +0100, Stefan Hajnoczi wrote:
The len field is mostly informational. The virtio device driver
inside the guest may make use of it. In many cases it doesn't so an
incorrect len value has no effect. In
drivers/block/virtio_blk.c:blk_done() the len variable is
On Wed, 2012-08-01 at 21:37 -0500, Anthony Liguori wrote:
But all of the DT initialization stuff that is leading to this
discussion in the first place is a gross hack to make a PV
architecture
work that took far too many short cuts.
Building a DT in memory representing hardware instead of
On Tue, 2012-07-31 at 16:09 +1000, David Gibson wrote:
The pseries machine currently ignores the -usb command line option.
This patch corrects the problem by having it instantiate a PCI OHCI
USB host controller when -usb is specified.
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
On Tue, 2012-07-31 at 16:09 +1000, David Gibson wrote:
The pseries machine currently ignores the -usb command line option.
This patch corrects the problem by having it instantiate a PCI OHCI
USB host controller when -usb is specified.
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
801 - 900 of 1227 matches
Mail list logo
