From: Roland Elek
We need to hook into some of the core IDE functionality for AHCI. To
do that, the easiest way is to make explicit functions calls be implicit
through a function call struct.
Signed-off-by: Roland Elek
Signed-off-by: Alexander Graf
---
v1 -> v2:
- rename IDEExtender to ID
This patch converts the ISA MMIO bridge code to always use little endian mmio.
All bswap code that existed was only there to convert from native cpu
endianness to little endian ISA devices.
Signed-off-by: Alexander Graf
---
hw/bonito.c|4 +-
hw/gt64xxx.c |6 +--
hw/
There's no need to bswap once we correctly set the mmio to be little endian.
Signed-off-by: Alexander Graf
---
hw/unin_pci.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index f2e440e..5f15058 100644
--- a/hw/unin_pci.c
+++ b/hw/unin
This patch adds an emulation layer for an ICH-7M AHCI controller. For now
this controller does not do IDE legacy emulation. It is a pure AHCI controller.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- rename IDEExtender to IDEBusOps and make a pointer (kraxel)
- make dma hooks explicit by p
This patch replaces explicit bswaps with endianness hints to the
mmio layer.
Because we don't depend on the target endianness anymore, we can also
move the driver over to Makefile.objs.
Signed-off-by: Alexander Graf
---
Makefile.objs |1 +
Makefile.target |3 ---
hw/rtl8139.c| 1
I get a warning on a signed comparison with an unsigned variable, so
let's make the variable signed and be happy.
Signed-off-by: Alexander Graf
---
target-ppc/kvm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 5cacef7..5caa07
The way mmio endianness is currently implemented is horrifying.
In the real world, CPUs have an endianness and write out data
to the memory bus. Instead of RAM, a receiving side here can be
a device. This device gets a byte stream again and needs to
make sense of it.
Since big endian systems writ
This patch replaces explicit bswaps with endianness hints to the
mmio layer.
Because we don't depend on the target endianness anymore, we can also
move the driver over to Makefile.objs.
Signed-off-by: Alexander Graf
---
Makefile.objs |1 +
Makefile.target |3 ---
hw/usb-ohci.c |
This patch replaces explicit bswaps with endianness hints to the
mmio layer.
Signed-off-by: Alexander Graf
---
hw/ppc_prep.c | 38 +++---
1 files changed, 3 insertions(+), 35 deletions(-)
diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 80f5db6..1492266 100644
On Wed, 2010-11-24 at 11:46 +0100, Hannes Reinecke wrote:
> >> - when a read is aborted due to a mark/EOF/EOD/EOM, the len
> reported to
> >> controller can be 0. LSI controller emulation doesn't know how to
> manage
> >> this. A workaround found is to call the completion routine with
> >> SCSI_REA
On 11/25/10 09:46, Benjamin Herrenschmidt wrote:
So far tho, it appears that I can (at least with scsi-disk) rely on
always been eventually called with SCSI_REASON_DONE so my code (and
maybe the usb-msd code too, I haven't verified) relies on that to
complete requests... Is that incorrect ?
Ye
On 11/24/2010 05:52 PM, Christoph Hellwig wrote:
> On Wed, Nov 24, 2010 at 12:16:08PM +0100, Hannes Reinecke wrote:
>> Add callback to create a request with a predefined iovec.
>> This is required for drivers which can use the iovec
>> of a command directly.
>
> What happend to my comment that the
The way we're currently modeling mmio is too simplified. We assume that
every device has the same endianness as the target CPU. In reality,
most devices are little endian (all PCI and ISA ones I'm aware of). Some
are big endian (special system devices) and a very little fraction is
target native en
This patch replaces explicit bswaps with endianness hints to the
mmio layer.
Signed-off-by: Alexander Graf
---
hw/ppc4xx_pci.c | 17 ++---
1 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/hw/ppc4xx_pci.c b/hw/ppc4xx_pci.c
index f2ecece..f62f1f9 100644
--- a/hw/ppc4xx
On Thu, 2010-11-25 at 09:50 +0100, Gerd Hoffmann wrote:
> On 11/25/10 09:46, Benjamin Herrenschmidt wrote:
>
> > So far tho, it appears that I can (at least with scsi-disk) rely on
> > always been eventually called with SCSI_REASON_DONE so my code (and
> > maybe the usb-msd code too, I haven't ver
On 11/25/2010 10:01 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-11-25 at 09:50 +0100, Gerd Hoffmann wrote:
>> On 11/25/10 09:46, Benjamin Herrenschmidt wrote:
>>
>>> So far tho, it appears that I can (at least with scsi-disk) rely on
>>> always been eventually called with SCSI_REASON_DONE so m
On Thu, 2010-11-25 at 10:06 +0100, Hannes Reinecke wrote:
> No, this is exactly as I'm expecting the SCSI layer to work.
> So from the light of this the patch to scsi-generic is valid.
> And it really looks like papering over a bug in the lsi HBA code.
Ok. I have no special case tho for a complete
Right now, I've somewhat come up with:
- client request occurs
- call device send_command()
- if result is 0, assume my complete() was called with
SCSI_REASON_DONE
- else, use sign of result for transfer direction, store the
absolute value as the total expected transfer len
Am 25.11.2010 06:22, schrieb ronnie sahlberg:
> Nicholas,
> below.
>
> On Thu, Nov 25, 2010 at 3:32 PM, Nicholas A. Bellinger
> wrote:
>
>> But existing code aside, I think having a small userspace iSCSI
>> initiator built into QEMU that 'just works' across all host environments
>> would be a pr
Hi,
On (Wed) Nov 10 2010 [19:37:19], Michael Roth wrote:
> EXAMPLE USAGE:
>
> The commandline options are a little convoluted right now; this will
> addressed in later revisions.
>
> - Configure guest agent to talk to host via virtio-serial
> # start guest with virtio-serial/virtproxy/virt
On Thu, Nov 25, 2010 at 2:30 AM, FUJITA Tomonori
wrote:
> On Wed, 24 Nov 2010 13:38:59 +
> Stefan Hajnoczi wrote:
>
>> > This series adds rebased support for the hw/scsi-bsg.c backstore for
>> > scsi-bus
>> > compatible HBA emulation in QEMU-KVM on Linux hosts supporting the BSG
>> > driver
On 25.11.2010, at 11:18, Gerd Hoffmann wrote:
> On 11/25/10 08:35, Alexander Graf wrote:
>> The way mmio endianness is currently implemented is horrifying.
>>
>> In the real world, CPUs have an endianness and write out data
>> to the memory bus. Instead of RAM, a receiving side here can be
>> a
On 11/25/10 08:35, Alexander Graf wrote:
The way mmio endianness is currently implemented is horrifying.
In the real world, CPUs have an endianness and write out data
to the memory bus. Instead of RAM, a receiving side here can be
a device. This device gets a byte stream again and needs to
make
Dear Alexander Graf,
thank you for contacting me.
I hope that I am right when I understand your below email as a complaint
that we have not contacted you before organizing
this event.
First of all, we understand our event not as an official QEMU event nor
have we stated this anywhere or that t
On Thu, Nov 25, 2010 at 11:18:26AM +0100, Gerd Hoffmann wrote:
> On 11/25/10 08:35, Alexander Graf wrote:
> >The way mmio endianness is currently implemented is horrifying.
> >
> >In the real world, CPUs have an endianness and write out data
> >to the memory bus. Instead of RAM, a receiving side he
Wolfgang,
On 25.11.2010, at 11:30, wolfgang mueller wrote:
> Dear Alexander Graf,
> thank you for contacting me.
> I hope that I am right when I understand your below email as a complaint that
> we have not contacted you before organizing
> this event.
The complaint is mostly that you have no
On Thu, Nov 25, 2010 at 08:07:39AM +0100, Alexander Graf wrote:
> +static int pci_ahci_init(PCIDevice *dev)
> +{
> +struct AHCIPCIState *d;
> +d = DO_UPCAST(struct AHCIPCIState, card, dev);
> +
> +pci_config_set_vendor_id(d->card.config, PCI_VENDOR_ID_INTEL);
> +pci_config_set_devic
> This patch introduces configuration variables
> CONFIG_SCSI_LSI
> CONFIG_SCSI_MEGASAS
> and renames the existing CONFIG_ESP to CONFIG_SCSI_ESP.
> With this the available SCSI HBAs can be configured for each
> target configuration instead of compiling it in for everyone.
No. These are both PCI de
On Wed, Nov 24, 2010 at 02:08:16PM +, adq wrote:
> > Interesting. I was also thinking that maybe we can leverage overriding
> > mechanisms that are already available. Maybe it's possible to squeeze the
> > HPET node into an SSDT. Maybe we need to override the whole DSDT from the
> > command
Hi,
The first thing we have to check with Daniel is whether or not we're
providing the info they would need/expect,
Daniel?
apart from that I have the
following general comments:
1. It's missing documentation in QMP/qmp-events.txt and qmp-commands.hx
(yeah, docs are far from code,
Am 24.11.2010 12:00, Alexander Graf wrote:
According to to the Intel IA-32 Software Developers Manual Vol 3 page
290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
Signed-off-by: Andrew de Quincey
diff --git a/hw/apic.c b/hw/apic.c
index 5f4a87c..20304e0
> The way mmio endianness is currently implemented is horrifying.
Agreed.
> #ifdef TARGET_WORDS_BIGENDIAN
> val = bswap32(val);
> #endif
>
> With the move to get device code only compiled once, this has
> become harder and harder to justify though, since we don't know
> the target endianness
> Makefile.objs |1 +
> default-configs/i386-softmmu.mak |1 +
> default-configs/x86_64-softmmu.mak |1 +
Why are you only enabling this on x86? PCI devices, especially things like
SATA controllers, should be completely target independent.
Paul
On 25.11.2010, at 13:28, Paul Brook wrote:
>> Makefile.objs |1 +
>> default-configs/i386-softmmu.mak |1 +
>> default-configs/x86_64-softmmu.mak |1 +
>
>
> Why are you only enabling this on x86? PCI devices, especially things like
> SATA controllers, should b
> On 25.11.2010, at 13:28, Paul Brook wrote:
> >> Makefile.objs |1 +
> >> default-configs/i386-softmmu.mak |1 +
> >> default-configs/x86_64-softmmu.mak |1 +
> >
> > Why are you only enabling this on x86? PCI devices, especially things
> > like SATA controllers,
On 25.11.2010, at 13:45, Paul Brook wrote:
>> On 25.11.2010, at 13:28, Paul Brook wrote:
Makefile.objs |1 +
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
>>>
>>> Why are you only enabling this on x86? PCI devices,
> > less than half of the targets are big-endian. If it's broken on
> > big-endian there should be a comment somewhere documenting this, so we
> > know to fix it.
>
> Well, it's stated in the cover letter and the same is true for almost every
> PCI device in qemu we have today. So what would you p
On 25.11.2010, at 11:59, Paul Brook wrote:
>> This patch introduces configuration variables
>> CONFIG_SCSI_LSI
>> CONFIG_SCSI_MEGASAS
>> and renames the existing CONFIG_ESP to CONFIG_SCSI_ESP.
>> With this the available SCSI HBAs can be configured for each
>> target configuration instead of compi
> On 25.11.2010, at 11:59, Paul Brook wrote:
> >> This patch introduces configuration variables
> >> CONFIG_SCSI_LSI
> >> CONFIG_SCSI_MEGASAS
> >> and renames the existing CONFIG_ESP to CONFIG_SCSI_ESP.
> >> With this the available SCSI HBAs can be configured for each
> >> target configuration inst
On 25.11.2010, at 14:22, Paul Brook wrote:
>> On 25.11.2010, at 11:59, Paul Brook wrote:
This patch introduces configuration variables
CONFIG_SCSI_LSI
CONFIG_SCSI_MEGASAS
and renames the existing CONFIG_ESP to CONFIG_SCSI_ESP.
With this the available SCSI HBAs can be conf
On Thu, 25 Nov 2010 09:06:05 +0800
Wen Congyang wrote:
> The args_type of migrate_set_speed in qmp-commands.hx is wrong.
> When we set migrate speed by json, qemu will be core dumped.
>
> This bug was caused by 07de3e60b05 and hence affects master only.
>
> Signed-off-by: Wen Congyang
Applied
This patchset adds support for the ATA TRIM and SCSI WRITE SAME with
unmap commands, which allow reclaiming free space from a backing image.
The user facing implementation is pretty complete, but not really
efficient because the underlying bdrv_discard implementation doesn't
use the aio implementa
Add a new bdrv_discard method to free blocks in a mapping image, and a new
drive property to set the granularity for these discard. If no discard
granularity support is set discard support is disabled.
Signed-off-by: Christoph Hellwig
Index: qemu/block.c
Add support for the data set management command, and the TRIM sub function
in it.
Signed-off-by: Christoph Hellwig
Index: qemu/hw/ide/core.c
===
--- qemu.orig/hw/ide/core.c 2010-11-25 12:33:40.961255346 +0100
+++ qemu/hw/ide/cor
Support discards via the WRITE SAME command with the unmap bit set, and
tell the initiator about the support for it via the block limit and the
new thin provisioning EVPD pages. Also fix the comment which incorrectly
describedthe block limits EVPD page.
Signed-off-by: Christoph Hellwig
Index: q
Make dma_bdrv_io available for drivers, and pass an explicit I/O function
instead of hardcoding bdrv_aio_readv/bdrv_aio_writev. This is required
to implement non-READ/WRITE dma commands in the ide driver, e.g. the
upcoming TRIM support.
Signed-off-by: Christoph Hellwig
Index: qemu/dma-helpers.c
Add support to discard blocks in a raw image residing on an XFS filesystem
by calling the XFS_IOC_UNRESVSP64 ioctl to punch holes. Support for other
hole punching mechanisms can be added when they become available.
Signed-off-by: Christoph Hellwig
Index: qemu/block/raw-posix.c
=
On Thu, 25 Nov 2010 12:42:52 +0100
Gerd Hoffmann wrote:
>Hi,
>
> > The first thing we have to check with Daniel is whether or not we're
> > providing the info they would need/expect,
>
> Daniel?
>
> > apart from that I have the
> > following general comments:
> >
> > 1. It's missing docu
On Thu, 25 Nov 2010, Christoph Hellwig wrote:
> Add a new bdrv_discard method to free blocks in a mapping image, and a new
> drive property to set the granularity for these discard. If no discard
> granularity support is set discard support is disabled.
>
> Signed-off-by: Christoph Hellwig
>
>
On Thu, 25 Nov 2010, Christoph Hellwig wrote:
> Add support for the data set management command, and the TRIM sub function
> in it.
Tabs.
[..snip..]
--
mailto:av1...@comtv.ru
On Thu, 25 Nov 2010, Christoph Hellwig wrote:
> Support discards via the WRITE SAME command with the unmap bit set, and
> tell the initiator about the support for it via the block limit and the
> new thin provisioning EVPD pages. Also fix the comment which incorrectly
> describedthe block limits
On Wed, Nov 24, 2010 at 11:16 AM, Hannes Reinecke wrote:
> +static int megasas_pd_get_info_submit(SCSIDevice * sdev, int lun,
> + struct megasas_cmd_t *cmd)
> +{
> + struct mfi_pd_info * info = cmd->iov_buf;
> + uint8_t cmdbuf[6];
> + SCSIRequest *req;
Am 24.11.2010 12:16, schrieb Hannes Reinecke:
> The SCSI spec has a quite detailed list of sense codes available.
> It even mandates the use of specific ones for some failure cases.
> The current implementation just has one type of 'generic' error
> which is actually a violation of the spec in cert
On Thu, Nov 25, 2010 at 1:57 PM, Christoph Hellwig wrote:
> +int bdrv_discard(BlockDriverState *bs, int64_t sector_num, int nb_sectors)
> +{
> + if (!bs->drv || !bs->drv->bdrv_discard)
> + return 0;
!bs->drv is normally -ENOMEDIUM. Perhaps we shouldn't lump it in with
!bs->drv->bdrv_di
On 11/25/2010 03:36 PM, Stefan Hajnoczi wrote:
> On Wed, Nov 24, 2010 at 11:16 AM, Hannes Reinecke wrote:
>> +static int megasas_pd_get_info_submit(SCSIDevice * sdev, int lun,
>> + struct megasas_cmd_t *cmd)
>> +{
>> +struct mfi_pd_info * info = cmd->iov_bu
On Thu, Nov 25, 2010 at 2:50 PM, Hannes Reinecke wrote:
> On 11/25/2010 03:36 PM, Stefan Hajnoczi wrote:
>> On Wed, Nov 24, 2010 at 11:16 AM, Hannes Reinecke wrote:
>>> +static int megasas_pd_get_info_submit(SCSIDevice * sdev, int lun,
>>> + struct megasas_cmd
Alexander,
the people we are addressing and we would like to bring together is from
the QEMU emulation community.
We are interested in running different ISAs mainly under Linux and
Windows versions. There is a huge additional
interest from industry for this part to QEMU for embedded systems/SW
On Thu, Nov 25, 2010 at 09:53:25AM +0100, Hannes Reinecke wrote:
> Looked into it.
> Sure I could be doing it for scsi-disk; for scsi-generic it won't
> work, though. And it's not much of a code-share to have from it;
> you'll end up with something like:
Yes, and that is a good start to completely
This patch enables USB UHCI global suspend/resume feature. The OS will
stop the HC once all ports are suspended. If there is activity on the
port(s), an interrupt signalling remote wakeup will be triggered.
To enable autosuspend for the USB tablet on Linux guests:
echo auto > /sys/devices/pci000
Hi,
+dev->info->remote_wakeup_cb = uhci_event;
diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..16de1c9 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -189,6 +189,11 @@ struct USBDeviceInfo {
*/
int (*handle_data)(USBDevice *dev, USBPacket *p);
+/*
+ * Process remote w
On 11/25/2010 04:29 PM, Christoph Hellwig wrote:
> On Thu, Nov 25, 2010 at 09:53:25AM +0100, Hannes Reinecke wrote:
>> Looked into it.
>> Sure I could be doing it for scsi-disk; for scsi-generic it won't
>> work, though. And it's not much of a code-share to have from it;
>> you'll end up with somet
Ok. Here is a full patch to QEMU 0.13.
Works with and without -singlestep.
Works with all fpu instructions.
Should also work with fsave.
** Patch added: "Bug fix. For version 0.13. This patch fixes the bug (for me)
completely."
https://bugs.launchpad.net/qemu/+bug/661696/+attachment/1744859
For the client side utility vscclient, see libcac_card:
libcac_card http://cgit.freedesktop.org/~alon/cac_card (temporary home)
written by Robert Relyea
Signed-off-by: Alon Levy
---
Makefile.objs |2 +-
hw/ccid-card-passthru.c | 277 ++
This patchset adds three new devices, usb-ccid, ccid-card-passthru and
ccid-card-emulated, providing a CCID bus, a simple passthru protocol
implementing card requiring a client, and a standalone emulated card.
It also introduces a new directory libcaccard with CAC card emulation,
CAC is a type of
Signed-off-by: Alon Levy
---
Makefile|6 --
Makefile.objs |5 +
Makefile.target |2 ++
configure | 24
libcaccard/Makefile | 18 ++
5 files changed, 53 insertions(+), 2 deletions(-)
create mode 10064
changes from v1:
remove stale comments, use only c-style comments
bugfix, forgot to set recv_len
change reader name to 'Virtual Reader'
Signed-off-by: Alon Levy
---
Makefile.objs |2 +-
hw/ccid-card-emulated.c | 492 +++
2 fi
A CCID device is a smart card reader. It is a USB device, defined at [1].
This patch introduces the usb-ccid device that is a ccid bus. Next patches will
introduce two card types to use it, a passthru card and an emulated card.
[1] http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_R
See patch 2 for details.
v2:
- Add remote wakeup callback in USBBus, as suggested by Gerd.
This patch enables USB UHCI global suspend/resume feature. The OS will
stop the HC once all ports are suspended. If there is activity on the
port(s), an interrupt signalling remote wakeup will be triggered.
To enable autosuspend for the USB tablet on Linux guests:
echo auto > /sys/devices/pci
Needed for remote wakeup notification.
Signed-off-by: Marcelo Tosatti
Index: qemu-kvm/hw/usb-bus.c
===
--- qemu-kvm.orig/hw/usb-bus.c
+++ qemu-kvm/hw/usb-bus.c
@@ -14,11 +14,12 @@ static struct BusInfo usb_bus_info = {
static int n
Signed-off-by: Alon Levy
---
docs/ccid.txt | 125 +
docs/libcaccard.txt | 482 +++
2 files changed, 607 insertions(+), 0 deletions(-)
create mode 100644 docs/ccid.txt
create mode 100644 docs/libcaccard.txt
diff --git a/docs/cc
Hello,
This is a rebase of the patchset I'd sent earlier.
The usual notes apply: this is just the start, just getting the
framework in place and a few examples so that people can then pick up
and start documenting their devices and options. We want to see all
of the devices covered, and hopefull
Document the parameters for the virtserialport and virtioconsole
devices.
Example:
$ ./x86_64-softmmu/qemu-system-x86_64 -device virtserialport,?
virtserialport.nr=uint32, The 'number' for the port for \
predictable port numbers. Use this to spawn ports if you \
plan to migrate the guest.
virtse
This results in an output like:
$ ./x86_64-softmmu/qemu-system-x86_64 -device virtio-net-pci,?
...
virtio-net-pci.mac=macaddr, The MAC address for the NIC.
virtio-net-pci.vlan=vlan, The VLAN to associate the NIC with.
virtio-net-pci.netdev=netdev, The peer net device to associate with this
virt
Document the options common to all block devices.
This comes from Kevin.
Signed-off-by: Amit Shah
CC: Kevin Wolf
---
block_int.h | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/block_int.h b/block_int.h
index 88a2546..867c4e2 100644
--- a/block_int.h
+++ b
> I rebased this and rechecked it. The *total* libguestfs boot time
> goes from 86 seconds down to 7.7 seconds. The proportion of that
> attributable to loading the appliance is approximately 650 times [sic]
> faster.
Nack.
> +/* Target address and size for DMA operations. This is only used
>
Christoph Hellwig writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and
qemu-xen: support empty write barriers in xen_disk"):
> On Wed, Nov 24, 2010 at 10:18:40AM -0800, Jeremy Fitzhardinge wrote:
> > Linux wants is a useful thing to do and implement (especially since it
> > amounts to standa
On 11/25/2010 11:30 AM, Ian Jackson wrote:
> Christoph Hellwig writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and
> qemu-xen: support empty write barriers in xen_disk"):
>> On Wed, Nov 24, 2010 at 10:18:40AM -0800, Jeremy Fitzhardinge wrote:
>>> Linux wants is a useful thing to do and impl
Am 24.11.2010 22:44, schrieb Benjamin Drung:
Attached a new version of my patch. You find two branches linked to this
bug for maverick and natty. The patch sets SDL_DISABLE_LOCK_KEYS and get
rid of the complete workaround in qemu-kvm. This requires SDL >= 1.2.14.
For newer versions of SDL (thos
On 24 November 2010 11:00, Alexander Graf wrote:
>
> On 24.11.2010, at 03:40, adq wrote:
>
>> On 23 November 2010 23:41, Alexander Graf wrote:
>>>
>>> On 23.11.2010, at 22:25, adq wrote:
>>>
This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
loads successfully (with
On 25 November 2010 11:28, Isaku Yamahata wrote:
> On Wed, Nov 24, 2010 at 02:08:16PM +, adq wrote:
>> > Interesting. I was also thinking that maybe we can leverage overriding
>> > mechanisms that are already available. Maybe it's possible to squeeze the
>> > HPET node into an SSDT. Maybe we
Hannes Reinecke wrote:
+static int megasas_scsi_init(PCIDevice *dev)
+{
+MPTState *s = DO_UPCAST(MPTState, dev, dev);
+uint8_t *pci_conf;
+int i;
+
+pci_conf = s->dev.config;
+
+/* PCI Vendor ID (word) */
+pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_LSI_LOGIC);
+/
On 25 November 2010 11:46, Jan Kiszka wrote:
> Am 24.11.2010 12:00, Alexander Graf wrote:
> According to to the Intel IA-32 Software Developers Manual Vol 3 page
> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>
> Signed-off-by: Andrew de Quincey
>
> diff --g
Hello,
Am 25.11.2010 um 12:03 schrieb Alexander Graf:
On 25.11.2010, at 11:30, wolfgang mueller wrote:
For the future, we are currently not planning a second Users' Forum
and we are open to forward the organization of a second workshop
to anybody else.
Why don't you simply take this event
On 25.11.2010, at 23:53, Andreas Färber wrote:
> Hello,
>
> Am 25.11.2010 um 12:03 schrieb Alexander Graf:
>
>> On 25.11.2010, at 11:30, wolfgang mueller wrote:
>>
>>> For the future, we are currently not planning a second Users' Forum and we
>>> are open to forward the organization of a seco
On Thu, Nov 25, 2010 at 11:46:40AM -0800, Jeremy Fitzhardinge wrote:
> The latter. There's a question over whether WRITE_BARRIER really
> supports empty barriers, since it appears that none of the existing
> backends implement it correctly - but on the other hand, the kernel
> blkback code does *t
On 25.11.2010, at 21:24, adq wrote:
> On 24 November 2010 11:00, Alexander Graf wrote:
>>
>> On 24.11.2010, at 03:40, adq wrote:
>>
>>> On 23 November 2010 23:41, Alexander Graf wrote:
On 23.11.2010, at 22:25, adq wrote:
> This patch ups the APIC version from 0x11 to 0x14
On 25.11.2010, at 22:03, adq wrote:
> On 25 November 2010 11:46, Jan Kiszka wrote:
>> Am 24.11.2010 12:00, Alexander Graf wrote:
>> According to to the Intel IA-32 Software Developers Manual Vol 3 page
>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>>
>> Signed-o
Public bug reported:
qemu-img -O vmdk raw-file.dd vmdk-file.vmdk
will failed with error.
This issue will be occured on all big endian environment.
** Affects: qemu
Importance: Undecided
Status: New
--
Failed to convert vmdk on MacOSX ppc
https://bugs.launchpad.net/bugs/681613
You
** Patch added: "0001-Enable-to-create-vmdk-headers-on-big-endian-machine.patch"
https://bugs.launchpad.net/bugs/681613/+attachment/1745371/+files/0001-Enable-to-create-vmdk-headers-on-big-endian-machine.patch
--
Failed to convert vmdk on MacOSX ppc
https://bugs.launchpad.net/bugs/681613
You
Wolfgang,
On 25.11.2010, at 15:54, wolfgang mueller wrote:
> Alexander,
> the people we are addressing and we would like to bring together is from the
> QEMU emulation community.
> We are interested in running different ISAs mainly under Linux and Windows
> versions. There is a huge additional
On 25.11.2010, at 23:53, Andreas Färber wrote:
> Hello,
>
> Am 25.11.2010 um 12:03 schrieb Alexander Graf:
>
>> On 25.11.2010, at 11:30, wolfgang mueller wrote:
>>
>>> For the future, we are currently not planning a second Users' Forum and we
>>> are open to forward the organization of a seco
This bug was fixed in the package qemu-kvm - 0.13.0+noroms-0ubuntu8
---
qemu-kvm (0.13.0+noroms-0ubuntu8) natty; urgency=low
* Add caps-lock-key-up-event.patch to enable normal up/down events for
Caps-Lock and Num-Lock keys by setting SDL_DISABLE_LOCK_KEYS (which
requires SD
Attached the uploaded debdiff for maverick.
** Patch added: "qemu-kvm_0.12.5+noroms-0ubuntu7.1.debdiff"
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/427612/+attachment/1745373/+files/qemu-kvm_0.12.5%2Bnoroms-0ubuntu7.1.debdiff
** Changed in: qemu-kvm (Ubuntu Maverick)
Status
>>> For the emulation side, things look different. I'm not aware of any
>>> traction on the emulation side of Qemu. Getting people together for that
>>> one is certainly lacking. I'm not sure I'm the right person to talk to
>>> there. If nobody else steps up, I could barely play the role of some
> I must say I'd like to get rid of the chunking transfer in scsi-disk.
> To have it for scsi-disk only is really pointless, as you can
> potentially send exactly the same commands via scsi-generic.
> So for scsi-generic to work properly qemu need to be able to
> allocate the _entire_ data buffer.
>> the people we are addressing and we would like to bring together is from the
>> QEMU emulation community.
>> We are interested in running different ISAs mainly under Linux and Windows
>> versions. There is a huge additional
>
> You're about the first person in 1/2 year that actually said you
> This patch enables USB UHCI global suspend/resume feature. The OS will
> stop the HC once all ports are suspended. If there is activity on the
> port(s), an interrupt signalling remote wakeup will be triggered.
I'm pretty sure this is wrong. Suspend/resume works based on physical
topology, i.e
On Fri, Nov 26, 2010 at 12:38:28AM +, Paul Brook wrote:
> > This patch enables USB UHCI global suspend/resume feature. The OS will
> > stop the HC once all ports are suspended. If there is activity on the
> > port(s), an interrupt signalling remote wakeup will be triggered.
>
> I'm pretty sure
Oops, there seems to be something wrong with my patch. I'll do
additional fix.
--
Failed to convert vmdk on MacOSX ppc
https://bugs.launchpad.net/bugs/681613
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug descr
1 - 100 of 101 matches
Mail list logo
