Re: [Qemu-devel] Re: [PATCH 10/16] scsi: Use 'SCSIRequest' directly
On 11/18/10 17:33, Hannes Reinecke wrote: Not sure if it makes sense to split it up into several patches; we need the ->get_req()/->put_req() callbacks to get the request in the first place. Point. And only then can we modify the other callbacks. However, splitting them off into two patchsets would render the first pretty much pointless. But sure, I can do a better description. Yes, please. thanks, Gerd
[Qemu-devel] Re: [PATCH 7/7] pci bridge: implement secondary bus reset
On Thu, Nov 18, 2010 at 10:46:25AM +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 18, 2010 at 04:29:10PM +0900, Isaku Yamahata wrote:
> > On Thu, Nov 18, 2010 at 09:05:30AM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Nov 17, 2010 at 01:50:27PM +0900, Isaku Yamahata wrote:
> > > > Emulates secondary bus reset when secondary bus reset bit
> > > > is written from 0 to 1.
> > > >
> > > > Signed-off-by: Isaku Yamahata
> > > > Signed-off-by: Anthony Liguori
> > > > ---
> > > > hw/pci_bridge.c | 12 +++-
> > > > 1 files changed, 11 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
> > > > index 58cc2e4..618a81e 100644
> > > > --- a/hw/pci_bridge.c
> > > > +++ b/hw/pci_bridge.c
> > > > @@ -139,6 +139,10 @@ pcibus_t pci_bridge_get_limit(const PCIDevice
> > > > *bridge, uint8_t type)
> > > > void pci_bridge_write_config(PCIDevice *d,
> > > > uint32_t address, uint32_t val, int len)
> > > > {
> > > > +PCIBridge *s = container_of(d, PCIBridge, dev);
> > > > +uint16_t bridge_control = pci_get_word(d->config +
> > > > PCI_BRIDGE_CONTROL);
> > > > +uint16_t bridge_control_new;
> > > > +
> > > > pci_default_write_config(d, address, val, len);
> > > >
> > > > if (/* io base/limit */
> > > > @@ -147,9 +151,15 @@ void pci_bridge_write_config(PCIDevice *d,
> > > > /* memory base/limit, prefetchable base/limit and
> > > > io base/limit upper 16 */
> > > > ranges_overlap(address, len, PCI_MEMORY_BASE, 20)) {
> > > > -PCIBridge *s = container_of(d, PCIBridge, dev);
> > > > pci_bridge_update_mappings(&s->sec_bus);
> > > > }
> > > > +
> > > > +bridge_control_new = pci_get_word(d->config + PCI_BRIDGE_CONTROL);
> > > > +if (!(bridge_control & PCI_BRIDGE_CTL_BUS_RESET) &&
> > > > +(bridge_control_new & PCI_BRIDGE_CTL_BUS_RESET)) {
> > > > +/* 0 -> 1 */
> > > > +pci_bus_reset(&s->sec_bus);
> > > > +}
> > > > }
> > > >
> > > > void pci_bridge_disable_base_limit(PCIDevice *dev)
> > >
> > > Presumably this bit will have to be made writeable?
> >
> > Yes, it's already writable.
> > static void pci_init_wmask_bridge(PCIDevice *d)
> > ...
> >pci_set_word(d->wmask + PCI_BRIDGE_CONTROL, 0x);
>
> Ouch, that's wrong, isn't it?
> Bits 15:12 are reserved, readonly, 0.
>
> I think we need the following (untested).
> Comments?
Basically it looks good if you left bits 8-11 RO intentional.
qemu doesn't emulate pci bus cycles, so it won't matter.
Also, please include following hunk.
commit 8c76e0427234290a640499c1305cabd998d6f777
Author: Isaku Yamahata
Date: Fri Nov 19 17:08:57 2010 +0900
pcie/port: initialize bridge control register properly
pci generic layer initialized bridge control register
according to pci spec. pcie deviates slightly from it,
so initializes it properly.
Signed-off-by: Isaku Yamahata
diff --git a/hw/pcie_port.c b/hw/pcie_port.c
index 117de61..340dcdb 100644
--- a/hw/pcie_port.c
+++ b/hw/pcie_port.c
@@ -27,6 +27,14 @@ void pcie_port_init_reg(PCIDevice *d)
pci_set_word(d->config + PCI_STATUS, 0);
pci_set_word(d->config + PCI_SEC_STATUS, 0);
+/* Unlike conventional pci bridge, some bits are hardwared to 0. */
+pci_set_word(d->wmask + PCI_BRIDGE_CONTROL,
+ PCI_BRIDGE_CTL_PARITY |
+ PCI_BRIDGE_CTL_ISA |
+ PCI_BRIDGE_CTL_VGA |
+ PCI_BRIDGE_CTL_SERR |
+ PCI_BRIDGE_CTL_BUS_RESET);
+
/* 7.5.3.5 Prefetchable Memory Base Limit
* The Prefetchable Memory Base and Prefetchable Memory Limit registers
* must indicate that 64-bit addresses are supported, as defined in
>
> pci: fix bridge control bit wmask
>
> Bits 12 to 15 in bridge control register are reserver and must be
> read-only zero, curent mask is 0x which makes them writeable. Fix
> this up by using symbolic bit names for writeable bits instead of a
> hardcoded constant.
>
> Signed-off-by: Michael S. Tsirkin
>
> --
>
> diff --git a/hw/pci.c b/hw/pci.c
> index 00ec8ea..7d6d5ad 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -588,7 +588,17 @@ static void pci_init_wmask_bridge(PCIDevice *d)
> /* PCI_PREF_BASE_UPPER32 and PCI_PREF_LIMIT_UPPER32 */
> memset(d->wmask + PCI_PREF_BASE_UPPER32, 0xff, 8);
>
> -pci_set_word(d->wmask + PCI_BRIDGE_CONTROL, 0x);
> +/* TODO: add this define to pci_regs.h in linux and then in qemu. */
> +#define PCI_BRIDGE_CTL_VGA_16BIT 0x10 /* VGA 16-bit decode */
> +pci_set_word(d->wmask + PCI_BRIDGE_CONTROL,
> + PCI_BRIDGE_CTL_PARITY |
> + PCI_BRIDGE_CTL_SERR |
> + PCI_BRIDGE_CTL_ISA |
> + PCI_BRIDGE_CTL_VGA |
> + PCI_BRIDGE_CTL_VGA_16BIT |
> + PCI_BRIDGE_CTL_MASTER_ABORT |
> + PCI_BRIDGE_CTL_BUS_RESET |
> + PCI_BRIDGE_CTL_FAST
[Qemu-devel] macaddr doesn't work
Dear all I use the QEMU with Debian. When I want to assign mac address to the QEMU. sudo qemu-system-arm -M versatilepb -monitor stdio -kernel vmlinuz-2.6.26-2-versatile -initrd initrd.img-2.6.26-2-versatile -hda test.img -append "root=/dev/sda1" -net nic,macaddr=52:54:00:12:34:57 -net tap However the eth0 will disapear and induce I cannot assign the IP address to the QEMU. http://myweb.ncku.edu.tw/~p76991028/eth0.png I have found this page. http://www.mail-archive.com/qemu-devel@nongnu.org/msg13741.html But this don't help me. Why I can't assign mac address to the QEMU Thanks. Best Regards
Re: [Qemu-devel] [PATCH 00/10] AHCI emulation support v2
On Thu, Nov 18, 2010 at 11:24 PM, Alexander Graf wrote: > linux-uztg:~ # dd if=/dev/sdc of=/dev/null bs=10M count=300 iflag=direct That's a big block size. bs=8k is interesting too because we see the per-request overhead. Since IDE, SATA, and virtio have different hardware interfaces that the guest drives we may see an interesting picture with small block sizes. Stefan
[Qemu-devel] Re: [PATCH 08/10] ahci: add ahci emulation
+static void ahci_check_irq(AHCIState *s) MSI support would be nice to have. Alrighty, I added MSI support. But I only have a single vector in use atm as nvec> 0 doesn't get written to the PCI config space so the code trips on that later on. For multiple vectors MSI-X is the best choice as it fixes a few design issues MSI has when it comes to multiple vectors. I think linux never ever uses MSI with multiple vectors anyway. cheers, Gerd
Re: [Qemu-devel] [PATCH 00/10] AHCI emulation support v2
Am 18.11.2010 19:43, schrieb Alexander Graf: > > On 18.11.2010, at 14:26, Kevin Wolf wrote: > >> Hi Alex, >> >> Am 18.11.2010 04:27, schrieb Alexander Graf: >>> This patch adds support for AHCI emulation. I have tested and verified it >>> works >>> in Linux, OpenBSD, Windows Vista and Windows 7. This AHCI emulation supports >>> NCQ, so multiple read or write requests can be outstanding at the same time. >>> >>> The code is however not fully optimized yet. I'm fairly sure that there are >>> low hanging performance fruits to be found still :). In my simple benchmarks >>> I achieved about 2/3rd of virtio performance. >>> >>> Also, this AHCI emulation layer does not support legacy mode. So if you're >>> using a disk with this emulation, you do not get it exposed using the legacy >>> IDE interfaces. >>> >>> Another nitpick is CD-ROM support in Windows. Somehow it doesn't detect a >>> CD-ROM drive attached to AHCI. At least it doesn't list it. >>> >>> To attach an AHCI disk to your VM, please use >>> >>> -drive file=...,if=sata >>> >>> This should do the trick for x86. On other platforms, you might need to add >>> the ahci host controller using -device. >>> >>> >>> This patch set is based on work done during the Google Summer of Code. I was >>> mentoring a student, Roland Elek, who wrote most of the AHCI emulation code >>> based on a patch from Chong Qiao. A bunch of other people were also >>> involved, >>> so everybody who I didn't mention - thanks a lot! >> >> I'm not completely sure about the relationship between the AHCI >> emulation and our existing IDE emulation. First thing I noticed is that >> AHCI wants to be independent and resides in hw/ instead of hw/ide/, but >> it still include ide/internal.h. Do you think it would make sense to >> move AHCI into hw/ide? > > Both ahci and ide implement ata. I guess the best thing to do would be to > completely refactor all ide code into ata and pata code, then add ahci (sata) > to the game. Estimated working time: ~1 month. :) > > As I would rather have something working we can base on in the tree, so > whoever volunteers for the refactoring (hint!) knows how to design the > interfaces, I am not sure how much is reasonable within this patch set. I guess I have to read this as: You want to drop the code into the repository, no matter what mess it creates, and leave the cleanup to some volunteer that will never appear. So whoever is in the unfortunate position of having to touch the IDE code afterwards will have the pain because this series is doing only the half of what should be done. I'm sure that with a working time of only a few days the result could be substantially improved, even if a month would be needed for perfection. > Moving the file to ide/ does sound like a good idea however. > >> >> Then I believe that core.c is now a mixture of some generic ATA code >> (that is also used by SATA) and the Legacy IDE code. SATA doesn't seem >> to interact with the generic code through clean interfaces, but by >> accessing internal data structures and calls to somewhere in the middle >> of the existing IDE emultion. I think we should get a clean abstraction >> there and have a clean split between SATA, PATA and common code, with >> each of them sitting in its own file in hw/ide. >> >> I haven't reviewed the patches in detail but just had a quick look at >> them, so my impressions might be wrong. If so, please correct me. > > No, you're completely right. We're in a chicken and egg situation. We don't > have ahci, but the ide code is ugly. We would probably do a bad job at > refactoring the ata code if we don't know which interfaces to design for. That problem is solved. You have posted patches, so you're aware what interfaces you need for AHCI. This awareness doesn't come from putting the code into git master. > So IMHO the only way we can really go is to implement sata, take the uglyness > it adds to the already ugly ide code and use all of that for a working state > we can start to refactor from. > > So yes, while I agree with your obversations, I do not believe we will get > there until at least 0.16 or so. And I'd rather like to see a fast default > block driver in gueast sooner than later :) Note that not doing the refactoring in this patch series means not only that it won't happen, but also that your patches are very hard to review. The order in which I would expect changes is to do the refactoring and then base the SATA code on these clean interfaces - not first creating a mess and then (maybe some time) trying to clean it up. You always say "we" will refactor and "we" will clean up, so who is this "we"? Will you do it or are you rather trying to put it on my todo list? I must admit that I wouldn't be happy about the latter. Kevin
Re: [Qemu-devel] [PATCH 16/16] megasas: LSI Megaraid SAS emulation
On 11/18/10 15:47, Hannes Reinecke wrote: > This patch adds an emulation for the LSI Megaraid SAS HBA. > > Signed-off-by: Hannes Reinecke > --- > Makefile.objs |2 +- > hw/megasas.c | 1826 > + > hw/mfi.h | 1197 + > hw/pci_ids.h |2 + > hw/scsi.h |1 + > 5 files changed, 3027 insertions(+), 1 deletions(-) > create mode 100644 hw/megasas.c > create mode 100644 hw/mfi.h > > diff --git a/Makefile.objs b/Makefile.objs > index 15569af..54c6e02 100644 > --- a/Makefile.objs > +++ b/Makefile.objs > @@ -231,7 +231,7 @@ hw-obj-$(CONFIG_IDE_MACIO) += ide/macio.o > hw-obj-$(CONFIG_IDE_VIA) += ide/via.o > > # SCSI layer > -hw-obj-y += lsi53c895a.o > +hw-obj-y += lsi53c895a.o megasas.o > hw-obj-$(CONFIG_ESP) += esp.o > > hw-obj-y += dma-helpers.o sysbus.o isa-bus.o Just had a look through your patches and have to say nice work. Haven't tested it though, but looks like a good step in the right direction. Only comment, as you are adding another SCSI driver, maybe it's time to make the driver selection configurable, rather than hard coding the build? Cheers, Jes
Re: [Qemu-devel] [RFC][PATCH v3 03/21] virtproxy: add debug functions for virtproxy core
On Thu, Nov 18, 2010 at 5:17 PM, Michael Roth wrote:
> On 11/18/2010 05:43 AM, Stefan Hajnoczi wrote:
>>
>> On Thu, Nov 18, 2010 at 11:09 AM, Jes Sorensen
>> wrote:
>>>
>>> On 11/16/10 02:15, Michael Roth wrote:
Signed-off-by: Michael Roth
---
virtproxy.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/virtproxy.c b/virtproxy.c
index 8f18d83..3686c77 100644
--- a/virtproxy.c
+++ b/virtproxy.c
@@ -13,6 +13,23 @@
#include "virtproxy.h"
+#define DEBUG_VP
+
+#ifdef DEBUG_VP
+#define TRACE(msg, ...) do { \
+ fprintf(stderr, "%s:%s():L%d: " msg "\n", \
+ __FILE__, __FUNCTION__, __LINE__, ## __VA_ARGS__); \
+} while(0)
+#else
+#define TRACE(msg, ...) \
+ do { } while (0)
+#endif
+
+#define LOG(msg, ...) do { \
+ fprintf(stderr, "%s:%s(): " msg "\n", \
+ __FILE__, __FUNCTION__, ## __VA_ARGS__); \
+} while(0)
+
>>>
>>> I wonder if it wouldn't make sense to do this in a more generic way and
>>> stick it in a header file. This type of debug code seems to show up
>>> repeatedly all over the place.
>>
>> I wanted to suggest actually using QEMU tracing but given that this
>> code compiles stand-alone, it may be more trouble to integrate than
>> it's worth.
>>
>> For qemu and qemu-tools code we should be using tracing because you
>> can build it into production without high overhead. How often do
>> these #defines get used, not often is my guess because no one wants to
>> tweak the source and rebuild, especially not in production.
>>
>
> I'd planned on replacing the TRACE()'s with trace calls eventually. Maybe I
> missed it in the documentation, but do we have a way to enable them for
> qemu-tools or does we need to provide our own hooks and do it
> programmatically?
qemu-tools builds with QEMU tracing. I wasn't sure whether you're
building in the qemu-tools style or whether qemu-vp is a completely
separate program.
So if qemu-vp is built with all the common qemu-tools make
infrastructure, then you should have tracing in there.
Stefan
[Qemu-devel] [Bug 427612] Re: kvm sends caps lock key up event twice
You mean "press caps lock" with "capslock turning on" and "release caps lock" with "capslock turning off"? ** Description changed: Binary package hint: qemu-kvm I have set the keyboard layout to German NEO 2 [1] in the host and the client (both current karmic). The caps lock is used as modifier (similar to shift) in NEO. When I press "caps lock" + "t", then the client prints - a "t" instead of a "-". It seems that the pressed caps lock is not - passed to the client. + a "t" instead of a "-". A caps lock key up event is sent to the client + before I release the caps lock key. [1] http://www.neo-layout.org/ ProblemType: Bug Architecture: amd64 Date: Fri Sep 11 01:38:58 2009 DistroRelease: Ubuntu 9.10 KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD Package: qemu-kvm 0.11.0~rc2-0ubuntu2 PccardctlIdent: - + PccardctlStatus: - + ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic root=UUID=37b01f5a-a578-49d6-a812-f166b103e68a ro quiet splash ProcEnviron: - LANG=de_DE.UTF-8 - SHELL=/bin/bash + LANG=de_DE.UTF-8 + SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-10.31-generic SourcePackage: qemu-kvm Uname: Linux 2.6.31-10-generic x86_64 dmi.bios.date: 07/15/2009 dmi.bios.vendor: Intel Corp. dmi.bios.version: DPP3510J.86A.0572.2009.0715.2346 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: DG33TL dmi.board.vendor: Intel Corporation dmi.board.version: AAD89517-802 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrDPP3510J.86A.0572.2009.0715.2346:bd07/15/2009:svn:pn:pvr:rvnIntelCorporation:rnDG33TL:rvrAAD89517-802:cvn:ct3:cvr: -- kvm sends caps lock key up event twice https://bugs.launchpad.net/bugs/427612 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Invalid Status in “libsdl1.2” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: New Status in “libsdl1.2” package in Debian: Fix Released Bug description: Binary package hint: qemu-kvm I have set the keyboard layout to German NEO 2 [1] in the host and the client (both current karmic). The caps lock is used as modifier (similar to shift) in NEO. When I press "caps lock" + "t", then the client prints a "t" instead of a "-". A caps lock key up event is sent to the client before I release the caps lock key. [1] http://www.neo-layout.org/ ProblemType: Bug Architecture: amd64 Date: Fri Sep 11 01:38:58 2009 DistroRelease: Ubuntu 9.10 KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD Package: qemu-kvm 0.11.0~rc2-0ubuntu2 PccardctlIdent: PccardctlStatus: ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic root=UUID=37b01f5a-a578-49d6-a812-f166b103e68a ro quiet splash ProcEnviron: LANG=de_DE.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-10.31-generic SourcePackage: qemu-kvm Uname: Linux 2.6.31-10-generic x86_64 dmi.bios.date: 07/15/2009 dmi.bios.vendor: Intel Corp. dmi.bios.version: DPP3510J.86A.0572.2009.0715.2346 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: DG33TL dmi.board.vendor: Intel Corporation dmi.board.version: AAD89517-802 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrDPP3510J.86A.0572.2009.0715.2346:bd07/15/2009:svn:pn:pvr:rvnIntelCorporation:rnDG33TL:rvrAAD89517-802:cvn:ct3:cvr:
[Qemu-devel] Re: [PATCH 0/2] Re: [PATCH v9 5/8] pcie/aer: helper functions for pcie aer capability
On Wed, Nov 17, 2010 at 04:06:38PM +0200, Michael S. Tsirkin wrote: > Please, try to address the TODO: I think the case of > PCIE device behind a pci bridge is not covered properly. Right, pci-to-pcie bridge case isn't covered. Although SERR bit can be set, the error can't be propagated up further because qemu doesn't emulate PERR#/SERR#. There is no use case of pci-to-pcie bridge in qemu, I think. If good error handling is wanted, express should be used. So it isn't worthwhile to implement pci-to-pcie bridge. -- yamahata
[Qemu-devel] [Bug 676029] [NEW] Silently fail with wrong vde socket dir
Public bug reported:
Hi,
Using qemu 0.12.5, kvm silently fail with exit code 1 when using -net
vde and a wrong path for sock. Actually, the sock option is mean to be
the socket dir of the vde_switch, not the socket itself.
With -net vde,sock=/var/run/vde/vde0/ctl , strace ends with the
following messages :
connect(7, {sa_family=AF_FILE, path="/var/run/vde/vde0/ctl/ctl"}, 110) = -1
ENOTDIR (Not a directory)
close(7)= 0
close(8)= 0
exit_group(1) = ?
root ~#
Please add a meaningful message.
Regards,
Étienne
** Affects: qemu
Importance: Undecided
Status: New
--
Silently fail with wrong vde socket dir
https://bugs.launchpad.net/bugs/676029
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
Hi,
Using qemu 0.12.5, kvm silently fail with exit code 1 when using -net vde and a
wrong path for sock. Actually, the sock option is mean to be the socket dir of
the vde_switch, not the socket itself.
With -net vde,sock=/var/run/vde/vde0/ctl , strace ends with the following
messages :
connect(7, {sa_family=AF_FILE, path="/var/run/vde/vde0/ctl/ctl"}, 110) = -1
ENOTDIR (Not a directory)
close(7)= 0
close(8)= 0
exit_group(1) = ?
root ~#
Please add a meaningful message.
Regards,
Étienne
Re: [Qemu-devel] [PATCH 1/6] Make the necessary changes in Makefile and configure file.
The commit message "Make the necessary changes in Makefile and configure file" provides no information, especially outside the context of your patch series. Please choose something more specific about what the patch is doing. CONFIG_POSIX=y excludes mingw32. Does this commit break Windows builds? I suspect vnc_thread and io_thread may not be available on Windows anyway. Should we actually add qemu-thread.o where threadlets.o gets added instead of putting it next to posix-aio-compat.o? Stefan
[Qemu-devel] [PATCH v2 4/6] qdev: introduce a helper function which triggers reset from a given device
Signed-off-by: Isaku Yamahata
Signed-off-by: Anthony Liguori
---
hw/qdev.c |5 +
hw/qdev.h |1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index b76da07..b65b63e 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -322,6 +322,11 @@ static int qbus_reset_one(BusState *bus, void *opaque)
return 0;
}
+void qdev_reset_all(DeviceState *dev)
+{
+qdev_walk_children(dev, qdev_reset_one, qbus_reset_one, NULL);
+}
+
void qbus_reset_all(BusState *bus)
{
qbus_walk_children(bus, qdev_reset_one, qbus_reset_one, NULL);
diff --git a/hw/qdev.h b/hw/qdev.h
index 5ac084f..3fac364 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -189,6 +189,7 @@ int qbus_walk_children(BusState *bus, qdev_walkerfn *devfn,
qbus_walkerfn *busfn, void *opaque);
int qdev_walk_children(DeviceState *dev, qdev_walkerfn *devfn,
qbus_walkerfn *busfn, void *opaque);
+void qdev_reset_all(DeviceState *dev);
void qbus_reset_all(BusState *bus);
void qbus_free(BusState *bus);
--
1.7.1.1
[Qemu-devel] [PATCH v2 2/6] qdev: reset qdev along with qdev tree
From: Anthony Liguori
This patch changes the reset handling so that qdev has no knowledge of the
global system reset. Instead, a new bus/device level function is introduced
that allows all devices/buses on the bus/device to be reset using a depth
first transversal.
N.B. we have to expose the implicit system bus because we have various hacks
that result in an implicit system bus existing. Instead, we ought to have an
explicitly created system bus that we can trigger reset from. That's a topic
for a future patch though.
Signed-off-by: Anthony Liguori
Signed-off-by: Isaku Yamahata
---
hw/qdev.c | 28 +++-
hw/qdev.h |4
vl.c |1 +
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 11d845a..92ccc8d 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -257,13 +257,6 @@ DeviceState *qdev_device_add(QemuOpts *opts)
return qdev;
}
-static void qdev_reset(void *opaque)
-{
-DeviceState *dev = opaque;
-if (dev->info->reset)
-dev->info->reset(dev);
-}
-
/* Initialize a device. Device properties should be set before calling
this function. IRQs and MMIO regions should be connected/mapped after
calling this function.
@@ -279,7 +272,6 @@ int qdev_init(DeviceState *dev)
qdev_free(dev);
return rc;
}
-qemu_register_reset(qdev_reset, dev);
if (dev->info->vmsd) {
vmstate_register_with_alias_id(dev, -1, dev->info->vmsd, dev,
dev->instance_id_alias,
@@ -308,6 +300,25 @@ int qdev_unplug(DeviceState *dev)
return dev->info->unplug(dev);
}
+static int qdev_reset_one(DeviceState *dev, void *opaque)
+{
+if (dev->info->reset) {
+dev->info->reset(dev);
+}
+
+return 0;
+}
+
+BusState *sysbus_get_default(void)
+{
+return main_system_bus;
+}
+
+void qbus_reset_all(BusState *bus)
+{
+qbus_walk_children(bus, qdev_reset_one, NULL, NULL);
+}
+
/* can be used as ->unplug() callback for the simple cases */
int qdev_simple_unplug_cb(DeviceState *dev)
{
@@ -351,7 +362,6 @@ void qdev_free(DeviceState *dev)
if (dev->opts)
qemu_opts_del(dev->opts);
}
-qemu_unregister_reset(qdev_reset, dev);
QLIST_REMOVE(dev, sibling);
for (prop = dev->info->props; prop && prop->name; prop++) {
if (prop->info->free) {
diff --git a/hw/qdev.h b/hw/qdev.h
index 550fd9b..e5ed333 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -187,10 +187,14 @@ int qbus_walk_children(BusState *bus, qdev_walkerfn
*devfn,
qbus_walkerfn *busfn, void *opaque);
int qdev_walk_children(DeviceState *dev, qdev_walkerfn *devfn,
qbus_walkerfn *busfn, void *opaque);
+void qbus_reset_all(BusState *bus);
void qbus_free(BusState *bus);
#define FROM_QBUS(type, dev) DO_UPCAST(type, qbus, dev)
+/* This should go away once we get rid of the NULL bus hack */
+BusState *sysbus_get_default(void);
+
/*** monitor commands ***/
void do_info_qtree(Monitor *mon);
diff --git a/vl.c b/vl.c
index c58583d..135fdeb 100644
--- a/vl.c
+++ b/vl.c
@@ -2976,6 +2976,7 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
+qemu_register_reset((void *)qbus_reset_all, sysbus_get_default());
qemu_system_reset();
if (loadvm) {
if (load_vmstate(loadvm) < 0) {
--
1.7.1.1
[Qemu-devel] [PATCH v2 6/6] pci bridge: implement secondary bus reset
Emulates secondary bus reset when secondary bus reset bit
is written from 0 to 1.
Signed-off-by: Isaku Yamahata
Signed-off-by: Anthony Liguori
---
hw/pci_bridge.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
index 58cc2e4..618a81e 100644
--- a/hw/pci_bridge.c
+++ b/hw/pci_bridge.c
@@ -139,6 +139,10 @@ pcibus_t pci_bridge_get_limit(const PCIDevice *bridge,
uint8_t type)
void pci_bridge_write_config(PCIDevice *d,
uint32_t address, uint32_t val, int len)
{
+PCIBridge *s = container_of(d, PCIBridge, dev);
+uint16_t bridge_control = pci_get_word(d->config + PCI_BRIDGE_CONTROL);
+uint16_t bridge_control_new;
+
pci_default_write_config(d, address, val, len);
if (/* io base/limit */
@@ -147,9 +151,15 @@ void pci_bridge_write_config(PCIDevice *d,
/* memory base/limit, prefetchable base/limit and
io base/limit upper 16 */
ranges_overlap(address, len, PCI_MEMORY_BASE, 20)) {
-PCIBridge *s = container_of(d, PCIBridge, dev);
pci_bridge_update_mappings(&s->sec_bus);
}
+
+bridge_control_new = pci_get_word(d->config + PCI_BRIDGE_CONTROL);
+if (!(bridge_control & PCI_BRIDGE_CTL_BUS_RESET) &&
+(bridge_control_new & PCI_BRIDGE_CTL_BUS_RESET)) {
+/* 0 -> 1 */
+pci_bus_reset(&s->sec_bus);
+}
}
void pci_bridge_disable_base_limit(PCIDevice *dev)
--
1.7.1.1
[Qemu-devel] [PATCH v2 1/6] qbus: add functions to walk both devices and busses
From: Anthony Liguori
There are some cases where you want to walk the busses, in particular, when
searching for a bus either by name or DeviceInfo.
Paolo suggested that we model the return values on how GCC's walkers work which
allows an actor to skip child transversal, or terminate walking with a positive
value that's returned as the qbus_walk_children's result.
Signed-off-by: Isaku Yamahata
Signed-off-by: Anthony Liguori
---
Changes v1 -> v2:
- update comments to match the implementation
---
hw/qdev.c | 46 ++
hw/qdev.h | 11 +++
2 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 35858cb..11d845a 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -449,6 +449,52 @@ BusState *qdev_get_child_bus(DeviceState *dev, const char
*name)
return NULL;
}
+int qbus_walk_children(BusState *bus, qdev_walkerfn *devfn,
+ qbus_walkerfn *busfn, void *opaque)
+{
+DeviceState *dev;
+int err;
+
+if (busfn) {
+err = busfn(bus, opaque);
+if (err) {
+return err;
+}
+}
+
+QLIST_FOREACH(dev, &bus->children, sibling) {
+err = qdev_walk_children(dev, devfn, busfn, opaque);
+if (err < 0) {
+return err;
+}
+}
+
+return 0;
+}
+
+int qdev_walk_children(DeviceState *dev, qdev_walkerfn *devfn,
+ qbus_walkerfn *busfn, void *opaque)
+{
+BusState *bus;
+int err;
+
+if (devfn) {
+err = devfn(dev, opaque);
+if (err) {
+return err;
+}
+}
+
+QLIST_FOREACH(bus, &dev->child_bus, sibling) {
+err = qbus_walk_children(bus, devfn, busfn, opaque);
+if (err < 0) {
+return err;
+}
+}
+
+return 0;
+}
+
static BusState *qbus_find_recursive(BusState *bus, const char *name,
const BusInfo *info)
{
diff --git a/hw/qdev.h b/hw/qdev.h
index 579328a..550fd9b 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -173,9 +173,20 @@ BusState *qdev_get_parent_bus(DeviceState *dev);
/*** BUS API. ***/
+/* Returns 0 to walk children, > 0 to skip walk, < 0 to terminate walk. */
+typedef int (qbus_walkerfn)(BusState *bus, void *opaque);
+typedef int (qdev_walkerfn)(DeviceState *dev, void *opaque);
+
void qbus_create_inplace(BusState *bus, BusInfo *info,
DeviceState *parent, const char *name);
BusState *qbus_create(BusInfo *info, DeviceState *parent, const char *name);
+/* Returns > 0 if either devfn or busfn skip walk somewhere in cursion,
+ * < 0 if either devfn or busfn terminate walk somewhere in cursion,
+ * 0 otherwise. */
+int qbus_walk_children(BusState *bus, qdev_walkerfn *devfn,
+ qbus_walkerfn *busfn, void *opaque);
+int qdev_walk_children(DeviceState *dev, qdev_walkerfn *devfn,
+ qbus_walkerfn *busfn, void *opaque);
void qbus_free(BusState *bus);
#define FROM_QBUS(type, dev) DO_UPCAST(type, qbus, dev)
--
1.7.1.1
[Qemu-devel] [PATCH v2 0/6] qdev reset refactoring and pci bus reset
Here is v2. I updated the comments, and dropped the pci qdev reset patch. Patch description: The goal of this patch series is to implement secondary bus reset emulation in pci-to-pci bridge. At first, this patch series refactors qdev reset, and then cleans up pci bus reset. Lastly implements pci bridge control secondary bus reset bit. This patch series is for pci bus reset, which is ported from the following repo. git://repo.or.cz/qemu/aliguori.git qdev-refactor Changes v1 -> v2: - update comment Anthony Liguori (2): qbus: add functions to walk both devices and busses qdev: reset qdev along with qdev tree Isaku Yamahata (4): qdev: introduce reset call back for qbus level qdev: introduce a helper function which triggers reset from a given device pci: make use of qdev reset frame work to pci bus reset. pci bridge: implement secondary bus reset hw/pci.c| 33 ++-- hw/pci.h|3 ++ hw/pci_bridge.c | 12 +++- hw/qdev.c | 87 +-- hw/qdev.h | 18 +++ vl.c|1 + 6 files changed, 140 insertions(+), 14 deletions(-)
[Qemu-devel] [PATCH v2 5/6] pci: make use of qdev reset frame work to pci bus reset.
Signed-off-by: Isaku Yamahata
Signed-off-by: Anthony Liguori
---
hw/pci.c | 33 +
hw/pci.h |3 +++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 962886e..51b7857 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -43,12 +43,14 @@
static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
static char *pcibus_get_dev_path(DeviceState *dev);
+static int pcibus_reset(BusState *qbus);
struct BusInfo pci_bus_info = {
.name = "PCI",
.size = sizeof(PCIBus),
.print_dev = pcibus_dev_print,
.get_dev_path = pcibus_get_dev_path,
+.reset = pcibus_reset,
.props = (Property[]) {
DEFINE_PROP_PCI_DEVFN("addr", PCIDevice, devfn, -1),
DEFINE_PROP_STRING("romfile", PCIDevice, romfile),
@@ -133,7 +135,7 @@ static void pci_update_irq_status(PCIDevice *dev)
}
}
-static void pci_device_reset(PCIDevice *dev)
+void pci_device_reset_default(PCIDevice *dev)
{
int r;
@@ -161,9 +163,24 @@ static void pci_device_reset(PCIDevice *dev)
pci_update_mappings(dev);
}
-static void pci_bus_reset(void *opaque)
+static void pci_device_reset(PCIDevice *dev)
+{
+if (!dev->qdev.info) {
+/* not all pci devices haven't been qdev'fied yet
+ TODO: remove this when all pci devices are qdev'fied. */
+pci_device_reset_default(dev);
+} else {
+qdev_reset_all(&dev->qdev);
+pci_device_reset_default(dev);
+}
+}
+
+/*
+ * Trigger pci bus reset under a given bus.
+ * This functions emulates RST#.
+ */
+void pci_bus_reset(PCIBus *bus)
{
-PCIBus *bus = opaque;
int i;
for (i = 0; i < bus->nirq; i++) {
@@ -176,6 +193,15 @@ static void pci_bus_reset(void *opaque)
}
}
+static int pcibus_reset(BusState *qbus)
+{
+pci_bus_reset(DO_UPCAST(PCIBus, qbus, qbus));
+
+/* topology traverse is done by pci_bus_reset().
+ Tell qbus/qdev walker not to traverse the tree */
+return 1;
+}
+
static void pci_host_bus_register(int domain, PCIBus *bus)
{
struct PCIHostBus *host;
@@ -230,7 +256,6 @@ void pci_bus_new_inplace(PCIBus *bus, DeviceState *parent,
pci_host_bus_register(0, bus); /* for now only pci domain 0 is supported */
vmstate_register(NULL, -1, &vmstate_pcibus, bus);
-qemu_register_reset(pci_bus_reset, bus);
}
PCIBus *pci_bus_new(DeviceState *parent, const char *name, int devfn_min)
diff --git a/hw/pci.h b/hw/pci.h
index 7100804..280a2f8 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -225,6 +225,9 @@ PCIBus *pci_register_bus(DeviceState *parent, const char
*name,
pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
void *irq_opaque, int devfn_min, int nirq);
+void pci_bus_reset(PCIBus *bus);
+void pci_device_reset_default(PCIDevice *dev);
+
void pci_bus_set_mem_base(PCIBus *bus, target_phys_addr_t base);
PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
--
1.7.1.1
[Qemu-devel] [PATCH v2 3/6] qdev: introduce reset call back for qbus level
and make it called via qbus_reset_all().
The qbus reset callback will be used by pci bus reset.
Signed-off-by: Isaku Yamahata
Signed-off-by: Anthony Liguori
---
hw/qdev.c | 10 +-
hw/qdev.h |2 ++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 92ccc8d..b76da07 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -314,9 +314,17 @@ BusState *sysbus_get_default(void)
return main_system_bus;
}
+static int qbus_reset_one(BusState *bus, void *opaque)
+{
+if (bus->info->reset) {
+return bus->info->reset(bus);
+}
+return 0;
+}
+
void qbus_reset_all(BusState *bus)
{
-qbus_walk_children(bus, qdev_reset_one, NULL, NULL);
+qbus_walk_children(bus, qdev_reset_one, qbus_reset_one, NULL);
}
/* can be used as ->unplug() callback for the simple cases */
diff --git a/hw/qdev.h b/hw/qdev.h
index e5ed333..5ac084f 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -49,12 +49,14 @@ struct DeviceState {
typedef void (*bus_dev_printfn)(Monitor *mon, DeviceState *dev, int indent);
typedef char *(*bus_get_dev_path)(DeviceState *dev);
+typedef int (qbus_resetfn)(BusState *bus);
struct BusInfo {
const char *name;
size_t size;
bus_dev_printfn print_dev;
bus_get_dev_path get_dev_path;
+qbus_resetfn *reset;
Property *props;
};
--
1.7.1.1
Re: [Qemu-devel] [PATCH 2/6] Move paio_cancel() to new infrastructure.
On Thu, Nov 18, 2010 at 6:06 PM, Arun R Bharadwaj wrote: > Move paio_cancel() to new infrastructure and introduce > the necessary APIs for this. > > Signed-off-by: Arun R Bharadwaj > --- > posix-aio-compat.c | 92 > ++-- > 1 files changed, 74 insertions(+), 18 deletions(-) This commit is not a safe step to make. paio_cancel() is going to cause uninitialized threadlet structures to be accessed. You split the patches up into smaller commits for easier review. Unfortunately this particular commit will result in a QEMU which builds successfully but has undefined behavior at runtime - it may crash or do random things. That's a problem for git-bisect(1) and in general for anyone who assumes they can build QEMU at an arbitrary point in the commit history. It's really important to preserve bisectability, because once commits get introduced that build bad QEMUs we can no longer have confidence in bisect! Please split up commits so they introduce a new feature incrementally but work properly at each step in the series. Stefan
[Qemu-devel] Re: [PATCH 08/10] ahci: add ahci emulation
On Fri, Nov 19, 2010 at 04:12:43AM -0500, Gerd Hoffmann wrote: > >>> +static void ahci_check_irq(AHCIState *s) > >> > >> MSI support would be nice to have. > > > > Alrighty, I added MSI support. But I only have a single vector in use > > atm as nvec> 0 doesn't get written to the PCI config space so the code > > trips on that later on. > > For multiple vectors MSI-X is the best choice as it fixes a few design > issues MSI has when it comes to multiple vectors. I think linux never > ever uses MSI with multiple vectors anyway. Linux doesn't even support MSI with multiple vectors today. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
Re: [Qemu-devel] [PATCH 6/6] Add helper functions to enable virtio-9p make use of the threadlets
On Thu, Nov 18, 2010 at 6:07 PM, Arun R Bharadwaj wrote: > From: Gautham R Shenoy > > infrastructure for offloading blocking tasks such as making posix calls on > to the helper threads and handle the post_posix_operations() from the > context of the iothread. This frees the vcpu thread to process any other guest > operations while the processing of v9fs_io is in progress. > > Signed-off-by: Gautham R Shenoy > Signed-off-by: Sripathi Kodi > Signed-off-by: Arun R Bharadwaj > --- > hw/virtio-9p.c | 164 > > posix-aio-compat.c | 30 +++--- > qemu-threadlets.c | 21 +++ > qemu-threadlets.h | 1 > vl.c | 3 + > 5 files changed, 196 insertions(+), 23 deletions(-) Is there code queued up which makes use of this in virtfs? I ask because at the moment this is deadcode. If you are restructuring this patch series, perhaps move the signal related changes into a commit - they are independent of virtfs. Stefan
Re: [Qemu-devel] Re: [PATCH 0/2] v8 Decouple block device removal from device removal
On Fri, 12 Nov 2010 18:38:57 +0100 Kevin Wolf wrote: > Am 12.11.2010 18:07, schrieb Ryan Harper: > > details, details, v8 > > > > This patch series decouples the detachment of a block device from the > > removal of the backing pci-device. Removal of a hotplugged pci device > > requires the guest to respond before qemu tears down the block device. > > In some cases, the guest may not respond leaving the guest with > > continued access to the block device. Mgmt layer doesn't have a > > reliable method to force a disconnect. > > > > The new monitor command, drive_del, will revoke a guests access to the > > block device independently of the removal of the pci device. > > > > The first patch implements drive_del, the second patch implements the > > qmp version of the monitor command. > > > > Changes since v7: > > - Fixed up doc strings (delete -> drive_del) > > Changes since v6: > > - Updated patch description > > - Dropped bdrv_unplug and inlined in drive_del > > - Explicitly invoke drive_uninit() > > Changes since v5: > > - Removed dangling pointers in guest and host state. This ensures things > > like > > info block no longer displays the deleted drive; though info pci will > > continue to display the pci device until the guest responds to the removal > > request. > > - Renamed drive_unplug -> drive_del > > Changes since v4: > > - Droppped drive_get_by_id patch and use bdrv_find() instead > > - Added additional details about drive_unplug to hmp/qmp interface > > > > Changes since v3: > > - Moved QMP command for drive_unplug() to separate patch > > > > Changes since v2: > > - Added QMP command for drive_unplug() > > > > Changes since v1: > > - CodingStyle fixes > > - Added qemu_aio_flush() to bdrv_unplug() > > > > Signed-off-by: Ryan Harper > > Thanks, applied both to the block branch. I guess the conclusion was that we don't want the new command in QMP? http://lists.gnu.org/archive/html/qemu-devel/2010-11/msg01084.html
[Qemu-devel] Re: [PATCH 7/7] pci bridge: implement secondary bus reset
On Fri, Nov 19, 2010 at 05:15:19PM +0900, Isaku Yamahata wrote:
> On Thu, Nov 18, 2010 at 10:46:25AM +0200, Michael S. Tsirkin wrote:
> > On Thu, Nov 18, 2010 at 04:29:10PM +0900, Isaku Yamahata wrote:
> > > On Thu, Nov 18, 2010 at 09:05:30AM +0200, Michael S. Tsirkin wrote:
> > > > On Wed, Nov 17, 2010 at 01:50:27PM +0900, Isaku Yamahata wrote:
> > > > > Emulates secondary bus reset when secondary bus reset bit
> > > > > is written from 0 to 1.
> > > > >
> > > > > Signed-off-by: Isaku Yamahata
> > > > > Signed-off-by: Anthony Liguori
> > > > > ---
> > > > > hw/pci_bridge.c | 12 +++-
> > > > > 1 files changed, 11 insertions(+), 1 deletions(-)
> > > > >
> > > > > diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
> > > > > index 58cc2e4..618a81e 100644
> > > > > --- a/hw/pci_bridge.c
> > > > > +++ b/hw/pci_bridge.c
> > > > > @@ -139,6 +139,10 @@ pcibus_t pci_bridge_get_limit(const PCIDevice
> > > > > *bridge, uint8_t type)
> > > > > void pci_bridge_write_config(PCIDevice *d,
> > > > > uint32_t address, uint32_t val, int len)
> > > > > {
> > > > > +PCIBridge *s = container_of(d, PCIBridge, dev);
> > > > > +uint16_t bridge_control = pci_get_word(d->config +
> > > > > PCI_BRIDGE_CONTROL);
> > > > > +uint16_t bridge_control_new;
> > > > > +
> > > > > pci_default_write_config(d, address, val, len);
> > > > >
> > > > > if (/* io base/limit */
> > > > > @@ -147,9 +151,15 @@ void pci_bridge_write_config(PCIDevice *d,
> > > > > /* memory base/limit, prefetchable base/limit and
> > > > > io base/limit upper 16 */
> > > > > ranges_overlap(address, len, PCI_MEMORY_BASE, 20)) {
> > > > > -PCIBridge *s = container_of(d, PCIBridge, dev);
> > > > > pci_bridge_update_mappings(&s->sec_bus);
> > > > > }
> > > > > +
> > > > > +bridge_control_new = pci_get_word(d->config +
> > > > > PCI_BRIDGE_CONTROL);
> > > > > +if (!(bridge_control & PCI_BRIDGE_CTL_BUS_RESET) &&
> > > > > +(bridge_control_new & PCI_BRIDGE_CTL_BUS_RESET)) {
> > > > > +/* 0 -> 1 */
> > > > > +pci_bus_reset(&s->sec_bus);
> > > > > +}
> > > > > }
> > > > >
> > > > > void pci_bridge_disable_base_limit(PCIDevice *dev)
> > > >
> > > > Presumably this bit will have to be made writeable?
> > >
> > > Yes, it's already writable.
> > > static void pci_init_wmask_bridge(PCIDevice *d)
> > > ...
> > >pci_set_word(d->wmask + PCI_BRIDGE_CONTROL, 0x);
> >
> > Ouch, that's wrong, isn't it?
> > Bits 15:12 are reserved, readonly, 0.
> >
> > I think we need the following (untested).
> > Comments?
>
> Basically it looks good if you left bits 8-11 RO intentional.
> qemu doesn't emulate pci bus cycles, so it won't matter.
Hmm, no, not intentional. I'll fix it up.
> Also, please include following hunk.
>
> commit 8c76e0427234290a640499c1305cabd998d6f777
> Author: Isaku Yamahata
> Date: Fri Nov 19 17:08:57 2010 +0900
>
> pcie/port: initialize bridge control register properly
>
> pci generic layer initialized bridge control register
> according to pci spec. pcie deviates slightly from it,
> so initializes it properly.
>
> Signed-off-by: Isaku Yamahata
Applied, thanks.
> diff --git a/hw/pcie_port.c b/hw/pcie_port.c
> index 117de61..340dcdb 100644
> --- a/hw/pcie_port.c
> +++ b/hw/pcie_port.c
> @@ -27,6 +27,14 @@ void pcie_port_init_reg(PCIDevice *d)
> pci_set_word(d->config + PCI_STATUS, 0);
> pci_set_word(d->config + PCI_SEC_STATUS, 0);
>
> +/* Unlike conventional pci bridge, some bits are hardwared to 0. */
> +pci_set_word(d->wmask + PCI_BRIDGE_CONTROL,
> + PCI_BRIDGE_CTL_PARITY |
> + PCI_BRIDGE_CTL_ISA |
> + PCI_BRIDGE_CTL_VGA |
> + PCI_BRIDGE_CTL_SERR |
> + PCI_BRIDGE_CTL_BUS_RESET);
> +
> /* 7.5.3.5 Prefetchable Memory Base Limit
> * The Prefetchable Memory Base and Prefetchable Memory Limit registers
> * must indicate that 64-bit addresses are supported, as defined in
>
>
> >
> > pci: fix bridge control bit wmask
> >
> > Bits 12 to 15 in bridge control register are reserver and must be
> > read-only zero, curent mask is 0x which makes them writeable. Fix
> > this up by using symbolic bit names for writeable bits instead of a
> > hardcoded constant.
> >
> > Signed-off-by: Michael S. Tsirkin
> >
> > --
> >
> > diff --git a/hw/pci.c b/hw/pci.c
> > index 00ec8ea..7d6d5ad 100644
> > --- a/hw/pci.c
> > +++ b/hw/pci.c
> > @@ -588,7 +588,17 @@ static void pci_init_wmask_bridge(PCIDevice *d)
> > /* PCI_PREF_BASE_UPPER32 and PCI_PREF_LIMIT_UPPER32 */
> > memset(d->wmask + PCI_PREF_BASE_UPPER32, 0xff, 8);
> >
> > -pci_set_word(d->wmask + PCI_BRIDGE_CONTROL, 0x);
> > +/* TODO: add this define to pci_regs.h in linux and then in qemu. */
> > +#define PCI_BRIDGE_CTL_VGA_16BIT 0x10 /* VGA 16-bit decode */
> > +pci_set_word(d->wma
Re: [Qemu-devel] Re: [PATCH 09/16] scsi-disk: Allocate iovec dynamically
Am 18.11.2010 17:28, schrieb Hannes Reinecke:
> On 11/18/2010 04:33 PM, Gerd Hoffmann wrote:
>> Hi,
>>
>>> +static size_t scsi_req_iov_len(SCSIDiskReq *r)
>>> +{
>>> +size_t iov_len = 0;
>>> +int i;
>>> +
>>> +for (i = 0; i< r->iov_num; i++)
>>> +iov_len += r->iov[i].iov_len;
>>> +
>>> +return iov_len;
>>> +}
>>
>> You are aware that there is a QEMUIOVector type with helper functions
>> which keeps track of both number of elements and total size?
>>
> Yes. But I'm passing passing in an entire iovec to the request.
> However, the QEMUIOVector routines allow you to add only _one_
> element at a time, which is pretty wasteful here.
Does the iov need to be changed afterwards, or why doesn't
qemu_iovec_init_external work here?
> And I'm counting the resulting length of the iovec, which might have
> been changed by read/write operations. For which there is no generic
> function either.
Can you explain which kind of read/write operations would change the
iov? This is not completely clear to me.
In general the same information that you're calculating here should be
stored in qiov->size for a QEUMIOVector, but depending what changes you
mean above it may not provide all operations you need.
Kevin
Re: [Qemu-devel] [PATCH 00/10] AHCI emulation support v2
Hi, As I would rather have something working we can base on in the tree, so whoever volunteers for the refactoring (hint!) knows how to design the interfaces, I am not sure how much is reasonable within this patch set. I guess I have to read this as: You want to drop the code into the repository, no matter what mess it creates, and leave the cleanup to some volunteer that will never appear. So whoever is in the unfortunate position of having to touch the IDE code afterwards will have the pain because this series is doing only the half of what should be done. Well, this is how IDE gets cleaned up right now. I was one of the victims ;) IDE is in a noticeable better state than it used to be two years ago. It is still quite messy though. I'm sure that with a working time of only a few days the result could be substantially improved, even if a month would be needed for perfection. [ disclaimer: didn't look at v3 yet ] Adding ahci should at least not make it more messy that it already is. Doing the controller-depending dispatching through a function pointer table (aka IDEBusOps) looks sane to me. SCSI does the same, although without a Ops struct as it needs a single function pointer only. Moving code shared between sata/ahci and ide to another source file (ata.c ?) makes sense and would be a good start to make clear which code is used for what. IDEBus must learn some things about sata. For example there is no such thing as a slave device, so a IDEBus representing a sata port must not allow slave devices being attached. Fixing the IDEState mess would be great. Right now IDEBus carries a array of IDEStates for master and slave for historical reasons: The ide code (used to?) assume that the IDEStates for master and slave are allocated together and that it can easily jump from one to the other and back using pointer arithmetics on the IDEState struct. IDEState doesn't belong there though, it should be part of IDEDrive. Also having a unused slave state doesn't make sense at all for sata. Fixing that without breaking migration could be non-trivial though. cheers, Gerd
[Qemu-devel] Re: [PATCH v2 6/6] pci bridge: implement secondary bus reset
On Fri, Nov 19, 2010 at 06:56:03PM +0900, Isaku Yamahata wrote:
> Emulates secondary bus reset when secondary bus reset bit
> is written from 0 to 1.
>
Interesting. This is not exactly what happens on real hardware
though: there, RST# stays asserted until bit is cleared.
So for example attempts to scan the secondary bus will
return nothing.
Can implement this later, but please add a comment here.
> Signed-off-by: Isaku Yamahata
> Signed-off-by: Anthony Liguori
> ---
> hw/pci_bridge.c | 12 +++-
> 1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
> index 58cc2e4..618a81e 100644
> --- a/hw/pci_bridge.c
> +++ b/hw/pci_bridge.c
> @@ -139,6 +139,10 @@ pcibus_t pci_bridge_get_limit(const PCIDevice *bridge,
> uint8_t type)
> void pci_bridge_write_config(PCIDevice *d,
> uint32_t address, uint32_t val, int len)
> {
> +PCIBridge *s = container_of(d, PCIBridge, dev);
> +uint16_t bridge_control = pci_get_word(d->config + PCI_BRIDGE_CONTROL);
> +uint16_t bridge_control_new;
I'd prefer shorter names for local variables.
> +
> pci_default_write_config(d, address, val, len);
>
> if (/* io base/limit */
> @@ -147,9 +151,15 @@ void pci_bridge_write_config(PCIDevice *d,
> /* memory base/limit, prefetchable base/limit and
> io base/limit upper 16 */
> ranges_overlap(address, len, PCI_MEMORY_BASE, 20)) {
> -PCIBridge *s = container_of(d, PCIBridge, dev);
> pci_bridge_update_mappings(&s->sec_bus);
> }
> +
> +bridge_control_new = pci_get_word(d->config + PCI_BRIDGE_CONTROL);
> +if (!(bridge_control & PCI_BRIDGE_CTL_BUS_RESET) &&
> +(bridge_control_new & PCI_BRIDGE_CTL_BUS_RESET)) {
Equivalent but shorter:
~bridge_control & bridge_control_new & PCI_BRIDGE_CTL_BUS_RESET
> +/* 0 -> 1 */
> +pci_bus_reset(&s->sec_bus);
> +}
> }
>
> void pci_bridge_disable_base_limit(PCIDevice *dev)
> --
> 1.7.1.1
[Qemu-devel] Re: [PATCH 0/2] Re: [PATCH v9 5/8] pcie/aer: helper functions for pcie aer capability
On Fri, Nov 19, 2010 at 06:42:27PM +0900, Isaku Yamahata wrote: > On Wed, Nov 17, 2010 at 04:06:38PM +0200, Michael S. Tsirkin wrote: > > Please, try to address the TODO: I think the case of > > PCIE device behind a pci bridge is not covered properly. > > Right, pci-to-pcie bridge case isn't covered. > Although SERR bit can be set, the error can't be propagated up further > because qemu doesn't emulate PERR#/SERR#. > > There is no use case of pci-to-pcie bridge in qemu, I think. I think it's useful to put an express device behind a pci bridge in qemu, because pci bridges are tested and supported by more guests. > If good error handling is wanted, express should be used. > So it isn't worthwhile to implement pci-to-pcie bridge. Okay, we can look into this later. > -- > yamahata
[Qemu-devel] Re: [PATCH 7/7] pci bridge: implement secondary bus reset
On Fri, Nov 19, 2010 at 05:15:19PM +0900, Isaku Yamahata wrote:
> On Thu, Nov 18, 2010 at 10:46:25AM +0200, Michael S. Tsirkin wrote:
> > On Thu, Nov 18, 2010 at 04:29:10PM +0900, Isaku Yamahata wrote:
> > > On Thu, Nov 18, 2010 at 09:05:30AM +0200, Michael S. Tsirkin wrote:
> > > > On Wed, Nov 17, 2010 at 01:50:27PM +0900, Isaku Yamahata wrote:
> > > > > Emulates secondary bus reset when secondary bus reset bit
> > > > > is written from 0 to 1.
> > > > >
> > > > > Signed-off-by: Isaku Yamahata
> > > > > Signed-off-by: Anthony Liguori
> > > > > ---
> > > > > hw/pci_bridge.c | 12 +++-
> > > > > 1 files changed, 11 insertions(+), 1 deletions(-)
> > > > >
> > > > > diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
> > > > > index 58cc2e4..618a81e 100644
> > > > > --- a/hw/pci_bridge.c
> > > > > +++ b/hw/pci_bridge.c
> > > > > @@ -139,6 +139,10 @@ pcibus_t pci_bridge_get_limit(const PCIDevice
> > > > > *bridge, uint8_t type)
> > > > > void pci_bridge_write_config(PCIDevice *d,
> > > > > uint32_t address, uint32_t val, int len)
> > > > > {
> > > > > +PCIBridge *s = container_of(d, PCIBridge, dev);
> > > > > +uint16_t bridge_control = pci_get_word(d->config +
> > > > > PCI_BRIDGE_CONTROL);
> > > > > +uint16_t bridge_control_new;
> > > > > +
> > > > > pci_default_write_config(d, address, val, len);
> > > > >
> > > > > if (/* io base/limit */
> > > > > @@ -147,9 +151,15 @@ void pci_bridge_write_config(PCIDevice *d,
> > > > > /* memory base/limit, prefetchable base/limit and
> > > > > io base/limit upper 16 */
> > > > > ranges_overlap(address, len, PCI_MEMORY_BASE, 20)) {
> > > > > -PCIBridge *s = container_of(d, PCIBridge, dev);
> > > > > pci_bridge_update_mappings(&s->sec_bus);
> > > > > }
> > > > > +
> > > > > +bridge_control_new = pci_get_word(d->config +
> > > > > PCI_BRIDGE_CONTROL);
> > > > > +if (!(bridge_control & PCI_BRIDGE_CTL_BUS_RESET) &&
> > > > > +(bridge_control_new & PCI_BRIDGE_CTL_BUS_RESET)) {
> > > > > +/* 0 -> 1 */
> > > > > +pci_bus_reset(&s->sec_bus);
> > > > > +}
> > > > > }
> > > > >
> > > > > void pci_bridge_disable_base_limit(PCIDevice *dev)
> > > >
> > > > Presumably this bit will have to be made writeable?
> > >
> > > Yes, it's already writable.
> > > static void pci_init_wmask_bridge(PCIDevice *d)
> > > ...
> > >pci_set_word(d->wmask + PCI_BRIDGE_CONTROL, 0x);
> >
> > Ouch, that's wrong, isn't it?
> > Bits 15:12 are reserved, readonly, 0.
> >
> > I think we need the following (untested).
> > Comments?
>
> Basically it looks good if you left bits 8-11 RO intentional.
> qemu doesn't emulate pci bus cycles, so it won't matter.
>
So this on top?
diff --git a/hw/pci.c b/hw/pci.c
index 7d6d5ad..75da4f7 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -589,7 +589,11 @@ static void pci_init_wmask_bridge(PCIDevice *d)
memset(d->wmask + PCI_PREF_BASE_UPPER32, 0xff, 8);
/* TODO: add this define to pci_regs.h in linux and then in qemu. */
-#define PCI_BRIDGE_CTL_VGA_16BIT 0x10 /* VGA 16-bit decode */
+#define PCI_BRIDGE_CTL_VGA_16BIT 0x10/* VGA 16-bit decode */
+#define PCI_BRIDGE_CTL_DISCARD0x100 /* Primary discard
timer */
+#define PCI_BRIDGE_CTL_SEC_DISCARD0x200 /* Secondary discard timer */
+#define PCI_BRIDGE_CTL_DISCARD_STATUS 0x400 /* Discard timer status */
+#define PCI_BRIDGE_CTL_DISCARD_SERR 0x800 /* Discard timer SERR# enable */
pci_set_word(d->wmask + PCI_BRIDGE_CONTROL,
PCI_BRIDGE_CTL_PARITY |
PCI_BRIDGE_CTL_SERR |
@@ -598,7 +602,15 @@ static void pci_init_wmask_bridge(PCIDevice *d)
PCI_BRIDGE_CTL_VGA_16BIT |
PCI_BRIDGE_CTL_MASTER_ABORT |
PCI_BRIDGE_CTL_BUS_RESET |
- PCI_BRIDGE_CTL_FAST_BACK);
+ PCI_BRIDGE_CTL_FAST_BACK |
+ PCI_BRIDGE_CTL_DISCARD |
+ PCI_BRIDGE_CTL_SEC_DISCARD |
+ PCI_BRIDGE_CTL_DISCARD_STATUS |
+ PCI_BRIDGE_CTL_DISCARD_SERR);
+/* Below does not do anything as we never set this bit, put here for
+ * completeness. */
+pci_set_word(d->w1mask + PCI_BRIDGE_CONTROL,
+ PCI_BRIDGE_CTL_DISCARD_STATUS);
}
static int pci_init_multifunction(PCIBus *bus, PCIDevice *dev)
Re: [Qemu-devel] [PATCH 00/10] AHCI emulation support v2
Am 19.11.2010 12:56, schrieb Gerd Hoffmann: >Hi, > >>> As I would rather have something working we can base on in the >>> tree, so whoever volunteers for the refactoring (hint!) knows how >>> to design the interfaces, I am not sure how much is reasonable >>> within this patch set. >> >> I guess I have to read this as: You want to drop the code into the >> repository, no matter what mess it creates, and leave the cleanup to >> some volunteer that will never appear. So whoever is in the >> unfortunate position of having to touch the IDE code afterwards will >> have the pain because this series is doing only the half of what >> should be done. > > Well, this is how IDE gets cleaned up right now. I was one of the > victims ;) > > IDE is in a noticeable better state than it used to be two years ago. > It is still quite messy though. Sure that's how it works today. We have no choice because we can't change the mistakes that were made in the past. But we can avoid to contribute new mess to it or we'll need even more victims. ;-) >> I'm sure that with a working time of only a few days the result could >> be substantially improved, even if a month would be needed for >> perfection. > > [ disclaimer: didn't look at v3 yet ] > > Adding ahci should at least not make it more messy that it already is. > > Doing the controller-depending dispatching through a function pointer > table (aka IDEBusOps) looks sane to me. SCSI does the same, although > without a Ops struct as it needs a single function pointer only. Yes, I suppose (still haven't looked at it in detail) these interfaces are generally sane, based on your comments and a quick look. This is also what makes me think that doing the next step shouldn't be too hard. The abstraction is basically in place, the rest should be mostly code movement and maybe splitting up some IDE data structures to make things look more symmetric between PATA and SATA. > Moving code shared between sata/ahci and ide to another source file > (ata.c ?) makes sense and would be a good start to make clear which code > is used for what. I agree (and ata.c would have been my suggestion, too). > IDEBus must learn some things about sata. For example there is no such > thing as a slave device, so a IDEBus representing a sata port must not > allow slave devices being attached. Hm, do the generic functions (i.e. what would end up in ata.c) even need access to the IDEBus? If not, we could leave IDEBus as it is for Legacy IDE and introduce a completely new SATABus. Most occurrences in core.c seem to use the bus only for ide_set_irq. > Fixing the IDEState mess would be great. Right now IDEBus carries a > array of IDEStates for master and slave for historical reasons: The ide > code (used to?) assume that the IDEStates for master and slave are > allocated together and that it can easily jump from one to the other and > back using pointer arithmetics on the IDEState struct. IDEState doesn't > belong there though, it should be part of IDEDrive. Okay, that makes sense. Kevin
Re: [Qemu-devel] Re: [PATCH 09/16] scsi-disk: Allocate iovec dynamically
On 11/19/2010 12:43 PM, Kevin Wolf wrote:
> Am 18.11.2010 17:28, schrieb Hannes Reinecke:
>> On 11/18/2010 04:33 PM, Gerd Hoffmann wrote:
>>> Hi,
>>>
+static size_t scsi_req_iov_len(SCSIDiskReq *r)
+{
+size_t iov_len = 0;
+int i;
+
+for (i = 0; i< r->iov_num; i++)
+iov_len += r->iov[i].iov_len;
+
+return iov_len;
+}
>>>
>>> You are aware that there is a QEMUIOVector type with helper functions
>>> which keeps track of both number of elements and total size?
>>>
>> Yes. But I'm passing passing in an entire iovec to the request.
>> However, the QEMUIOVector routines allow you to add only _one_
>> element at a time, which is pretty wasteful here.
>
> Does the iov need to be changed afterwards, or why doesn't
> qemu_iovec_init_external work here?
>
Oh, but I _do_ use qemu_iovec_init_external(); cf
hw/scsi_disk.c:scsi_read_data()
and yes, the iovec might be modified by the read/write operation;
see below.
>> And I'm counting the resulting length of the iovec, which might have
>> been changed by read/write operations. For which there is no generic
>> function either.
>
> Can you explain which kind of read/write operations would change the
> iov? This is not completely clear to me.
>
It is perfectly valid to send down an iovec larger than the command
would fill out; eg for a SCSI Inquiry you could easily request 255
bytes, but the command itself would only provide you with say 36 bytes.
Using SG_IO you would pass down the iovec (with the full size of
255), and you would be returned the same iovec. However, the
->iov_len parameter of the iovec elements would be modified
depending on the size of the actual data returned. Hence you need to
figure out the resulting size of the iovec by the above command.
> In general the same information that you're calculating here should be
> stored in qiov->size for a QEUMIOVector, but depending what changes you
> mean above it may not provide all operations you need.
>
Ah. Seem to have missed it. Care to point it out to me?
But I don't think it'll work for the scsi-generic case, where we're
just using SG_IO.
But then, I tend to get lost in the callbacks-upon-callbacks
reference in the block layer, so there's a fair chance I haven't
seen it.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] Re: [PATCH 09/16] scsi-disk: Allocate iovec dynamically
Am 19.11.2010 13:30, schrieb Hannes Reinecke:
> On 11/19/2010 12:43 PM, Kevin Wolf wrote:
>> Am 18.11.2010 17:28, schrieb Hannes Reinecke:
>>> On 11/18/2010 04:33 PM, Gerd Hoffmann wrote:
Hi,
> +static size_t scsi_req_iov_len(SCSIDiskReq *r)
> +{
> +size_t iov_len = 0;
> +int i;
> +
> +for (i = 0; i< r->iov_num; i++)
> +iov_len += r->iov[i].iov_len;
> +
> +return iov_len;
> +}
You are aware that there is a QEMUIOVector type with helper functions
which keeps track of both number of elements and total size?
>>> Yes. But I'm passing passing in an entire iovec to the request.
>>> However, the QEMUIOVector routines allow you to add only _one_
>>> element at a time, which is pretty wasteful here.
>>
>> Does the iov need to be changed afterwards, or why doesn't
>> qemu_iovec_init_external work here?
>>
> Oh, but I _do_ use qemu_iovec_init_external(); cf
>
> hw/scsi_disk.c:scsi_read_data()
>
> and yes, the iovec might be modified by the read/write operation;
> see below.
>
>>> And I'm counting the resulting length of the iovec, which might have
>>> been changed by read/write operations. For which there is no generic
>>> function either.
>>
>> Can you explain which kind of read/write operations would change the
>> iov? This is not completely clear to me.
>>
> It is perfectly valid to send down an iovec larger than the command
> would fill out; eg for a SCSI Inquiry you could easily request 255
> bytes, but the command itself would only provide you with say 36 bytes.
Okay, so at the point where you create the iovec you don't have this
information yet but rather let the command emulation update the iovec
later. Makes sense.
That's probably something that QEMUIOVectors isn't really designed for,
so just forget what I said. :-)
Kevin
Re: [Qemu-devel] [PATCH 00/10] AHCI emulation support v2
On 19.11.2010, at 10:15, Kevin Wolf wrote: > Am 18.11.2010 19:43, schrieb Alexander Graf: >> >> On 18.11.2010, at 14:26, Kevin Wolf wrote: >> >>> Hi Alex, >>> >>> Am 18.11.2010 04:27, schrieb Alexander Graf: This patch adds support for AHCI emulation. I have tested and verified it works in Linux, OpenBSD, Windows Vista and Windows 7. This AHCI emulation supports NCQ, so multiple read or write requests can be outstanding at the same time. The code is however not fully optimized yet. I'm fairly sure that there are low hanging performance fruits to be found still :). In my simple benchmarks I achieved about 2/3rd of virtio performance. Also, this AHCI emulation layer does not support legacy mode. So if you're using a disk with this emulation, you do not get it exposed using the legacy IDE interfaces. Another nitpick is CD-ROM support in Windows. Somehow it doesn't detect a CD-ROM drive attached to AHCI. At least it doesn't list it. To attach an AHCI disk to your VM, please use -drive file=...,if=sata This should do the trick for x86. On other platforms, you might need to add the ahci host controller using -device. This patch set is based on work done during the Google Summer of Code. I was mentoring a student, Roland Elek, who wrote most of the AHCI emulation code based on a patch from Chong Qiao. A bunch of other people were also involved, so everybody who I didn't mention - thanks a lot! >>> >>> I'm not completely sure about the relationship between the AHCI >>> emulation and our existing IDE emulation. First thing I noticed is that >>> AHCI wants to be independent and resides in hw/ instead of hw/ide/, but >>> it still include ide/internal.h. Do you think it would make sense to >>> move AHCI into hw/ide? >> >> Both ahci and ide implement ata. I guess the best thing to do would be to >> completely refactor all ide code into ata and pata code, then add ahci >> (sata) to the game. Estimated working time: ~1 month. :) >> >> As I would rather have something working we can base on in the tree, so >> whoever volunteers for the refactoring (hint!) knows how to design the >> interfaces, I am not sure how much is reasonable within this patch set. > > I guess I have to read this as: You want to drop the code into the > repository, no matter what mess it creates, and leave the cleanup to > some volunteer that will never appear. So whoever is in the unfortunate > position of having to touch the IDE code afterwards will have the pain > because this series is doing only the half of what should be done. > > I'm sure that with a working time of only a few days the result could be > substantially improved, even if a month would be needed for perfection. > >> Moving the file to ide/ does sound like a good idea however. >> >>> >>> Then I believe that core.c is now a mixture of some generic ATA code >>> (that is also used by SATA) and the Legacy IDE code. SATA doesn't seem >>> to interact with the generic code through clean interfaces, but by >>> accessing internal data structures and calls to somewhere in the middle >>> of the existing IDE emultion. I think we should get a clean abstraction >>> there and have a clean split between SATA, PATA and common code, with >>> each of them sitting in its own file in hw/ide. >>> >>> I haven't reviewed the patches in detail but just had a quick look at >>> them, so my impressions might be wrong. If so, please correct me. >> >> No, you're completely right. We're in a chicken and egg situation. We don't >> have ahci, but the ide code is ugly. We would probably do a bad job at >> refactoring the ata code if we don't know which interfaces to design for. > > That problem is solved. You have posted patches, so you're aware what > interfaces you need for AHCI. This awareness doesn't come from putting > the code into git master. I guess you should go back and read the "this doesn't work yet" list. There is a lot of stuff that I'm not sure we have all correctly sorted out. The most intrusive one on that side is the legacy IDE compatibility. I don't know what interfaces and what changes we will need for that to become realistic. Also to catch up on Gerd's point - whatever refactoring we do, we will basically have to break migration. There is no way we can change all the internal state and structure and maintain binary compatibility with the old save states. Alex
Re: [Qemu-devel] Re: [PATCH 0/2] v8 Decouple block device removal from device removal
On Tue, 16 Nov 2010 15:01:12 +0100 Kevin Wolf wrote: > Am 16.11.2010 14:51, schrieb Luiz Capitulino: > > On Fri, 12 Nov 2010 18:38:57 +0100 > > Kevin Wolf wrote: > > > >> Am 12.11.2010 18:07, schrieb Ryan Harper: > >>> details, details, v8 > >>> > >>> This patch series decouples the detachment of a block device from the > >>> removal of the backing pci-device. Removal of a hotplugged pci device > >>> requires the guest to respond before qemu tears down the block device. > >>> In some cases, the guest may not respond leaving the guest with > >>> continued access to the block device. Mgmt layer doesn't have a > >>> reliable method to force a disconnect. > >>> > >>> The new monitor command, drive_del, will revoke a guests access to the > >>> block device independently of the removal of the pci device. > >>> > >>> The first patch implements drive_del, the second patch implements the > >>> qmp version of the monitor command. > >>> > >>> Changes since v7: > >>> - Fixed up doc strings (delete -> drive_del) > >>> Changes since v6: > >>> - Updated patch description > >>> - Dropped bdrv_unplug and inlined in drive_del > >>> - Explicitly invoke drive_uninit() > >>> Changes since v5: > >>> - Removed dangling pointers in guest and host state. This ensures things > >>> like > >>> info block no longer displays the deleted drive; though info pci will > >>> continue to display the pci device until the guest responds to the > >>> removal > >>> request. > >>> - Renamed drive_unplug -> drive_del > >>> Changes since v4: > >>> - Droppped drive_get_by_id patch and use bdrv_find() instead > >>> - Added additional details about drive_unplug to hmp/qmp interface > >>> > >>> Changes since v3: > >>> - Moved QMP command for drive_unplug() to separate patch > >>> > >>> Changes since v2: > >>> - Added QMP command for drive_unplug() > >>> > >>> Changes since v1: > >>> - CodingStyle fixes > >>> - Added qemu_aio_flush() to bdrv_unplug() > >>> > >>> Signed-off-by: Ryan Harper > >> > >> Thanks, applied both to the block branch. > > > > I guess the conclusion was that we don't want the new command > > in QMP? > > > > http://lists.gnu.org/archive/html/qemu-devel/2010-11/msg01084.html > > If you compare the time of these mails, Markus sent his mail only a few > minutes after I had applied the patches and posted this. Oh, didn't notice that. > Ryan split the patch in two parts only to allow dropping the QMP part if > we decided so, so I think he'll agree. I'm going to drop the second > patch from my queue again before I send a pull request. Ok, thanks.
[Qemu-devel] [PATCH] target-sparc: remove unused functions cpu_lock(), cpu_unlock()
---
target-sparc/cpu.h|2 --
target-sparc/helper.c | 14 --
2 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/target-sparc/cpu.h b/target-sparc/cpu.h
index 7e0d17c..3e93bbb 100644
--- a/target-sparc/cpu.h
+++ b/target-sparc/cpu.h
@@ -444,8 +444,6 @@ CPUSPARCState *cpu_sparc_init(const char *cpu_model);
void cpu_sparc_set_id(CPUSPARCState *env, unsigned int cpu);
void sparc_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt,
...));
-void cpu_lock(void);
-void cpu_unlock(void);
int cpu_sparc_handle_mmu_fault(CPUSPARCState *env1, target_ulong address, int
rw,
int mmu_idx, int is_softmmu);
#define cpu_handle_mmu_fault cpu_sparc_handle_mmu_fault
diff --git a/target-sparc/helper.c b/target-sparc/helper.c
index e84c312..7e45d7a 100644
--- a/target-sparc/helper.c
+++ b/target-sparc/helper.c
@@ -41,20 +41,6 @@ static int cpu_sparc_find_by_name(sparc_def_t *cpu_def,
const char *cpu_model);
/* Sparc MMU emulation */
-/* thread support */
-
-static spinlock_t global_cpu_lock = SPIN_LOCK_UNLOCKED;
-
-void cpu_lock(void)
-{
-spin_lock(&global_cpu_lock);
-}
-
-void cpu_unlock(void)
-{
-spin_unlock(&global_cpu_lock);
-}
-
#if defined(CONFIG_USER_ONLY)
int cpu_sparc_handle_mmu_fault(CPUState *env1, target_ulong address, int rw,
--
1.6.3.3
Re: [Qemu-devel] [PATCH 00/10] AHCI emulation support v2
Am 19.11.2010 14:08, schrieb Alexander Graf: > > On 19.11.2010, at 10:15, Kevin Wolf wrote: > >> Am 18.11.2010 19:43, schrieb Alexander Graf: Then I believe that core.c is now a mixture of some generic ATA code (that is also used by SATA) and the Legacy IDE code. SATA doesn't seem to interact with the generic code through clean interfaces, but by accessing internal data structures and calls to somewhere in the middle of the existing IDE emultion. I think we should get a clean abstraction there and have a clean split between SATA, PATA and common code, with each of them sitting in its own file in hw/ide. I haven't reviewed the patches in detail but just had a quick look at them, so my impressions might be wrong. If so, please correct me. >>> >>> No, you're completely right. We're in a chicken and egg situation. We don't >>> have ahci, but the ide code is ugly. We would probably do a bad job at >>> refactoring the ata code if we don't know which interfaces to design for. >> >> That problem is solved. You have posted patches, so you're aware what >> interfaces you need for AHCI. This awareness doesn't come from putting >> the code into git master. > > I guess you should go back and read the "this doesn't work yet" list. There > is a lot of stuff that I'm not sure we have all correctly sorted out. The > most intrusive one on that side is the legacy IDE compatibility. I don't know > what interfaces and what changes we will need for that to become realistic. Fair enough. I'll accept that we can't get it sorted out now, but let's try to do the part that we can do. Let's change the split to SATA (ahci.c), Legacy IDE (ide.c?), common code (ata.c) and "don't know yet" (core.c). A start for that would be if in Patch 2 you moved the function to ata.c instead of just reindenting. We're also probably pretty sure that, for example, the I/O port handling won't need to be shared and can be moved to ide.c. Whenever it becomes clear for a part in which category it belongs, we would move it out of core.c and eventually, I hope, core.c could be removed. > Also to catch up on Gerd's point - whatever refactoring we do, we will > basically have to break migration. There is no way we can change all the > internal state and structure and maintain binary compatibility with the old > save states. Hm, breaking migration isn't really an option. I'm not familiar with migration code, but maybe Juan can contribute some magic? Speaking of migration, that seems to be missing for the AHCI yet, too. Are you planning to complete the functionality first before you start with that? Kevin
[Qemu-devel] [Bug 427612] Re: kvm sends caps lock key up event twice
Sorry, Benjamin, I cut-pasted the wrong bit. When capslock is mapped to
control on the
host, then I get:
key press:
sdl_process_key({type=0x2,which=0x0,state=0x1,keysym={scancode=0x42,sym=0x132,mod=0x0,unicode=0x0}})
keycode = 0x3a
kbd_put_keycode(0x3a)
kbd_put_keycode(0xba)
key up:
sdl_process_key({type=0x3,which=0x0,state=0x0,keysym={scancode=0x42,sym=0x132,mod=0x0,unicode=0x0}})
keycode = 0x3a
kbd_put_keycode(0x3a)
kbd_put_keycode(0xba)
--
kvm sends caps lock key up event twice
https://bugs.launchpad.net/bugs/427612
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: Invalid
Status in “libsdl1.2” package in Ubuntu: Invalid
Status in “qemu-kvm” package in Ubuntu: New
Status in “libsdl1.2” package in Debian: Fix Released
Bug description:
Binary package hint: qemu-kvm
I have set the keyboard layout to German NEO 2 [1] in the host and the client
(both current karmic). The caps lock is used as modifier (similar to shift) in
NEO. When I press "caps lock" + "t", then the client prints a "t" instead of a
"-". A caps lock key up event is sent to the client before I release the caps
lock key.
[1] http://www.neo-layout.org/
ProblemType: Bug
Architecture: amd64
Date: Fri Sep 11 01:38:58 2009
DistroRelease: Ubuntu 9.10
KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1:
UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD
Package: qemu-kvm 0.11.0~rc2-0ubuntu2
PccardctlIdent:
PccardctlStatus:
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic
root=UUID=37b01f5a-a578-49d6-a812-f166b103e68a ro quiet splash
ProcEnviron:
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.31-generic
SourcePackage: qemu-kvm
Uname: Linux 2.6.31-10-generic x86_64
dmi.bios.date: 07/15/2009
dmi.bios.vendor: Intel Corp.
dmi.bios.version: DPP3510J.86A.0572.2009.0715.2346
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DG33TL
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD89517-802
dmi.chassis.type: 3
dmi.modalias:
dmi:bvnIntelCorp.:bvrDPP3510J.86A.0572.2009.0715.2346:bd07/15/2009:svn:pn:pvr:rvnIntelCorporation:rnDG33TL:rvrAAD89517-802:cvn:ct3:cvr:
Re: [Qemu-devel] [PATCH 16/16] megasas: LSI Megaraid SAS emulation
Jes Sorensen writes: > On 11/18/10 15:47, Hannes Reinecke wrote: >> This patch adds an emulation for the LSI Megaraid SAS HBA. >> >> Signed-off-by: Hannes Reinecke >> --- >> Makefile.objs |2 +- >> hw/megasas.c | 1826 >> + >> hw/mfi.h | 1197 + >> hw/pci_ids.h |2 + >> hw/scsi.h |1 + >> 5 files changed, 3027 insertions(+), 1 deletions(-) >> create mode 100644 hw/megasas.c >> create mode 100644 hw/mfi.h >> >> diff --git a/Makefile.objs b/Makefile.objs >> index 15569af..54c6e02 100644 >> --- a/Makefile.objs >> +++ b/Makefile.objs >> @@ -231,7 +231,7 @@ hw-obj-$(CONFIG_IDE_MACIO) += ide/macio.o >> hw-obj-$(CONFIG_IDE_VIA) += ide/via.o >> >> # SCSI layer >> -hw-obj-y += lsi53c895a.o >> +hw-obj-y += lsi53c895a.o megasas.o >> hw-obj-$(CONFIG_ESP) += esp.o >> >> hw-obj-y += dma-helpers.o sysbus.o isa-bus.o > > Just had a look through your patches and have to say nice work. Haven't > tested it though, but looks like a good step in the right direction. > > Only comment, as you are adding another SCSI driver, maybe it's time to > make the driver selection configurable, rather than hard coding the build? What do you mean by that? We hardcode lsi53c895a in two places where we really mean "default SCSI controller type": pc_pci_device_init(), which applies to "-drive if=scsi", and qemu_pci_hot_add_storage(), which applies to "pci_add storage if=scsi". Not sure making that default configurable is worth it. If you want more control than -drive and pci_add provice, use -device and device_add.
Re: [Qemu-devel] [PATCH 16/16] megasas: LSI Megaraid SAS emulation
On 11/19/2010 03:06 PM, Markus Armbruster wrote: > Jes Sorensen writes: > >> On 11/18/10 15:47, Hannes Reinecke wrote: >>> This patch adds an emulation for the LSI Megaraid SAS HBA. >>> >>> Signed-off-by: Hannes Reinecke >>> --- >>> Makefile.objs |2 +- >>> hw/megasas.c | 1826 >>> + >>> hw/mfi.h | 1197 + >>> hw/pci_ids.h |2 + >>> hw/scsi.h |1 + >>> 5 files changed, 3027 insertions(+), 1 deletions(-) >>> create mode 100644 hw/megasas.c >>> create mode 100644 hw/mfi.h >>> >>> diff --git a/Makefile.objs b/Makefile.objs >>> index 15569af..54c6e02 100644 >>> --- a/Makefile.objs >>> +++ b/Makefile.objs >>> @@ -231,7 +231,7 @@ hw-obj-$(CONFIG_IDE_MACIO) += ide/macio.o >>> hw-obj-$(CONFIG_IDE_VIA) += ide/via.o >>> >>> # SCSI layer >>> -hw-obj-y += lsi53c895a.o >>> +hw-obj-y += lsi53c895a.o megasas.o >>> hw-obj-$(CONFIG_ESP) += esp.o >>> >>> hw-obj-y += dma-helpers.o sysbus.o isa-bus.o >> >> Just had a look through your patches and have to say nice work. Haven't >> tested it though, but looks like a good step in the right direction. >> >> Only comment, as you are adding another SCSI driver, maybe it's time to >> make the driver selection configurable, rather than hard coding the build? > > What do you mean by that? > > We hardcode lsi53c895a in two places where we really mean "default SCSI > controller type": pc_pci_device_init(), which applies to "-drive > if=scsi", and qemu_pci_hot_add_storage(), which applies to "pci_add > storage if=scsi". Not sure making that default configurable is worth > it. > > If you want more control than -drive and pci_add provice, use -device > and device_add. Idea is probably to have megasas the default SCSI controller, if configured during compile time. Basically have a configure option '--scsi-hba=megasas' or somesuch. But then, you can 'easily' select the megasas HBA nowadays with -drive file=XXX,if=none,id=d1 \ -device megasas,id=m1 \ -device scsi-disk,drive=d1 So not sure if it's worthwhile. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH 16/16] megasas: LSI Megaraid SAS emulation
On 11/19/10 15:06, Markus Armbruster wrote: >> Only comment, as you are adding another SCSI driver, maybe it's time to >> make the driver selection configurable, rather than hard coding the build? > > What do you mean by that? > > We hardcode lsi53c895a in two places where we really mean "default SCSI > controller type": pc_pci_device_init(), which applies to "-drive > if=scsi", and qemu_pci_hot_add_storage(), which applies to "pci_add > storage if=scsi". Not sure making that default configurable is worth > it. > > If you want more control than -drive and pci_add provice, use -device > and device_add. What I mean is for most other device types we allow to specify a list of wanted devices at the configure line, which is what I am suggesting we added support for for SCSI as well. Cheers, Jes
Re: [Qemu-devel] [PATCH 00/10] AHCI emulation support v2
Hi, Also to catch up on Gerd's point - whatever refactoring we do, we will basically have to break migration. There is no way we can change all the internal state and structure and maintain binary compatibility with the old save states. On the other hand it would be a *real* pity to drag the ide migration mess into ahci ... Ideally each ide-drive should save its state itself, and likewise each ide/ahci controller. Maybe it would be a good first step to move to such a model in the savevm data format, but keep the current ide data structures for a while so we can easily accept migrations in the old savevm format for the time being. Then a relase or two away from today we'll drop support for the old ide savevm format, so we can finally tranform the ide data structures to something sane? Juan? Comments? cheers, Gerd
[Qemu-devel] [PATCH] target-arm: remove unused functions cpu_lock(), cpu_unlock()
---
target-arm/cpu.h |2 --
target-arm/op_helper.c | 14 --
2 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index b87c605..0284bad 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -227,8 +227,6 @@ int cpu_arm_handle_mmu_fault (CPUARMState *env,
target_ulong address, int rw,
int mmu_idx, int is_softmuu);
#define cpu_handle_mmu_fault cpu_arm_handle_mmu_fault
-void cpu_lock(void);
-void cpu_unlock(void);
static inline void cpu_set_tls(CPUARMState *env, target_ulong newtls)
{
env->cp15.c13_tls2 = newtls;
diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
index 9b1a014..43baa63 100644
--- a/target-arm/op_helper.c
+++ b/target-arm/op_helper.c
@@ -28,20 +28,6 @@ void raise_exception(int tt)
cpu_loop_exit();
}
-/* thread support */
-
-static spinlock_t global_cpu_lock = SPIN_LOCK_UNLOCKED;
-
-void cpu_lock(void)
-{
-spin_lock(&global_cpu_lock);
-}
-
-void cpu_unlock(void)
-{
-spin_unlock(&global_cpu_lock);
-}
-
uint32_t HELPER(neon_tbl)(uint32_t ireg, uint32_t def,
uint32_t rn, uint32_t maxindex)
{
--
1.6.3.3
[Qemu-devel] [PATCH] ARM: enable XScale/iWMMXT in linux-user mode
In linux-user mode, the XScale/iWMMXT coprocessors must be enabled
at reset so that we can run code that uses these instructions.
Signed-off-by: Peter Maydell
---
target-arm/helper.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 996d40d..94aef39 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -203,7 +203,13 @@ void cpu_reset(CPUARMState *env)
cpu_reset_model_id(env, id);
#if defined (CONFIG_USER_ONLY)
env->uncached_cpsr = ARM_CPU_MODE_USR;
+/* For user mode we must enable access to coprocessors */
env->vfp.xregs[ARM_VFP_FPEXC] = 1 << 30;
+if (arm_feature(env, ARM_FEATURE_IWMMXT)) {
+env->cp15.c15_cpar = 3;
+} else if (arm_feature(env, ARM_FEATURE_XSCALE)) {
+env->cp15.c15_cpar = 1;
+}
#else
/* SVC mode with interrupts disabled. */
env->uncached_cpsr = ARM_CPU_MODE_SVC | CPSR_A | CPSR_F | CPSR_I;
--
1.6.3.3
Re: [Qemu-devel] [PATCH] ARM: enable XScale/iWMMXT in linux-user mode
On 19 November 2010 15:36, Peter Maydell wrote: > In linux-user mode, the XScale/iWMMXT coprocessors must be enabled > at reset so that we can run code that uses these instructions. > > Signed-off-by: Peter Maydell This patch fixes the same issue as this patch submitted by Lars Munch back in May: http://patchwork.ozlabs.org/patch/51970/ but I preferred to put the enabling of the XScale coprocessors in the same part of the code as the existing enabling of the VFP for linux-user mode. -- PMM
[Qemu-devel] [PATCH]target-arm: fix semihosting commandline handling
The ARM semihosting commandline handling does not work -- please see
details in bug report 673613,
https://bugs.launchpad.net/qemu/+bug/673613 .
The following patch, suggested by Peter Maydell, fixes the problem. I
have tested the patch on the latest development tree, on which it works
(after one unrelated fix).
Best regards,
- Wolfgang Schildbach
---
diff --git a/arm-semi.c b/arm-semi.c
index 0687b03..53b40e4 100644
--- a/arm-semi.c
+++ b/arm-semi.c
@@ -373,45 +373,48 @@ uint32_t do_arm_semihosting(CPUState *env)
#ifdef CONFIG_USER_ONLY
/* Build a commandline from the original argv. */
{
-char **arg = ts->info->host_argv;
-int len = ARG(1);
-/* lock the buffer on the ARM side */
-char *cmdline_buffer = (char*)lock_user(VERIFY_WRITE,
ARG(0), len, 0);
+int i ;
-if (!cmdline_buffer)
-/* FIXME - should this error code be -TARGET_EFAULT ?
*/
-return (uint32_t)-1;
+char *arm_cmdline_buffer ;
+const char *host_cmdline_buffer ;
-s = cmdline_buffer;
-while (*arg && len > 2) {
-int n = strlen(*arg);
+int arm_cmdline_len = ARG(1) ;
+int host_cmdline_len =
ts->info->arg_end-ts->info->arg_start ;
-if (s != cmdline_buffer) {
-*(s++) = ' ';
-len--;
-}
-if (n >= len)
-n = len - 1;
-memcpy(s, *arg, n);
-s += n;
-len -= n;
-arg++;
-}
-/* Null terminate the string. */
-*s = 0;
-len = s - cmdline_buffer;
+if (host_cmdline_len > arm_cmdline_len)
+return (uint32_t)-1; /* command line too long */
+
+/* lock the buffers on the ARM side */
+arm_cmdline_buffer = (char*)lock_user(VERIFY_WRITE, ARG(0),
host_cmdline_len, 0);
+host_cmdline_buffer = (const char*)lock_user(PAGE_READ,
ts->info->arg_start, host_cmdline_len, 0);
-/* Unlock the buffer on the ARM side. */
-unlock_user(cmdline_buffer, ARG(0), len);
+if (arm_cmdline_buffer && host_cmdline_buffer)
+{
-/* Adjust the commandline length argument. */
-SET_ARG(1, len);
+/* the last argument is zero-terminated;
+ no need for additional termination */
+memcpy(arm_cmdline_buffer, host_cmdline_buffer,
host_cmdline_len);
-/* Return success if commandline fit into buffer. */
-return *arg ? -1 : 0;
+/* separate arguments by white spaces */
+for (i = 0; i < host_cmdline_len-1; i++) {
+if (arm_cmdline_buffer[i] == 0) {
+arm_cmdline_buffer[i] = ' ';
+}
+}
+
+/* Adjust the commandline length argument. */
+SET_ARG(1, host_cmdline_len);
+}
+
+/* Unlock the buffers on the ARM side. */
+unlock_user(arm_cmdline_buffer, ARG(0), host_cmdline_len);
+unlock_user((void*)host_cmdline_buffer,
ts->info->arg_start, host_cmdline_len);
+
+/* Return success if we could return a commandline. */
+return (arm_cmdline_buffer && host_cmdline_buffer) ? 0 :
-1;
}
#else
- return -1;
+return -1;
#endif
case SYS_HEAPINFO:
{
diff --git a/bsd-user/bsdload.c b/bsd-user/bsdload.c
index 14a93bf..6d9bb6f 100644
--- a/bsd-user/bsdload.c
+++ b/bsd-user/bsdload.c
@@ -176,8 +176,6 @@ int loader_exec(const char * filename, char ** argv,
char ** envp,
retval = prepare_binprm(&bprm);
-infop->host_argv = argv;
-
if(retval>=0) {
if (bprm.buf[0] == 0x7f
&& bprm.buf[1] == 'E'
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 9763616..e343894 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -50,7 +50,6 @@ struct image_info {
abi_ulong entry;
abi_ulong code_offset;
abi_ulong data_offset;
-char **host_argv;
int personality;
};
diff --git a/linux-user/linuxload.c b/linux-user/linuxload.c
index 9ee27c3..ac8c486 100644
--- a/linux-user/linuxload.c
+++ b/linux-user/linuxload.c
@@ -174,8 +174,6 @@ int loader_exec(const char * filename, char ** argv,
char ** envp,
retval = prepare_binprm(bprm);
-infop->host_argv = argv;
-
if(retval>=0) {
if (bprm->buf[0] == 0x7f
&& bprm->buf[1] == 'E'
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index 708021e..8f0a81f 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -50,7 +50,6 @@ struct image_info {
abi_ulong saved_auxv;
abi_ulong arg_start;
abi_ulong arg_end;
-char**host_argv;
int personali
Re: [Qemu-devel] [PATCH 16/16] megasas: LSI Megaraid SAS emulation
On 19.11.2010, at 15:31, Jes Sorensen wrote: > On 11/19/10 15:06, Markus Armbruster wrote: >>> Only comment, as you are adding another SCSI driver, maybe it's time to >>> make the driver selection configurable, rather than hard coding the build? >> >> What do you mean by that? >> >> We hardcode lsi53c895a in two places where we really mean "default SCSI >> controller type": pc_pci_device_init(), which applies to "-drive >> if=scsi", and qemu_pci_hot_add_storage(), which applies to "pci_add >> storage if=scsi". Not sure making that default configurable is worth >> it. >> >> If you want more control than -drive and pci_add provice, use -device >> and device_add. > > What I mean is for most other device types we allow to specify a list of > wanted devices at the configure line, which is what I am suggesting we > added support for for SCSI as well. Oh, you mean something like: hw-obj-$(CONFIG_MEGASAS) += megasas.o with respective entries in default-config/*? Yeah, makes sense. Alex
[Qemu-devel] [PATCH 1/1] NBD isn't used by qemu-img, so don't link qemu-img against NBD objects
From: Jes Sorensen Signed-off-by: Jes Sorensen --- Makefile |2 +- Makefile.objs | 12 ++-- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 747e47c..a503c1c 100644 --- a/Makefile +++ b/Makefile @@ -154,7 +154,7 @@ qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o: $(GENERATED_HEADERS) qemu-img$(EXESUF): qemu-img.o qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o -qemu-nbd$(EXESUF): qemu-nbd.o qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o +qemu-nbd$(EXESUF): qemu-nbd.o qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(nbd-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o qemu-io$(EXESUF): qemu-io.o cmd.o qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o diff --git a/Makefile.objs b/Makefile.objs index 23b17ce..5120e88 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -14,13 +14,13 @@ oslib-obj-$(CONFIG_POSIX) += oslib-posix.o # block-obj-y is code used by both qemu system emulation and qemu-img block-obj-y = cutils.o cache-utils.o qemu-malloc.o qemu-option.o module.o -block-obj-y += nbd.o block.o aio.o aes.o qemu-config.o +block-obj-y += block.o aio.o aes.o qemu-config.o block-obj-$(CONFIG_POSIX) += posix-aio-compat.o block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o vvfat.o block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o -block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o +block-nested-y += parallels.o blkdebug.o sheepdog.o blkverify.o block-nested-$(CONFIG_WIN32) += raw-win32.o block-nested-$(CONFIG_POSIX) += raw-posix.o block-nested-$(CONFIG_CURL) += curl.o @@ -45,6 +45,13 @@ net-obj-y += $(addprefix net/, $(net-nested-y)) fsdev-nested-$(CONFIG_VIRTFS) = qemu-fsdev.o fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) +### +# nbd-obj-y is code used by both qemu and qemu-nbd + +nbd-obj-y = nbd.o +nbd-nested-y = nbd.o +nbd-obj-y += $(addprefix block/, $(nbd-nested-y)) + ## # libqemu_common.a: Target independent part of system emulation. The # long term path is to suppress *all* target specific code in case of @@ -53,6 +60,7 @@ fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) common-obj-y = $(block-obj-y) blockdev.o common-obj-y += $(net-obj-y) +common-obj-y += $(nbd-obj-y) common-obj-y += $(qobject-obj-y) common-obj-$(CONFIG_LINUX) += $(fsdev-obj-$(CONFIG_LINUX)) common-obj-y += readline.o console.o cursor.o async.o qemu-error.o -- 1.7.3.2
RE: [Qemu-devel] [PATCH]target-arm: fix semihosting commandline handling
Oops. Being new to git, I now realize this patch is not what I have in
my source tree. Please disregard the previous post, I will re-post with
the proper patch. Sorry for the noise...
- Wolfgang Schildbach
From: qemu-devel-bounces+wschi=dolby@nongnu.org
[mailto:qemu-devel-bounces+wschi=dolby@nongnu.org] On Behalf Of
Schildbach, Wolfgang
Sent: Friday, November 19, 2010 5:22 PM
To: qemu-devel@nongnu.org
Cc: peter.mayd...@linaro.org
Subject: [Qemu-devel] [PATCH]target-arm: fix semihosting commandline
handling
The ARM semihosting commandline handling does not work -- please see
details in bug report 673613,
https://bugs.launchpad.net/qemu/+bug/673613 .
The following patch, suggested by Peter Maydell, fixes the problem. I
have tested the patch on the latest development tree, on which it works
(after one unrelated fix).
Best regards,
- Wolfgang Schildbach
---
diff --git a/arm-semi.c b/arm-semi.c
index 0687b03..53b40e4 100644
--- a/arm-semi.c
+++ b/arm-semi.c
@@ -373,45 +373,48 @@ uint32_t do_arm_semihosting(CPUState *env)
#ifdef CONFIG_USER_ONLY
/* Build a commandline from the original argv. */
{
-char **arg = ts->info->host_argv;
-int len = ARG(1);
-/* lock the buffer on the ARM side */
-char *cmdline_buffer = (char*)lock_user(VERIFY_WRITE,
ARG(0), len, 0);
+int i ;
-if (!cmdline_buffer)
-/* FIXME - should this error code be -TARGET_EFAULT ?
*/
-return (uint32_t)-1;
+char *arm_cmdline_buffer ;
+const char *host_cmdline_buffer ;
-s = cmdline_buffer;
-while (*arg && len > 2) {
-int n = strlen(*arg);
+int arm_cmdline_len = ARG(1) ;
+int host_cmdline_len =
ts->info->arg_end-ts->info->arg_start ;
-if (s != cmdline_buffer) {
-*(s++) = ' ';
-len--;
-}
-if (n >= len)
-n = len - 1;
-memcpy(s, *arg, n);
-s += n;
-len -= n;
-arg++;
-}
-/* Null terminate the string. */
-*s = 0;
-len = s - cmdline_buffer;
+if (host_cmdline_len > arm_cmdline_len)
+return (uint32_t)-1; /* command line too long */
+
+/* lock the buffers on the ARM side */
+arm_cmdline_buffer = (char*)lock_user(VERIFY_WRITE, ARG(0),
host_cmdline_len, 0);
+host_cmdline_buffer = (const char*)lock_user(PAGE_READ,
ts->info->arg_start, host_cmdline_len, 0);
-/* Unlock the buffer on the ARM side. */
-unlock_user(cmdline_buffer, ARG(0), len);
+if (arm_cmdline_buffer && host_cmdline_buffer)
+{
-/* Adjust the commandline length argument. */
-SET_ARG(1, len);
+/* the last argument is zero-terminated;
+ no need for additional termination */
+memcpy(arm_cmdline_buffer, host_cmdline_buffer,
host_cmdline_len);
-/* Return success if commandline fit into buffer. */
-return *arg ? -1 : 0;
+/* separate arguments by white spaces */
+for (i = 0; i < host_cmdline_len-1; i++) {
+if (arm_cmdline_buffer[i] == 0) {
+arm_cmdline_buffer[i] = ' ';
+}
+}
+
+/* Adjust the commandline length argument. */
+SET_ARG(1, host_cmdline_len);
+}
+
+/* Unlock the buffers on the ARM side. */
+unlock_user(arm_cmdline_buffer, ARG(0), host_cmdline_len);
+unlock_user((void*)host_cmdline_buffer,
ts->info->arg_start, host_cmdline_len);
+
+/* Return success if we could return a commandline. */
+return (arm_cmdline_buffer && host_cmdline_buffer) ? 0 :
-1;
}
#else
- return -1;
+return -1;
#endif
case SYS_HEAPINFO:
{
diff --git a/bsd-user/bsdload.c b/bsd-user/bsdload.c
index 14a93bf..6d9bb6f 100644
--- a/bsd-user/bsdload.c
+++ b/bsd-user/bsdload.c
@@ -176,8 +176,6 @@ int loader_exec(const char * filename, char ** argv,
char ** envp,
retval = prepare_binprm(&bprm);
-infop->host_argv = argv;
-
if(retval>=0) {
if (bprm.buf[0] == 0x7f
&& bprm.buf[1] == 'E'
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 9763616..e343894 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -50,7 +50,6 @@ struct image_info {
abi_ulong entry;
abi_ulong code_offset;
abi_ulong data_offset;
-char **host_argv;
int personality;
};
diff --git a/linux-user/linuxload.c b/linux-user/linuxload.c
index 9ee27c3..ac8c486 100644
--- a/linux-user/linuxload.c
+++ b/linux-user/linuxload.c
@@ -174,8 +174,6 @@
Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device
"Michael S. Tsirkin" writes: > On Tue, Nov 09, 2010 at 11:41:43AM +0900, Isaku Yamahata wrote: >> On Mon, Nov 08, 2010 at 06:26:33PM +0200, Michael S. Tsirkin wrote: >> > Replace bus number with slot numbers of parent bridges up to the root. >> > This works for root bridge in a compatible way because bus number there >> > is hard-coded to 0. >> > IMO nested bridges are broken anyway, no way to be compatible there. >> > >> > >> > Gleb, Markus, I think the following should be sufficient for PCI. What >> > do you think? Also - do we need to update QMP/monitor to teach them to >> > work with these paths? >> > >> > This is on top of Alex's patch, completely untested. >> > >> > >> > pci: fix device path for devices behind nested bridges >> > >> > We were using bus number in the device path, which is clearly >> > broken as this number is guest-assigned for all devices >> > except the root. >> > >> > Fix by using hierarchical list of slots, walking the path >> > from root down to device, instead. Add :00 as bus number >> > so that if there are no nested bridges, this is compatible >> > with what we have now. >> >> This format, Domain:00:Slot:Slot:Slot.Function, doesn't work >> because pci-to-pci bridge is pci function. >> So the format should be >> Domain:00:Slot.Function:Slot.Function:Slot.Function >> >> thanks, > > Hmm, interesting. If we do this we aren't backwards compatible > though, so maybe we could try using openfirmware paths, just as well. Whatever we do, we need to make it work for all (qdevified) devices and buses. It should also be possible to use canonical addressing with device_add & friends. I.e. permit naming a device by (a unique abbreviation of) its canonical address in addition to naming it by its user-defined ID. For instance, something like device_del /pci/@1,1 in addition to device_del ID Open Firmware is a useful source of inspiration there, but should it come into conflict with usability, we should let usability win.
[Qemu-devel] Re: [PATCH v9 3/8] pci: clean up of pci status register
On Tue, Nov 16, 2010 at 05:26:07PM +0900, Isaku Yamahata wrote:
> This patch refine the initialization/reset of
> pci status registers.
>
> Signed-off-by: Isaku Yamahata
This one seems good. Applied with some tweaks: I cut down the comment:
we don't really need to repeat what code does IMO, rather why it does
it, and clarified the comment text. Also split init_w1c out to a
function so that each function does one thing.
> ---
> hw/pci.c | 41 +++--
> 1 files changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/hw/pci.c b/hw/pci.c
> index 52fe655..fba765b 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -145,6 +145,9 @@ static void pci_device_reset(PCIDevice *dev)
> pci_word_test_and_clear_mask(dev->config + PCI_COMMAND,
> pci_get_word(dev->wmask + PCI_COMMAND) |
> pci_get_word(dev->w1cmask + PCI_COMMAND));
> +pci_word_test_and_clear_mask(dev->config + PCI_STATUS,
> + pci_get_word(dev->wmask + PCI_STATUS) |
> + pci_get_word(dev->w1cmask + PCI_STATUS));
> dev->config[PCI_CACHE_LINE_SIZE] = 0x0;
> dev->config[PCI_INTERRUPT_LINE] = 0x0;
> for (r = 0; r < PCI_NUM_REGIONS; ++r) {
> @@ -540,7 +543,7 @@ static void pci_init_cmask(PCIDevice *dev)
> dev->cmask[PCI_CAPABILITY_LIST] = 0xff;
> }
>
> -static void pci_init_wmask(PCIDevice *dev)
> +static void pci_init_wmask_w1cmask(PCIDevice *dev)
> {
> int config_size = pci_config_size(dev);
>
> @@ -595,6 +598,40 @@ static void pci_init_wmask(PCIDevice *dev)
> PCI_COMMAND_MASTER | PCI_COMMAND_PARITY | PCI_COMMAND_SERR |
> PCI_COMMAND_INTX_DISABLE);
>
> +/*
> + * bit 0-2: reserved
> + * bit 3: PCI_STATUS_INTERRUPT: RO
> + * bit 4: PCI_STATUS_CAP_LIST: RO
> + * bit 5: PCI_STATUS_66MHZ: RO
> + * bit 6: PCI_STATUS_UDF: reserved (PCI 2.2-)
> + * bit 7: PCI_STATUS_FAST_BACK: RO
> + * bit 8: PCI_STATUS_PARITY
> + *type 0: RW for bus master
> + *type 1: RW1C
> + * bit 9-10: PCI_STATUS_DEVSEL: RO
> + * bit 11: PCI_STATUS_SIG_TARGET_ABORT
> + * type 0: RW1C for targets that is capable of terminating
> + * a transaction.
> + * type 1: RW1C
> + * bit 12: PCI_STATUS_REC_TARGET_ABORT
> + * type 0: RW1C for masters
> + * type 1: RW1C
> + * bit 13: PCI_STATUS_REC_MASTER_ABORT
> + * type 0: RW1C for masters
> + * type 1: RW1C
> + * bit 14: PCI_STATUS_SIG_SYSTEM_ERROR
> + * type 0: RW1C with execptions
> + * type 1: RW1C
> + * bit : PCI_STATUS_DETECTED_PARITY: RW1C
> + *
> + * It's okay to set w1mask even for RO=0(i.e. reserved) because
> + * writing value 1 to w1c bit whose value is 0 has no effect.
> + */
> +pci_set_word(dev->w1cmask + PCI_STATUS,
> + PCI_STATUS_PARITY | PCI_STATUS_SIG_TARGET_ABORT |
> + PCI_STATUS_REC_TARGET_ABORT | PCI_STATUS_REC_MASTER_ABORT |
> + PCI_STATUS_SIG_SYSTEM_ERROR | PCI_STATUS_DETECTED_PARITY);
> +
> memset(dev->wmask + PCI_CONFIG_HEADER_SIZE, 0xff,
> config_size - PCI_CONFIG_HEADER_SIZE);
> }
> @@ -725,7 +762,7 @@ static PCIDevice *do_pci_register_device(PCIDevice
> *pci_dev, PCIBus *bus,
> pci_set_default_subsystem_id(pci_dev);
> }
> pci_init_cmask(pci_dev);
> -pci_init_wmask(pci_dev);
> +pci_init_wmask_w1cmask(pci_dev);
> if (is_bridge) {
> pci_init_wmask_bridge(pci_dev);
> }
> --
> 1.7.1.1
Re: [Qemu-devel] [PATCH 16/16] megasas: LSI Megaraid SAS emulation
On 11/19/10 17:36, Alexander Graf wrote: > > On 19.11.2010, at 15:31, Jes Sorensen wrote: >> What I mean is for most other device types we allow to specify a list of >> wanted devices at the configure line, which is what I am suggesting we >> added support for for SCSI as well. > > Oh, you mean something like: > > hw-obj-$(CONFIG_MEGASAS) += megasas.o > > with respective entries in default-config/*? Yeah, makes sense. Correct, and I suggest we add that for the 53c895 driver too. Cheers, Jes
[Qemu-devel] [Bug 668799] Re: qemu-arm segfaults executing msgmerge (gettext)
The following patch stops the segfault (which happens because cpu_unlink_tb() is fiddling with the links between tbs without taking the tb_lock, so another thread can come in via eg tb_add_jump() and cause corruption of the linked lists). However, there are a number of comments in the TB handling code about things being non-thread-safe or not SMP safe, so I need to have a more careful think about the whole thing. diff --git a/exec.c b/exec.c index db9ff55..5f4a50b 100644 --- a/exec.c +++ b/exec.c @@ -1606,9 +1606,8 @@ static void cpu_unlink_tb(CPUState *env) emulation this often isn't actually as bad as it sounds. Often signals are used primarily to interrupt blocking syscalls. */ TranslationBlock *tb; -static spinlock_t interrupt_lock = SPIN_LOCK_UNLOCKED; -spin_lock(&interrupt_lock); +spin_lock(&tb_lock); tb = env->current_tb; /* if the cpu is currently executing code, we must unlink it and all the potentially executing TB */ @@ -1616,7 +1615,7 @@ static void cpu_unlink_tb(CPUState *env) env->current_tb = NULL; tb_reset_jump_recursive(tb); } -spin_unlock(&interrupt_lock); +spin_unlock(&tb_lock); } /* mask must never be zero, except for A20 change call */ -- qemu-arm segfaults executing msgmerge (gettext) https://bugs.launchpad.net/bugs/668799 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: upstream qemu.git revision b45e9c05dbacba8e992f0bffeca04c6379c3ad45 Starting program: /usr/bin/qemu-arm msgmerge-static ar.po anjuta.pot [Thread debugging using libthread_db enabled] [New Thread 0x74bc3ff0 (LWP 26108)] [New Thread 0x74b8aff0 (LWP 26109)] [New Thread 0x74b51ff0 (LWP 26110)] [New Thread 0x74b18ff0 (LWP 26111)] [New Thread 0x74adfff0 (LWP 26112)] [New Thread 0x74aa6ff0 (LWP 26113)] [New Thread 0x74a6dff0 (LWP 26114)] [New Thread 0x74a34ff0 (LWP 26115)] [New Thread 0x749fbff0 (LWP 26116)] [New Thread 0x749c2ff0 (LWP 26117)] [New Thread 0x74989ff0 (LWP 26118)] [New Thread 0x74950ff0 (LWP 26119)] [New Thread 0x74917ff0 (LWP 26120)] [New Thread 0x748deff0 (LWP 26121)] [New Thread 0x748a5ff0 (LWP 26122)] [New Thread 0x7486cff0 (LWP 26123)] [New Thread 0x74833ff0 (LWP 26124)] [New Thread 0x747faff0 (LWP 26125)] [New Thread 0x747c1ff0 (LWP 26126)] [New Thread 0x74788ff0 (LWP 26127)] [New Thread 0x7474fff0 (LWP 26128)] [New Thread 0x74716ff0 (LWP 26129)] [New Thread 0x746ddff0 (LWP 26130)] . Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x74aa6ff0 (LWP 26113)] 0x600480d4 in tb_reset_jump_recursive2 (tb=0x74c63540, n=0) at /home/user/git/qemu/exec.c:1333 1333tb1 = tb1->jmp_next[n1]; (gdb) bt #0 0x600480d4 in tb_reset_jump_recursive2 (tb=0x74c63540, n=0) at /home/user/git/qemu/exec.c:1333 #1 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63540) at /home/user/git/qemu/exec.c:1361 #2 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c634d8, n=0) at /home/user/git/qemu/exec.c:1355 #3 0x600481c0 in tb_reset_jump_recursive (tb=0x74c634d8) at /home/user/git/qemu/exec.c:1361 #4 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63470, n=0) at /home/user/git/qemu/exec.c:1355 #5 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63470) at /home/user/git/qemu/exec.c:1361 #6 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63408, n=1) at /home/user/git/qemu/exec.c:1355 #7 0x600481d1 in tb_reset_jump_recursive (tb=0x74c63408) at /home/user/git/qemu/exec.c:1362 #8 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c633a0, n=0) at /home/user/git/qemu/exec.c:1355 #9 0x600481c0 in tb_reset_jump_recursive (tb=0x74c633a0) at /home/user/git/qemu/exec.c:1361 #10 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63338, n=0) at /home/user/git/qemu/exec.c:1355 #11 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63338) at /home/user/git/qemu/exec.c:1361 #12 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c632d0, n=0) at /home/user/git/qemu/exec.c:1355 ---Type to continue, or q to quit--- #13 0x600481c0 in tb_reset_jump_recursive (tb=0x74c632d0) at /home/user/git/qemu/exec.c:1361 #14 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63268, n=1) at /home/user/git/qemu/exec.c:1355 #15 0x600481d1 in tb_reset_jump_recursive (tb=0x74c63268) at /home/user/git/qemu/exec.c:1362 #16 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63200, n=0) at /home/user/git/qemu/exec.c:1355 #17 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63200) at /home/user/git/qemu/exec.c:1361 #18 0x600487c5 in cpu_unlink_tb
Re: [Qemu-devel] [PATCH 10/16] scsi: Use 'SCSIRequest' directly
On Thu, Nov 18, 2010 at 03:47:28PM +0100, Hannes Reinecke wrote: > > Rather than to access a SCSIRequest via an abstract 'tag' we can > as well use it directly and save us the lookup. The get_put/buf methods are a bit misnamed. get/put generally implies refcounting while they are simple alloc/free routines. I'd suggest renaming them to alloc_buf/free_buf. Otherwise the patch looks very good to me.
Re: [Qemu-devel] [PATCH 02/16] scsi: Increase the number of possible devices
On Thu, Nov 18, 2010 at 03:46:25PM +0100, Hannes Reinecke wrote: > > The SCSI parallel interface has a limite of 8 devices, but > not the SCSI stack in general. So we should be removing the > hard-coded limit and use MAX_SCSI_DEVS instead. > And we only need to scan those devices which are allocated > by the bus. Looks good.
Re: [Qemu-devel] [PATCH 01/16] Allow zero alloc_hint in qemu_sglist_init()
On Thu, Nov 18, 2010 at 03:44:34PM +0100, Hannes Reinecke wrote: > > qemu_malloc doesn't check for zero argument, so we need to > check ourselves. I'm not sure if it's a that good idea to remove the implicit ->sg != NULL assumption. Any reason you can't simply call qemu_sglist_init later?
[Qemu-devel] [PATCH] pci: Replace unneeded type casts in calls of pci_register_bar
There is no need for these type casts (as other existing
code shows). So re-write the first argument without
type cast (and remove a related TODO comment).
Cc: Michael S. Tsirkin
Signed-off-by: Stefan Weil
---
hw/cirrus_vga.c |4 ++--
hw/e1000.c |4 ++--
hw/ide/via.c|2 +-
hw/lsi53c895a.c |7 +++
hw/openpic.c|2 +-
hw/usb-ohci.c |2 +-
6 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index aadc56f..40be55d 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3204,10 +3204,10 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
/* memory #0 LFB */
/* memory #1 memory-mapped I/O */
/* XXX: s->vga.vram_size must be a power of two */
- pci_register_bar((PCIDevice *)d, 0, 0x200,
+ pci_register_bar(&d->dev, 0, 0x200,
PCI_BASE_ADDRESS_MEM_PREFETCH, cirrus_pci_lfb_map);
if (device_id == CIRRUS_ID_CLGD5446) {
- pci_register_bar((PCIDevice *)d, 1, CIRRUS_PNPMMIO_SIZE,
+ pci_register_bar(&d->dev, 1, CIRRUS_PNPMMIO_SIZE,
PCI_BASE_ADDRESS_SPACE_MEMORY, cirrus_pci_mmio_map);
}
return 0;
diff --git a/hw/e1000.c b/hw/e1000.c
index 7811699..57d08cf 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1133,10 +1133,10 @@ static int pci_e1000_init(PCIDevice *pci_dev)
d->mmio_index = cpu_register_io_memory(e1000_mmio_read,
e1000_mmio_write, d);
-pci_register_bar((PCIDevice *)d, 0, PNPMMIO_SIZE,
+pci_register_bar(&d->dev, 0, PNPMMIO_SIZE,
PCI_BASE_ADDRESS_SPACE_MEMORY, e1000_mmio_map);
-pci_register_bar((PCIDevice *)d, 1, IOPORT_SIZE,
+pci_register_bar(&d->dev, 1, IOPORT_SIZE,
PCI_BASE_ADDRESS_SPACE_IO, ioport_map);
memmove(d->eeprom_data, e1000_eeprom_template,
diff --git a/hw/ide/via.c b/hw/ide/via.c
index b2c7cad..2001a36 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -153,7 +153,7 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
pci_set_long(pci_conf + PCI_CAPABILITY_LIST, 0x00c0);
qemu_register_reset(via_reset, d);
-pci_register_bar((PCIDevice *)d, 4, 0x10,
+pci_register_bar(&d->dev, 4, 0x10,
PCI_BASE_ADDRESS_SPACE_IO, bmdma_map);
vmstate_register(&dev->qdev, 0, &vmstate_ide_pci, d);
diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c
index f97335e..1aef62f 100644
--- a/hw/lsi53c895a.c
+++ b/hw/lsi53c895a.c
@@ -2177,12 +2177,11 @@ static int lsi_scsi_init(PCIDevice *dev)
s->ram_io_addr = cpu_register_io_memory(lsi_ram_readfn,
lsi_ram_writefn, s);
-/* TODO: use dev and get rid of cast below */
-pci_register_bar((struct PCIDevice *)s, 0, 256,
+pci_register_bar(&s->dev, 0, 256,
PCI_BASE_ADDRESS_SPACE_IO, lsi_io_mapfunc);
-pci_register_bar((struct PCIDevice *)s, 1, 0x400,
+pci_register_bar(&s->dev, 1, 0x400,
PCI_BASE_ADDRESS_SPACE_MEMORY, lsi_mmio_mapfunc);
-pci_register_bar((struct PCIDevice *)s, 2, 0x2000,
+pci_register_bar(&s->dev, 2, 0x2000,
PCI_BASE_ADDRESS_SPACE_MEMORY, lsi_ram_mapfunc);
QTAILQ_INIT(&s->queue);
diff --git a/hw/openpic.c b/hw/openpic.c
index 01bf15f..f6b8f21 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
@@ -1197,7 +1197,7 @@ qemu_irq *openpic_init (PCIBus *bus, int *pmem_index, int
nb_cpus,
pci_conf[0x3d] = 0x00; // no interrupt pin
/* Register I/O spaces */
-pci_register_bar((PCIDevice *)opp, 0, 0x4,
+pci_register_bar(&opp->pci_dev, 0, 0x4,
PCI_BASE_ADDRESS_SPACE_MEMORY, &openpic_map);
} else {
opp = qemu_mallocz(sizeof(openpic_t));
diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
index c60fd8d..8fb2f83 100644
--- a/hw/usb-ohci.c
+++ b/hw/usb-ohci.c
@@ -1741,7 +1741,7 @@ static int usb_ohci_initfn_pci(struct PCIDevice *dev)
ohci->state.irq = ohci->pci_dev.irq[0];
/* TODO: avoid cast below by using dev */
-pci_register_bar((struct PCIDevice *)ohci, 0, 256,
+pci_register_bar(&ohci->pci_dev, 0, 256,
PCI_BASE_ADDRESS_SPACE_MEMORY, ohci_mapfunc);
return 0;
}
--
1.7.2.3
Re: [Qemu-devel] [PATCH 03/16] scsi: Return SAM status codes
On Thu, Nov 18, 2010 at 03:46:32PM +0100, Hannes Reinecke wrote: > > The SCSI emulation is supposed to return status codes as defined > by SAM, not the linux ones which are shifted by one. When just looking at the patch the description is rather confusing as all places touched were already returning the correct value by doing the opencoded shift. Only a little grepping reveals that there are lots of other incorrect uses, too. You might consider mentioning this in the patch description.
Re: [Qemu-devel] [PATCH 04/16] scsi: INQUIRY VPD fixes
On Thu, Nov 18, 2010 at 03:47:00PM +0100, Hannes Reinecke wrote: > > We should announce and support the block device characterics page > only on block devices, not on CDROMs. And the VPD page 0x83 has > an off-by-one error. Looks good. This code would be a lot cleaner by splitting all vpd emulations out into separate helpers, btw.
Re: [Qemu-devel] [PATCH 05/16] scsi: Move sense handling into the driver
On Thu, Nov 18, 2010 at 03:47:04PM +0100, Hannes Reinecke wrote: > > The current sense handling in scsi-bus is only used by the > scsi-disk driver; the scsi-generic driver is using its own. > So we should move the current sense handling into the > scsi-disk driver. Looks good.
Re: [Qemu-devel] [PATCH 06/16] scsi-disk: Remove duplicate cdb parsing
On Thu, Nov 18, 2010 at 03:47:09PM +0100, Hannes Reinecke wrote: > > We parse the CDB twice, which is completely unnecessary. > > Signed-off-by: Hannes Reinecke Looks good, Reviewed-by: Christoph Hellwig
Re: [Qemu-devel] [PATCH 07/16] scsi: Update sense code handling
On Thu, Nov 18, 2010 at 03:47:14PM +0100, Hannes Reinecke wrote: > > 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 certain cases. > This patch introduces various predefined sense codes to have the > sense code reporting more in line with the spec. Looks good.
Re: [Qemu-devel] [PATCH 12/16] scsi-generic: use plain ioctl
On Thu, Nov 18, 2010 at 03:47:36PM +0100, Hannes Reinecke wrote: > > aio_ioctl is emulated anyway and currently broken. What's broken about it currently? > So better use 'normal' ioctl here as there are no benefits > on using the emulated async I/O call. There are huge benefits. Without it the whole scsi command execution happens synchronously in the qemu main loop, blocking guest execution.
RE: [Qemu-devel] [PATCH]target-arm: fix semihosting commandline handling
Please disregard my earlier patch. Due to my not being familiar with
git, I posted a wrong version of my code. I'll follow up with a new
version later.
(My previous post seems to not have made it to the list. My apologies if
you receive this twice.)
- Wolfgang Schildbach
From: qemu-devel-bounces+wschi=dolby@nongnu.org
[mailto:qemu-devel-bounces+wschi=dolby@nongnu.org] On Behalf Of
Schildbach, Wolfgang
Sent: Friday, November 19, 2010 5:22 PM
To: qemu-devel@nongnu.org
Cc: peter.mayd...@linaro.org
Subject: [Qemu-devel] [PATCH]target-arm: fix semihosting commandline
handling
The ARM semihosting commandline handling does not work -- please see
details in bug report 673613,
https://bugs.launchpad.net/qemu/+bug/673613 .
The following patch, suggested by Peter Maydell, fixes the problem. I
have tested the patch on the latest development tree, on which it works
(after one unrelated fix).
Best regards,
- Wolfgang Schildbach
---
diff --git a/arm-semi.c b/arm-semi.c
index 0687b03..53b40e4 100644
--- a/arm-semi.c
+++ b/arm-semi.c
@@ -373,45 +373,48 @@ uint32_t do_arm_semihosting(CPUState *env)
#ifdef CONFIG_USER_ONLY
/* Build a commandline from the original argv. */
{
-char **arg = ts->info->host_argv;
-int len = ARG(1);
-/* lock the buffer on the ARM side */
-char *cmdline_buffer = (char*)lock_user(VERIFY_WRITE,
ARG(0), len, 0);
+int i ;
-if (!cmdline_buffer)
-/* FIXME - should this error code be -TARGET_EFAULT ?
*/
-return (uint32_t)-1;
+char *arm_cmdline_buffer ;
+const char *host_cmdline_buffer ;
-s = cmdline_buffer;
-while (*arg && len > 2) {
-int n = strlen(*arg);
+int arm_cmdline_len = ARG(1) ;
+int host_cmdline_len =
ts->info->arg_end-ts->info->arg_start ;
-if (s != cmdline_buffer) {
-*(s++) = ' ';
-len--;
-}
-if (n >= len)
-n = len - 1;
-memcpy(s, *arg, n);
-s += n;
-len -= n;
-arg++;
-}
-/* Null terminate the string. */
-*s = 0;
-len = s - cmdline_buffer;
+if (host_cmdline_len > arm_cmdline_len)
+return (uint32_t)-1; /* command line too long */
+
+/* lock the buffers on the ARM side */
+arm_cmdline_buffer = (char*)lock_user(VERIFY_WRITE, ARG(0),
host_cmdline_len, 0);
+host_cmdline_buffer = (const char*)lock_user(PAGE_READ,
ts->info->arg_start, host_cmdline_len, 0);
-/* Unlock the buffer on the ARM side. */
-unlock_user(cmdline_buffer, ARG(0), len);
+if (arm_cmdline_buffer && host_cmdline_buffer)
+{
-/* Adjust the commandline length argument. */
-SET_ARG(1, len);
+/* the last argument is zero-terminated;
+ no need for additional termination */
+memcpy(arm_cmdline_buffer, host_cmdline_buffer,
host_cmdline_len);
-/* Return success if commandline fit into buffer. */
-return *arg ? -1 : 0;
+/* separate arguments by white spaces */
+for (i = 0; i < host_cmdline_len-1; i++) {
+if (arm_cmdline_buffer[i] == 0) {
+arm_cmdline_buffer[i] = ' ';
+}
+}
+
+/* Adjust the commandline length argument. */
+SET_ARG(1, host_cmdline_len);
+}
+
+/* Unlock the buffers on the ARM side. */
+unlock_user(arm_cmdline_buffer, ARG(0), host_cmdline_len);
+unlock_user((void*)host_cmdline_buffer,
ts->info->arg_start, host_cmdline_len);
+
+/* Return success if we could return a commandline. */
+return (arm_cmdline_buffer && host_cmdline_buffer) ? 0 :
-1;
}
#else
- return -1;
+return -1;
#endif
case SYS_HEAPINFO:
{
diff --git a/bsd-user/bsdload.c b/bsd-user/bsdload.c
index 14a93bf..6d9bb6f 100644
--- a/bsd-user/bsdload.c
+++ b/bsd-user/bsdload.c
@@ -176,8 +176,6 @@ int loader_exec(const char * filename, char ** argv,
char ** envp,
retval = prepare_binprm(&bprm);
-infop->host_argv = argv;
-
if(retval>=0) {
if (bprm.buf[0] == 0x7f
&& bprm.buf[1] == 'E'
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 9763616..e343894 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -50,7 +50,6 @@ struct image_info {
abi_ulong entry;
abi_ulong code_offset;
abi_ulong data_offset;
-char **host_argv;
int personality;
};
diff --git a/linux-user/linuxload.c b/linux-user/linuxload.c
index 9ee27c3..ac8c486 100644
--- a/linux
Re: [Qemu-devel] Re: [PATCH v2 0/4] use new vgabios.
On 11/01/2010 11:03 AM, Gerd Hoffmann wrote: On 10/15/10 12:02, Gerd Hoffmann wrote: This patch series will put the new vgabios into use for stdvga and vmware_vga. The vgabios patches have been posted a while ago, they are also also available from git://anongit.freedesktop.org/~kraxel/vgabios pcibios For obvious reasons it depends on the new vgabios binaries being present, i.e. vgabios patches being committed to vgabios.git, subtree being updated and vgabios binaries being recompiled + committed to qemu.git. Changes in v2: * rebase to master, resolve video.x removal conflict. * add a new clean up patch, removes bits which where used by video.x code only. The qemu patches are also available from git://anongit.freedesktop.org/spice/qemu vgabios.2 please pull, Gerd Ping? Merged this and the qemu patches (vgabios.3 branch). Thanks. Regards, Anthony Liguori cheers, Gerd
Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device
On Fri, Nov 19, 2010 at 06:02:58PM +0100, Markus Armbruster wrote: > "Michael S. Tsirkin" writes: > > > On Tue, Nov 09, 2010 at 11:41:43AM +0900, Isaku Yamahata wrote: > >> On Mon, Nov 08, 2010 at 06:26:33PM +0200, Michael S. Tsirkin wrote: > >> > Replace bus number with slot numbers of parent bridges up to the root. > >> > This works for root bridge in a compatible way because bus number there > >> > is hard-coded to 0. > >> > IMO nested bridges are broken anyway, no way to be compatible there. > >> > > >> > > >> > Gleb, Markus, I think the following should be sufficient for PCI. What > >> > do you think? Also - do we need to update QMP/monitor to teach them to > >> > work with these paths? > >> > > >> > This is on top of Alex's patch, completely untested. > >> > > >> > > >> > pci: fix device path for devices behind nested bridges > >> > > >> > We were using bus number in the device path, which is clearly > >> > broken as this number is guest-assigned for all devices > >> > except the root. > >> > > >> > Fix by using hierarchical list of slots, walking the path > >> > from root down to device, instead. Add :00 as bus number > >> > so that if there are no nested bridges, this is compatible > >> > with what we have now. > >> > >> This format, Domain:00:Slot:Slot:Slot.Function, doesn't work > >> because pci-to-pci bridge is pci function. > >> So the format should be > >> Domain:00:Slot.Function:Slot.Function:Slot.Function > >> > >> thanks, > > > > Hmm, interesting. If we do this we aren't backwards compatible > > though, so maybe we could try using openfirmware paths, just as well. > > Whatever we do, we need to make it work for all (qdevified) devices and > buses. > > It should also be possible to use canonical addressing with device_add & > friends. I.e. permit naming a device by (a unique abbreviation of) its > canonical address in addition to naming it by its user-defined ID. For > instance, something like > >device_del /pci/@1,1 > FWIW openbios allows this kind of abbreviation. > in addition to > >device_del ID > > Open Firmware is a useful source of inspiration there, but should it > come into conflict with usability, we should let usability win. -- Gleb.
[Qemu-devel] [PATCH] ahci: fix lst+fis mapping
The ahci map_page() function checks whenever it got a full page mapped.
This is wrong. The data structures are much smaller: command list is
1k and fis is 256 bytes. Checking whenever we can access that much
bytes without crossing a page border is good enougth.
Signed-off-by: Gerd Hoffmann
---
hw/ahci.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/hw/ahci.c b/hw/ahci.c
index 0ee021e..fdd5572 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -411,16 +411,16 @@ static void ahci_check_irq(AHCIState *s)
}
}
-static void map_page(uint8_t **ptr, uint64_t addr)
+static void map_page(uint8_t **ptr, uint64_t addr, uint32_t wanted)
{
-target_phys_addr_t len = 4096;
+target_phys_addr_t len = wanted;
if (*ptr) {
cpu_physical_memory_unmap(*ptr, 1, len, len);
}
*ptr = cpu_physical_memory_map(addr, &len, 1);
-if (len < 4096) {
+if (len < wanted) {
*ptr = NULL;
}
}
@@ -435,22 +435,22 @@ static void ahci_port_write(AHCIState *s, int port, int
offset, uint32_t val)
case PORT_LST_ADDR:
pr->lst_addr = val;
map_page(&s->dev[port].lst,
- ((uint64_t)pr->lst_addr_hi << 32) | pr->lst_addr);
+ ((uint64_t)pr->lst_addr_hi << 32) | pr->lst_addr, 1024);
break;
case PORT_LST_ADDR_HI:
pr->lst_addr_hi = val;
map_page(&s->dev[port].lst,
- ((uint64_t)pr->lst_addr_hi << 32) | pr->lst_addr);
+ ((uint64_t)pr->lst_addr_hi << 32) | pr->lst_addr, 1024);
break;
case PORT_FIS_ADDR:
pr->fis_addr = val;
map_page(&s->dev[port].res_fis,
- ((uint64_t)pr->fis_addr_hi << 32) | pr->fis_addr);
+ ((uint64_t)pr->fis_addr_hi << 32) | pr->fis_addr, 256);
break;
case PORT_FIS_ADDR_HI:
pr->fis_addr_hi = val;
map_page(&s->dev[port].res_fis,
- ((uint64_t)pr->fis_addr_hi << 32) | pr->fis_addr);
+ ((uint64_t)pr->fis_addr_hi << 32) | pr->fis_addr, 256);
break;
case PORT_IRQ_STAT:
pr->irq_stat &= ~val;
--
1.7.1
[Qemu-devel] [PATCH v3 0/9] PCI capability and device assignment improvements
v3: - Rework to avoid introducing conflicts with qemu.git hw/pci - Drop capability lookup table - Add back minimal device assignment PM, EXP, X, VPD, VNDR capabilities This version should do a much better job at not introducing new differences between qemu-kvm.git and qemu.git hw/pci. The diff between the pci files after this series is significantly reduced. I added back the previous RFC patch that adds new capabilities for assigned devices. I'm sure we'll want to add passthrough for various fields, but that can come later (along with figuring out whether we can consolidate emulation should other drivers want it). Thanks, Alex v2: - Fixed the function name in 1/8 per Michael's suggestion. - Removed capability specific config read/write registration - Added more checks to add_capability - Added capability lookup table to PCIDevice I've dropped the RFC patch to add more capabilities to device assignment while I do some more work on it. Please feel free to comment on the v1 version though. Patches still against qemu-kvm, but I hope some of this makes it easier to bring qemu & qemu-kvm closer here. v1: This series attempts to clean up capability support between common code and device assignment. In doing so, we can move existing MSI & MSI-X capabilities to offsets matching real hardware, and further enable more capabilities to be exposed. The last patch is only for RFC, I'd like some input on what we should pass directly and where we should only provide read-only/emulated access. Patches 1-7 are submitted for commit. --- Alex Williamson (9): device-assignment: pass through and stub more PCI caps device-assignment: Make use of config_map pci: Remove capability specific handlers device-assignment: Move PCI capabilities to match physical hardware pci: Remove cap.length, cap.start, cap.supported pci: Replace used bitmap with config byte map device-assignment: Use PCI capabilities support pci: Remove pci_enable_capability_support() pci: pci_default_cap_write_config ignores wmask hw/device-assignment.c | 332 +--- hw/pci.c | 109 ++-- hw/pci.h | 32 - 3 files changed, 276 insertions(+), 197 deletions(-)
[Qemu-devel] [PATCH v3 1/9] pci: pci_default_cap_write_config ignores wmask
Make use of wmask, just like the rest of config space.
This duplicates code in pci_default_write_config, but we plan to get
rid of this function anyway, so avoid the code churn.
Signed-off-by: Alex Williamson
---
hw/pci.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index c3b5048..8e99746 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1088,16 +1088,6 @@ uint32_t pci_default_read_config(PCIDevice *d,
return pci_read_config(d, address, len);
}
-static void pci_write_config(PCIDevice *pci_dev,
- uint32_t address, uint32_t val, int len)
-{
-int i;
-for (i = 0; i < len; i++) {
-pci_dev->config[address + i] = val & 0xff;
-val >>= 8;
-}
-}
-
int pci_access_cap_config(PCIDevice *pci_dev, uint32_t address, int len)
{
if (pci_dev->cap.supported && address >= pci_dev->cap.start &&
@@ -1115,7 +1105,14 @@ uint32_t pci_default_cap_read_config(PCIDevice *pci_dev,
void pci_default_cap_write_config(PCIDevice *pci_dev,
uint32_t address, uint32_t val, int len)
{
-pci_write_config(pci_dev, address, val, len);
+uint32_t config_size = pci_config_size(pci_dev);
+int i;
+
+for (i = 0; i < len && address + i < config_size; val >>= 8, ++i) {
+uint8_t wmask = pci_dev->wmask[address + i];
+pci_dev->config[address + i] =
+(pci_dev->config[address + i] & ~wmask) | (val & wmask);
+}
}
void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int l)
[Qemu-devel] [PATCH v3 2/9] pci: Remove pci_enable_capability_support()
This interface doesn't make much sense, adding a capability can
take care of everything, just provide a means to register
capability read/write handlers.
Device assignment does it's own thing, so requires a couple
ugly hacks that will be cleaned by subsequent patches.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 12 ---
hw/pci.c | 52 +---
hw/pci.h |9 +++-
3 files changed, 35 insertions(+), 38 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 369bff9..a297cb4 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -1292,7 +1292,12 @@ static int assigned_device_pci_cap_init(PCIDevice
*pci_dev)
PCIRegion *pci_region = dev->real_device.regions;
int next_cap_pt = 0;
+pci_dev->cap.supported = 1;
+pci_dev->cap.start = PCI_CAPABILITY_CONFIG_DEFAULT_START_ADDR;
pci_dev->cap.length = 0;
+pci_dev->config[PCI_STATUS] |= PCI_STATUS_CAP_LIST;
+pci_dev->config[PCI_CAPABILITY_LIST] = pci_dev->cap.start;
+
#ifdef KVM_CAP_IRQ_ROUTING
#ifdef KVM_CAP_DEVICE_MSI
/* Expose MSI capability
@@ -1488,9 +1493,10 @@ static int assigned_initfn(struct PCIDevice *pci_dev)
dev->h_busnr = dev->host.bus;
dev->h_devfn = PCI_DEVFN(dev->host.dev, dev->host.func);
-if (pci_enable_capability_support(pci_dev, 0, NULL,
-assigned_device_pci_cap_write_config,
-assigned_device_pci_cap_init) < 0)
+pci_register_capability_handlers(pci_dev, NULL,
+ assigned_device_pci_cap_write_config);
+
+if (assigned_device_pci_cap_init(pci_dev) < 0)
goto out;
/* assign device to guest */
diff --git a/hw/pci.c b/hw/pci.c
index 8e99746..f2896d9 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -770,6 +770,8 @@ static PCIDevice *do_pci_register_device(PCIDevice
*pci_dev, PCIBus *bus,
config_write = pci_default_write_config;
pci_dev->config_read = config_read;
pci_dev->config_write = config_write;
+pci_dev->cap.config_read = pci_default_cap_read_config;
+pci_dev->cap.config_write = pci_default_cap_write_config;
bus->devices[devfn] = pci_dev;
pci_dev->irq = qemu_allocate_irqs(pci_set_irq, pci_dev, PCI_NUM_PINS);
pci_dev->version_id = 2; /* Current pci device vmstate version */
@@ -1754,35 +1756,21 @@ PCIDevice *pci_create_simple_multifunction(PCIBus *bus,
int devfn,
return dev;
}
-int pci_enable_capability_support(PCIDevice *pci_dev,
- uint32_t config_start,
- PCICapConfigReadFunc *config_read,
- PCICapConfigWriteFunc *config_write,
- PCICapConfigInitFunc *config_init)
+void pci_register_capability_handlers(PCIDevice *pdev,
+ PCICapConfigReadFunc *config_read,
+ PCICapConfigWriteFunc *config_write)
{
-if (!pci_dev)
-return -ENODEV;
-
-pci_dev->config[0x06] |= 0x10; // status = capabilities
-
-if (config_start == 0)
- pci_dev->cap.start = PCI_CAPABILITY_CONFIG_DEFAULT_START_ADDR;
-else if (config_start >= 0x40 && config_start < 0xff)
-pci_dev->cap.start = config_start;
-else
-return -EINVAL;
+if (config_read) {
+pdev->cap.config_read = config_read;
+} else {
+pdev->cap.config_read = pci_default_cap_read_config;
+}
-if (config_read)
-pci_dev->cap.config_read = config_read;
-else
-pci_dev->cap.config_read = pci_default_cap_read_config;
-if (config_write)
-pci_dev->cap.config_write = config_write;
-else
-pci_dev->cap.config_write = pci_default_cap_write_config;
-pci_dev->cap.supported = 1;
-pci_dev->config[PCI_CAPABILITY_LIST] = pci_dev->cap.start;
-return config_init(pci_dev);
+if (config_write) {
+pdev->cap.config_write = config_write;
+} else {
+pdev->cap.config_write = pci_default_cap_write_config;
+}
}
PCIDevice *pci_create(PCIBus *bus, int devfn, const char *name)
@@ -1920,12 +1908,16 @@ int pci_add_capability(PCIDevice *pdev, uint8_t cap_id,
config[PCI_CAP_LIST_ID] = cap_id;
config[PCI_CAP_LIST_NEXT] = pdev->config[PCI_CAPABILITY_LIST];
pdev->config[PCI_CAPABILITY_LIST] = offset;
-pdev->config[PCI_STATUS] |= PCI_STATUS_CAP_LIST;
memset(pdev->used + offset, 0xFF, size);
/* Make capability read-only by default */
memset(pdev->wmask + offset, 0, size);
/* Check capability by default */
memset(pdev->cmask + offset, 0xFF, size);
+
+pdev->config[PCI_STATUS] |= PCI_STATUS_CAP_LIST;
+pdev->cap.supported = 1;
+pdev->cap.start = pdev->cap.start ? MIN(pdev->cap.start, offset) : offset;
+
return offset;
}
@@ -1943,8 +1935,10 @@ void pci_del_capability(PCIDevice *pdev, uint8_t cap_id,
uint8_t siz
[Qemu-devel] [PATCH v3 3/9] device-assignment: Use PCI capabilities support
Convert to use common pci_add_capabilities() rather than creating
our own mess.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 112 +++-
1 files changed, 63 insertions(+), 49 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index a297cb4..76aacac 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -38,6 +38,7 @@
#include "device-assignment.h"
#include "loader.h"
#include "monitor.h"
+#include "range.h"
#include
/* From linux/ioport.h */
@@ -1075,17 +1076,17 @@ static void assigned_dev_update_msi(PCIDevice *pci_dev,
unsigned int ctrl_pos)
}
if (ctrl_byte & PCI_MSI_FLAGS_ENABLE) {
+int pos = ctrl_pos - PCI_MSI_FLAGS;
assigned_dev->entry = calloc(1, sizeof(struct kvm_irq_routing_entry));
if (!assigned_dev->entry) {
perror("assigned_dev_update_msi: ");
return;
}
assigned_dev->entry->u.msi.address_lo =
-*(uint32_t *)(pci_dev->config + pci_dev->cap.start +
- PCI_MSI_ADDRESS_LO);
+pci_get_long(pci_dev->config + pos + PCI_MSI_ADDRESS_LO);
assigned_dev->entry->u.msi.address_hi = 0;
-assigned_dev->entry->u.msi.data = *(uint16_t *)(pci_dev->config +
-pci_dev->cap.start + PCI_MSI_DATA_32);
+assigned_dev->entry->u.msi.data =
+pci_get_word(pci_dev->config + pos + PCI_MSI_DATA_32);
assigned_dev->entry->type = KVM_IRQ_ROUTING_MSI;
r = kvm_get_irq_route_gsi();
if (r < 0) {
@@ -1123,10 +1124,7 @@ static int assigned_dev_update_msix_mmio(PCIDevice
*pci_dev)
struct kvm_assigned_msix_entry msix_entry;
void *va = adev->msix_table_page;
-if (adev->cap.available & ASSIGNED_DEVICE_CAP_MSI)
-pos = pci_dev->cap.start + PCI_CAPABILITY_CONFIG_MSI_LENGTH;
-else
-pos = pci_dev->cap.start;
+pos = pci_find_capability(pci_dev, PCI_CAP_ID_MSIX);
entries_max_nr = *(uint16_t *)(pci_dev->config + pos + 2);
entries_max_nr &= PCI_MSIX_TABSIZE;
@@ -1260,26 +1258,23 @@ static void
assigned_device_pci_cap_write_config(PCIDevice *pci_dev, uint32_t ad
uint32_t val, int len)
{
AssignedDevice *assigned_dev = container_of(pci_dev, AssignedDevice, dev);
-unsigned int pos = pci_dev->cap.start, ctrl_pos;
pci_default_cap_write_config(pci_dev, address, val, len);
#ifdef KVM_CAP_IRQ_ROUTING
#ifdef KVM_CAP_DEVICE_MSI
if (assigned_dev->cap.available & ASSIGNED_DEVICE_CAP_MSI) {
-ctrl_pos = pos + PCI_MSI_FLAGS;
-if (address <= ctrl_pos && address + len > ctrl_pos)
-assigned_dev_update_msi(pci_dev, ctrl_pos);
-pos += PCI_CAPABILITY_CONFIG_MSI_LENGTH;
+int pos = pci_find_capability(pci_dev, PCI_CAP_ID_MSI);
+if (ranges_overlap(address, len, pos + PCI_MSI_FLAGS, 1)) {
+assigned_dev_update_msi(pci_dev, pos + PCI_MSI_FLAGS);
+}
}
#endif
#ifdef KVM_CAP_DEVICE_MSIX
if (assigned_dev->cap.available & ASSIGNED_DEVICE_CAP_MSIX) {
-ctrl_pos = pos + 3;
-if (address <= ctrl_pos && address + len > ctrl_pos) {
-ctrl_pos--; /* control is word long */
-assigned_dev_update_msix(pci_dev, ctrl_pos);
+int pos = pci_find_capability(pci_dev, PCI_CAP_ID_MSIX);
+if (ranges_overlap(address, len, pos + PCI_MSIX_FLAGS + 1, 1)) {
+assigned_dev_update_msix(pci_dev, pos + PCI_MSIX_FLAGS);
}
-pos += PCI_CAPABILITY_CONFIG_MSIX_LENGTH;
}
#endif
#endif
@@ -1290,58 +1285,77 @@ static int assigned_device_pci_cap_init(PCIDevice
*pci_dev)
{
AssignedDevice *dev = container_of(pci_dev, AssignedDevice, dev);
PCIRegion *pci_region = dev->real_device.regions;
-int next_cap_pt = 0;
-pci_dev->cap.supported = 1;
-pci_dev->cap.start = PCI_CAPABILITY_CONFIG_DEFAULT_START_ADDR;
+/* Clear initial capabilities pointer and status copied from hw */
+pci_set_byte(pci_dev->config + PCI_CAPABILITY_LIST, 0);
+pci_set_word(pci_dev->config + PCI_STATUS,
+ pci_get_word(pci_dev->config + PCI_STATUS) &
+ ~PCI_STATUS_CAP_LIST);
+
pci_dev->cap.length = 0;
-pci_dev->config[PCI_STATUS] |= PCI_STATUS_CAP_LIST;
-pci_dev->config[PCI_CAPABILITY_LIST] = pci_dev->cap.start;
#ifdef KVM_CAP_IRQ_ROUTING
#ifdef KVM_CAP_DEVICE_MSI
/* Expose MSI capability
* MSI capability is the 1st capability in capability config */
if (pci_find_cap_offset(pci_dev, PCI_CAP_ID_MSI)) {
+int vpos, ppos;
+uint16_t flags;
+
dev->cap.available |= ASSIGNED_DEVICE_CAP_MSI;
-memset(&pci_dev->config[pci_dev->cap.start + pci_dev->cap.length],
- 0, PCI_CAPABILITY_CONFIG_MSI_LENGTH);
-pci_dev->config[pci_dev->cap.start + pci_dev->cap.length] =
-PCI_CAP_ID_MSI;
+
[Qemu-devel] [PATCH v3 8/9] device-assignment: Make use of config_map
We can figure out the capability being touched much more quickly
and efficiently with the config_map. Use it.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 32 +++-
1 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 970ffa1..832c236 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -1254,28 +1254,34 @@ static void assigned_dev_update_msix(PCIDevice
*pci_dev, unsigned int ctrl_pos)
static void assigned_device_pci_cap_write_config(PCIDevice *pci_dev, uint32_t
address,
uint32_t val, int len)
{
-AssignedDevice *assigned_dev = container_of(pci_dev, AssignedDevice, dev);
+uint8_t cap_id = pci_dev->config_map[address];
pci_default_write_config(pci_dev, address, val, len);
+switch (cap_id) {
#ifdef KVM_CAP_IRQ_ROUTING
+case PCI_CAP_ID_MSI:
#ifdef KVM_CAP_DEVICE_MSI
-if (assigned_dev->cap.available & ASSIGNED_DEVICE_CAP_MSI) {
-int pos = pci_find_capability(pci_dev, PCI_CAP_ID_MSI);
-if (ranges_overlap(address, len, pos + PCI_MSI_FLAGS, 1)) {
-assigned_dev_update_msi(pci_dev, pos + PCI_MSI_FLAGS);
+{
+uint8_t cap = pci_find_capability(pci_dev, cap_id);
+if (ranges_overlap(address - cap, len, PCI_MSI_FLAGS, 1)) {
+assigned_dev_update_msi(pci_dev, cap + PCI_MSI_FLAGS);
+}
}
-}
#endif
+break;
+
+case PCI_CAP_ID_MSIX:
#ifdef KVM_CAP_DEVICE_MSIX
-if (assigned_dev->cap.available & ASSIGNED_DEVICE_CAP_MSIX) {
-int pos = pci_find_capability(pci_dev, PCI_CAP_ID_MSIX);
-if (ranges_overlap(address, len, pos + PCI_MSIX_FLAGS + 1, 1)) {
-assigned_dev_update_msix(pci_dev, pos + PCI_MSIX_FLAGS);
- }
-}
+{
+uint8_t cap = pci_find_capability(pci_dev, cap_id);
+if (ranges_overlap(address - cap, len, PCI_MSIX_FLAGS + 1, 1)) {
+assigned_dev_update_msix(pci_dev, cap + PCI_MSIX_FLAGS);
+}
+}
#endif
+break;
#endif
-return;
+}
}
static int assigned_device_pci_cap_init(PCIDevice *pci_dev)
[Qemu-devel] [PATCH v3 4/9] pci: Replace used bitmap with config byte map
Capabilities are allocated in bytes, so we can track both whether
a byte is used and by what capability in the same structure.
Remove pci_reserve_capability() as there are no users, remove
pci_access_cap_config() since it's now a trivial lookup.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c |4 ++--
hw/pci.c | 30 +-
hw/pci.h |8 ++--
3 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 76aacac..a4fad60 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -423,7 +423,7 @@ static void assigned_dev_pci_write_config(PCIDevice *d,
uint32_t address,
if ((address >= 0x10 && address <= 0x24) || address == 0x30 ||
address == 0x34 || address == 0x3c || address == 0x3d ||
-pci_access_cap_config(d, address, len)) {
+(address > PCI_CONFIG_HEADER_SIZE && d->config_map[address])) {
/* used for update-mappings (BAR emulation) */
pci_default_write_config(d, address, val, len);
return;
@@ -459,7 +459,7 @@ static uint32_t assigned_dev_pci_read_config(PCIDevice *d,
uint32_t address,
if (address < 0x4 || (pci_dev->need_emulate_cmd && address == 0x4) ||
(address >= 0x10 && address <= 0x24) || address == 0x30 ||
address == 0x34 || address == 0x3c || address == 0x3d ||
-pci_access_cap_config(d, address, len)) {
+(address > PCI_CONFIG_HEADER_SIZE && d->config_map[address])) {
val = pci_default_read_config(d, address, len);
DEBUG("(%x.%x): address=%04x val=0x%08x len=%d\n",
(d->devfn >> 3) & 0x1F, (d->devfn & 0x7), address, val, len);
diff --git a/hw/pci.c b/hw/pci.c
index f2896d9..cbe6fb7 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -712,7 +712,7 @@ static void pci_config_alloc(PCIDevice *pci_dev)
pci_dev->cmask = qemu_mallocz(config_size);
pci_dev->wmask = qemu_mallocz(config_size);
pci_dev->w1cmask = qemu_mallocz(config_size);
-pci_dev->used = qemu_mallocz(config_size);
+pci_dev->config_map = qemu_mallocz(config_size);
}
static void pci_config_free(PCIDevice *pci_dev)
@@ -721,7 +721,7 @@ static void pci_config_free(PCIDevice *pci_dev)
qemu_free(pci_dev->cmask);
qemu_free(pci_dev->wmask);
qemu_free(pci_dev->w1cmask);
-qemu_free(pci_dev->used);
+qemu_free(pci_dev->config_map);
}
/* -1 for devfn means auto assign */
@@ -751,6 +751,8 @@ static PCIDevice *do_pci_register_device(PCIDevice
*pci_dev, PCIBus *bus,
pci_dev->irq_state = 0;
pci_config_alloc(pci_dev);
+memset(pci_dev->config_map, 0xff, PCI_CONFIG_HEADER_SIZE);
+
if (!is_bridge) {
pci_set_default_subsystem_id(pci_dev);
}
@@ -1083,21 +1085,13 @@ uint32_t pci_default_read_config(PCIDevice *d,
{
assert(len == 1 || len == 2 || len == 4);
-if (pci_access_cap_config(d, address, len)) {
+if (address > PCI_CONFIG_HEADER_SIZE && d->config_map[address]) {
return d->cap.config_read(d, address, len);
}
return pci_read_config(d, address, len);
}
-int pci_access_cap_config(PCIDevice *pci_dev, uint32_t address, int len)
-{
-if (pci_dev->cap.supported && address >= pci_dev->cap.start &&
-(address + len) < pci_dev->cap.start + pci_dev->cap.length)
-return 1;
-return 0;
-}
-
uint32_t pci_default_cap_read_config(PCIDevice *pci_dev,
uint32_t address, int len)
{
@@ -1122,7 +1116,7 @@ void pci_default_write_config(PCIDevice *d, uint32_t
addr, uint32_t val, int l)
int i, was_irq_disabled = pci_irq_disabled(d);
uint32_t config_size = pci_config_size(d);
-if (pci_access_cap_config(d, addr, l)) {
+if (addr > PCI_CONFIG_HEADER_SIZE && d->config_map[addr]) {
d->cap.config_write(d, addr, val, l);
return;
}
@@ -1789,7 +1783,7 @@ static int pci_find_space(PCIDevice *pdev, uint8_t size)
int offset = PCI_CONFIG_HEADER_SIZE;
int i;
for (i = PCI_CONFIG_HEADER_SIZE; i < config_size; ++i)
-if (pdev->used[i])
+if (pdev->config_map[i])
offset = i + 1;
else if (i - offset + 1 == size)
return offset;
@@ -1908,7 +1902,7 @@ int pci_add_capability(PCIDevice *pdev, uint8_t cap_id,
config[PCI_CAP_LIST_ID] = cap_id;
config[PCI_CAP_LIST_NEXT] = pdev->config[PCI_CAPABILITY_LIST];
pdev->config[PCI_CAPABILITY_LIST] = offset;
-memset(pdev->used + offset, 0xFF, size);
+memset(pdev->config_map + offset, cap_id, size);
/* Make capability read-only by default */
memset(pdev->wmask + offset, 0, size);
/* Check capability by default */
@@ -1933,7 +1927,7 @@ void pci_del_capability(PCIDevice *pdev, uint8_t cap_id,
uint8_t size)
memset(pdev->w1cmask + offset, 0, size);
/* Clear cmask as device-specific registers can't be checked */
memset(pdev->cmask + offset, 0, size);
-memset(pdev->u
[Qemu-devel] [PATCH v3 6/9] device-assignment: Move PCI capabilities to match physical hardware
Now that common PCI code doesn't have a hangup on capabilities
being contiguous, move assigned device capabilities to match
their offset on physical hardware. This helps for drivers that
assume a capability configuration and don't bother searching.
We can also remove several calls to assigned_dev_pci_read_* because
we're overlaying the capability at the same location as the initial
copy we made of config space. We can therefore just use pci_get_*.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 65 +++-
1 files changed, 20 insertions(+), 45 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 975d3cb..6314773 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -366,16 +366,6 @@ static uint8_t assigned_dev_pci_read_byte(PCIDevice *d,
int pos)
return (uint8_t)assigned_dev_pci_read(d, pos, 1);
}
-static uint16_t assigned_dev_pci_read_word(PCIDevice *d, int pos)
-{
-return (uint16_t)assigned_dev_pci_read(d, pos, 2);
-}
-
-static uint32_t assigned_dev_pci_read_long(PCIDevice *d, int pos)
-{
-return assigned_dev_pci_read(d, pos, 4);
-}
-
static uint8_t pci_find_cap_offset(PCIDevice *d, uint8_t cap)
{
int id;
@@ -1285,6 +1275,7 @@ static int assigned_device_pci_cap_init(PCIDevice
*pci_dev)
{
AssignedDevice *dev = container_of(pci_dev, AssignedDevice, dev);
PCIRegion *pci_region = dev->real_device.regions;
+int pos;
/* Clear initial capabilities pointer and status copied from hw */
pci_set_byte(pci_dev->config + PCI_CAPABILITY_LIST, 0);
@@ -1296,60 +1287,44 @@ static int assigned_device_pci_cap_init(PCIDevice
*pci_dev)
#ifdef KVM_CAP_DEVICE_MSI
/* Expose MSI capability
* MSI capability is the 1st capability in capability config */
-if (pci_find_cap_offset(pci_dev, PCI_CAP_ID_MSI)) {
-int vpos, ppos;
-uint16_t flags;
-
+if ((pos = pci_find_cap_offset(pci_dev, PCI_CAP_ID_MSI))) {
dev->cap.available |= ASSIGNED_DEVICE_CAP_MSI;
-vpos = pci_add_capability(pci_dev, PCI_CAP_ID_MSI, 0,
- PCI_CAPABILITY_CONFIG_MSI_LENGTH);
-
-memset(pci_dev->config + vpos + PCI_CAP_FLAGS, 0,
- PCI_CAPABILITY_CONFIG_MSI_LENGTH - PCI_CAP_FLAGS);
+pci_add_capability(pci_dev, PCI_CAP_ID_MSI, pos,
+ PCI_CAPABILITY_CONFIG_MSI_LENGTH);
/* Only 32-bit/no-mask currently supported */
-ppos = pci_find_cap_offset(pci_dev, PCI_CAP_ID_MSI);
-flags = assigned_dev_pci_read_word(pci_dev, ppos + PCI_MSI_FLAGS);
-flags &= PCI_MSI_FLAGS_QMASK;
-pci_set_word(pci_dev->config + vpos + PCI_MSI_FLAGS, flags);
+pci_set_word(pci_dev->config + pos + PCI_MSI_FLAGS,
+ pci_get_word(pci_dev->config + pos + PCI_MSI_FLAGS) &
+ PCI_MSI_FLAGS_QMASK);
+pci_set_long(pci_dev->config + pos + PCI_MSI_ADDRESS_LO, 0);
+pci_set_word(pci_dev->config + pos + PCI_MSI_DATA_32, 0);
/* Set writable fields */
-pci_set_word(pci_dev->wmask + vpos + PCI_MSI_FLAGS,
+pci_set_word(pci_dev->wmask + pos + PCI_MSI_FLAGS,
PCI_MSI_FLAGS_QSIZE | PCI_MSI_FLAGS_ENABLE);
-pci_set_long(pci_dev->wmask + vpos + PCI_MSI_ADDRESS_LO, 0xfffc);
-pci_set_long(pci_dev->wmask + vpos + PCI_MSI_DATA_32, 0x);
+pci_set_long(pci_dev->wmask + pos + PCI_MSI_ADDRESS_LO, 0xfffc);
+pci_set_word(pci_dev->wmask + pos + PCI_MSI_DATA_32, 0x);
}
#endif
#ifdef KVM_CAP_DEVICE_MSIX
/* Expose MSI-X capability */
-if (pci_find_cap_offset(pci_dev, PCI_CAP_ID_MSIX)) {
-int vpos, ppos, entry_nr, bar_nr;
+if ((pos = pci_find_cap_offset(pci_dev, PCI_CAP_ID_MSIX))) {
+int bar_nr;
uint32_t msix_table_entry;
dev->cap.available |= ASSIGNED_DEVICE_CAP_MSIX;
-vpos = pci_add_capability(pci_dev, PCI_CAP_ID_MSIX, 0,
+pci_add_capability(pci_dev, PCI_CAP_ID_MSIX, pos,
PCI_CAPABILITY_CONFIG_MSIX_LENGTH);
-memset(pci_dev->config + vpos + PCI_CAP_FLAGS, 0,
- PCI_CAPABILITY_CONFIG_MSIX_LENGTH - PCI_CAP_FLAGS);
+pci_set_word(pci_dev->config + pos + PCI_MSIX_FLAGS,
+ pci_get_word(pci_dev->config + pos + PCI_MSIX_FLAGS) &
+ PCI_MSIX_TABSIZE);
/* Only enable and function mask bits are writable */
-pci_set_word(pci_dev->wmask + vpos + PCI_MSIX_FLAGS,
+pci_set_word(pci_dev->wmask + pos + PCI_MSIX_FLAGS,
PCI_MSIX_FLAGS_ENABLE | PCI_MSIX_FLAGS_MASKALL);
-ppos = pci_find_cap_offset(pci_dev, PCI_CAP_ID_MSIX);
-
-entry_nr = assigned_dev_pci_read_word(pci_dev, ppos + PCI_MSIX_FLAGS);
-entry_nr &= PCI_MSIX_TABSIZE;
-pci_set_word(pci_dev->config + vpos + PCI_MSIX_FLAGS, entry_nr);
-
-msix_table_entry = assigned_
[Qemu-devel] [PATCH v3 7/9] pci: Remove capability specific handlers
Drivers can break these out on their own if they need to.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 16 -
hw/pci.c | 61 ++--
hw/pci.h | 19 ---
3 files changed, 13 insertions(+), 83 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 6314773..970ffa1 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -63,6 +63,10 @@ static void assigned_dev_load_option_rom(AssignedDevice
*dev);
static void assigned_dev_unregister_msix_mmio(AssignedDevice *dev);
+static void assigned_device_pci_cap_write_config(PCIDevice *pci_dev,
+ uint32_t address,
+ uint32_t val, int len);
+
static uint32_t assigned_dev_ioport_rw(AssignedDevRegion *dev_region,
uint32_t addr, int len, uint32_t *val)
{
@@ -406,14 +410,17 @@ static void assigned_dev_pci_write_config(PCIDevice *d,
uint32_t address,
((d->devfn >> 3) & 0x1F), (d->devfn & 0x7),
(uint16_t) address, val, len);
+if (address > PCI_CONFIG_HEADER_SIZE && d->config_map[address]) {
+return assigned_device_pci_cap_write_config(d, address, val, len);
+}
+
if (address == 0x4) {
pci_default_write_config(d, address, val, len);
/* Continue to program the card */
}
if ((address >= 0x10 && address <= 0x24) || address == 0x30 ||
-address == 0x34 || address == 0x3c || address == 0x3d ||
-(address > PCI_CONFIG_HEADER_SIZE && d->config_map[address])) {
+address == 0x34 || address == 0x3c || address == 0x3d) {
/* used for update-mappings (BAR emulation) */
pci_default_write_config(d, address, val, len);
return;
@@ -1249,7 +1256,7 @@ static void
assigned_device_pci_cap_write_config(PCIDevice *pci_dev, uint32_t ad
{
AssignedDevice *assigned_dev = container_of(pci_dev, AssignedDevice, dev);
-pci_default_cap_write_config(pci_dev, address, val, len);
+pci_default_write_config(pci_dev, address, val, len);
#ifdef KVM_CAP_IRQ_ROUTING
#ifdef KVM_CAP_DEVICE_MSI
if (assigned_dev->cap.available & ASSIGNED_DEVICE_CAP_MSI) {
@@ -1478,9 +1485,6 @@ static int assigned_initfn(struct PCIDevice *pci_dev)
dev->h_busnr = dev->host.bus;
dev->h_devfn = PCI_DEVFN(dev->host.dev, dev->host.func);
-pci_register_capability_handlers(pci_dev, NULL,
- assigned_device_pci_cap_write_config);
-
if (assigned_device_pci_cap_init(pci_dev) < 0)
goto out;
diff --git a/hw/pci.c b/hw/pci.c
index 1cf62b6..e529793 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -772,8 +772,6 @@ static PCIDevice *do_pci_register_device(PCIDevice
*pci_dev, PCIBus *bus,
config_write = pci_default_write_config;
pci_dev->config_read = config_read;
pci_dev->config_write = config_write;
-pci_dev->cap.config_read = pci_default_cap_read_config;
-pci_dev->cap.config_write = pci_default_cap_write_config;
bus->devices[devfn] = pci_dev;
pci_dev->irq = qemu_allocate_irqs(pci_set_irq, pci_dev, PCI_NUM_PINS);
pci_dev->version_id = 2; /* Current pci device vmstate version */
@@ -1070,57 +1068,21 @@ static void pci_update_irq_disabled(PCIDevice *d, int
was_irq_disabled)
}
}
-static uint32_t pci_read_config(PCIDevice *d,
-uint32_t address, int len)
+uint32_t pci_default_read_config(PCIDevice *d,
+ uint32_t address, int len)
{
uint32_t val = 0;
-
+assert(len == 1 || len == 2 || len == 4);
len = MIN(len, pci_config_size(d) - address);
memcpy(&val, d->config + address, len);
return le32_to_cpu(val);
}
-uint32_t pci_default_read_config(PCIDevice *d,
- uint32_t address, int len)
-{
-assert(len == 1 || len == 2 || len == 4);
-
-if (address > PCI_CONFIG_HEADER_SIZE && d->config_map[address]) {
-return d->cap.config_read(d, address, len);
-}
-
-return pci_read_config(d, address, len);
-}
-
-uint32_t pci_default_cap_read_config(PCIDevice *pci_dev,
- uint32_t address, int len)
-{
-return pci_read_config(pci_dev, address, len);
-}
-
-void pci_default_cap_write_config(PCIDevice *pci_dev,
- uint32_t address, uint32_t val, int len)
-{
-uint32_t config_size = pci_config_size(pci_dev);
-int i;
-
-for (i = 0; i < len && address + i < config_size; val >>= 8, ++i) {
-uint8_t wmask = pci_dev->wmask[address + i];
-pci_dev->config[address + i] =
-(pci_dev->config[address + i] & ~wmask) | (val & wmask);
-}
-}
-
void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int l)
{
int i, was_irq_disabled = pci_irq_disabled(d);
uint32_t config_size =
[Qemu-devel] [PATCH v3 5/9] pci: Remove cap.length, cap.start, cap.supported
Capabilities aren't required to be contiguous, so cap.length never
really made much sense. Likewise, cap.start is mostly meaningless
too. Both of these are better served by the capability map. We
can also get rid of cap.supported, since it's really now unused
and redundant with flag in the status word anyway.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c |4
hw/pci.c |3 ---
hw/pci.h |2 --
3 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index a4fad60..975d3cb 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -1292,8 +1292,6 @@ static int assigned_device_pci_cap_init(PCIDevice
*pci_dev)
pci_get_word(pci_dev->config + PCI_STATUS) &
~PCI_STATUS_CAP_LIST);
-pci_dev->cap.length = 0;
-
#ifdef KVM_CAP_IRQ_ROUTING
#ifdef KVM_CAP_DEVICE_MSI
/* Expose MSI capability
@@ -1320,7 +1318,6 @@ static int assigned_device_pci_cap_init(PCIDevice
*pci_dev)
PCI_MSI_FLAGS_QSIZE | PCI_MSI_FLAGS_ENABLE);
pci_set_long(pci_dev->wmask + vpos + PCI_MSI_ADDRESS_LO, 0xfffc);
pci_set_long(pci_dev->wmask + vpos + PCI_MSI_DATA_32, 0x);
-pci_dev->cap.length += PCI_CAPABILITY_CONFIG_MSI_LENGTH;
}
#endif
#ifdef KVM_CAP_DEVICE_MSIX
@@ -1356,7 +1353,6 @@ static int assigned_device_pci_cap_init(PCIDevice
*pci_dev)
bar_nr = msix_table_entry & PCI_MSIX_BIR;
msix_table_entry &= ~PCI_MSIX_BIR;
dev->msix_table_addr = pci_region[bar_nr].base_addr + msix_table_entry;
-pci_dev->cap.length += PCI_CAPABILITY_CONFIG_MSIX_LENGTH;
}
#endif
#endif
diff --git a/hw/pci.c b/hw/pci.c
index cbe6fb7..1cf62b6 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1909,8 +1909,6 @@ int pci_add_capability(PCIDevice *pdev, uint8_t cap_id,
memset(pdev->cmask + offset, 0xFF, size);
pdev->config[PCI_STATUS] |= PCI_STATUS_CAP_LIST;
-pdev->cap.supported = 1;
-pdev->cap.start = pdev->cap.start ? MIN(pdev->cap.start, offset) : offset;
return offset;
}
@@ -1931,7 +1929,6 @@ void pci_del_capability(PCIDevice *pdev, uint8_t cap_id,
uint8_t size)
if (!pdev->config[PCI_CAPABILITY_LIST]) {
pdev->config[PCI_STATUS] &= ~PCI_STATUS_CAP_LIST;
-pdev->cap.start = pdev->cap.length = 0;
}
}
diff --git a/hw/pci.h b/hw/pci.h
index bd15b43..146f81d 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -220,8 +220,6 @@ struct PCIDevice {
/* Device capability configuration space */
struct {
-int supported;
-unsigned int start, length;
PCICapConfigReadFunc *config_read;
PCICapConfigWriteFunc *config_write;
} cap;
[Qemu-devel] [PATCH v3 9/9] device-assignment: pass through and stub more PCI caps
Some drivers depend on finding capabilities like power management,
PCI express/X, vital product data, or vendor specific fields. Now
that we have better capability support, we can pass more of these
tables through to the guest. Note that VPD and VNDR are direct pass
through capabilies, the rest are mostly empty shells with a few
writable bits where necessary.
It may be possible to consolidate dummy capabilities into common files
for other drivers to use, but I prefer to leave them here for now as
we figure out what bits to handle directly with hardware and what bits
are purely emulated.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 213 +---
1 files changed, 199 insertions(+), 14 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 832c236..cd62b5a 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -67,6 +67,9 @@ static void assigned_device_pci_cap_write_config(PCIDevice
*pci_dev,
uint32_t address,
uint32_t val, int len);
+static uint32_t assigned_device_pci_cap_read_config(PCIDevice *pci_dev,
+uint32_t address, int len);
+
static uint32_t assigned_dev_ioport_rw(AssignedDevRegion *dev_region,
uint32_t addr, int len, uint32_t *val)
{
@@ -370,6 +373,27 @@ static uint8_t assigned_dev_pci_read_byte(PCIDevice *d,
int pos)
return (uint8_t)assigned_dev_pci_read(d, pos, 1);
}
+static void assigned_dev_pci_write(PCIDevice *d, int pos, uint32_t val, int
len)
+{
+AssignedDevice *pci_dev = container_of(d, AssignedDevice, dev);
+ssize_t ret;
+int fd = pci_dev->real_device.config_fd;
+
+again:
+ret = pwrite(fd, &val, len, pos);
+if (ret != len) {
+ if ((ret < 0) && (errno == EINTR || errno == EAGAIN))
+ goto again;
+
+ fprintf(stderr, "%s: pwrite failed, ret = %zd errno = %d\n",
+ __func__, ret, errno);
+
+ exit(1);
+}
+
+return;
+}
+
static uint8_t pci_find_cap_offset(PCIDevice *d, uint8_t cap)
{
int id;
@@ -453,10 +477,13 @@ static uint32_t assigned_dev_pci_read_config(PCIDevice
*d, uint32_t address,
ssize_t ret;
AssignedDevice *pci_dev = container_of(d, AssignedDevice, dev);
+if (address > PCI_CONFIG_HEADER_SIZE && d->config_map[address]) {
+return assigned_device_pci_cap_read_config(d, address, len);
+}
+
if (address < 0x4 || (pci_dev->need_emulate_cmd && address == 0x4) ||
(address >= 0x10 && address <= 0x24) || address == 0x30 ||
-address == 0x34 || address == 0x3c || address == 0x3d ||
-(address > PCI_CONFIG_HEADER_SIZE && d->config_map[address])) {
+address == 0x34 || address == 0x3c || address == 0x3d) {
val = pci_default_read_config(d, address, len);
DEBUG("(%x.%x): address=%04x val=0x%08x len=%d\n",
(d->devfn >> 3) & 0x1F, (d->devfn & 0x7), address, val, len);
@@ -1251,36 +1278,72 @@ static void assigned_dev_update_msix(PCIDevice
*pci_dev, unsigned int ctrl_pos)
#endif
#endif
-static void assigned_device_pci_cap_write_config(PCIDevice *pci_dev, uint32_t
address,
+static uint32_t assigned_device_pci_cap_read_config(PCIDevice *pci_dev,
+uint32_t address, int len)
+{
+uint8_t cap, cap_id = pci_dev->config_map[address];
+
+switch (cap_id) {
+
+case PCI_CAP_ID_VPD:
+cap = pci_find_capability(pci_dev, cap_id);
+if (!ranges_overlap(address, len, cap, PCI_CAP_FLAGS)) {
+return assigned_dev_pci_read(pci_dev, address, len);
+}
+break;
+
+case PCI_CAP_ID_VNDR:
+cap = pci_find_capability(pci_dev, cap_id);
+if (!ranges_overlap(address, len, cap, PCI_CAP_FLAGS + 1)) {
+return assigned_dev_pci_read(pci_dev, address, len);
+}
+break;
+}
+
+return pci_default_read_config(pci_dev, address, len);
+}
+
+static void assigned_device_pci_cap_write_config(PCIDevice *pci_dev,
+ uint32_t address,
uint32_t val, int len)
{
-uint8_t cap_id = pci_dev->config_map[address];
+uint8_t cap, cap_id = pci_dev->config_map[address];
pci_default_write_config(pci_dev, address, val, len);
switch (cap_id) {
#ifdef KVM_CAP_IRQ_ROUTING
case PCI_CAP_ID_MSI:
#ifdef KVM_CAP_DEVICE_MSI
-{
-uint8_t cap = pci_find_capability(pci_dev, cap_id);
-if (ranges_overlap(address - cap, len, PCI_MSI_FLAGS, 1)) {
-assigned_dev_update_msi(pci_dev, cap + PCI_MSI_FLAGS);
-}
+cap = pci_find_capability(pci_dev, cap_id);
+if (ranges_overlap(address - cap, len, PCI_MSI_FLAGS, 1)) {
+assigned_dev_update_msi(pci_dev,
[Qemu-devel] [Bug 661696] Re: incomplete emulation of fstenv under TCG
Any news on this bug? -- incomplete emulation of fstenv under TCG https://bugs.launchpad.net/bugs/661696 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Steps to reproduce: 1) Install Windows (tried XP and 7) in qemu (tried qemu without kvm and qemu-kvm). 2) Get OllyDbg ( http://ollydbg.de/odbg200.zip ). 3) Use some Metasploit-encoded file, example included. It is not a virus! File was generated with Metasploit, command (if i remember it right): `msfpayload windows/exec cmd=notepad R | msfencode -e x86/shikata_ga_nai -t exe -o cmd_exec_notepad.shikata_ga_nai.exe`. 4) Launch the file under Windows in qemu, make sure it opens a notepad. 5) Open file under OllyDbg, run (F9) it there. It opens a notpad. Close OllyDbg. 6) Open file under OllyDbg, trace over (Ctrl+F12) it there. It fails with `Access violation when writing to [some address]`. Command: 316A 13, XOR DWORD PTR DS:[EDX+13],EBP Under native Windows, the trace over command works fine. Under VMware the trace works fine. Under VirtualBox it also fails (checked in the spring). $ qemu-kvm --version QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard
[Qemu-devel] [Bug 661696] Re: incomplete emulation of fstenv under TCG
The full testcase:
#include
extern void *x;
int main() {
int a;
asm volatile ("x: fldz\n\
push %%edx\n\
fnstenv -0xc(%%esp)\n\
pop %%edx\n" : "=d" (a) : : "memory");
printf ("%x %x\n", a, &x);
return 0;
}
$ gcc -m32 test.c -o test
$ ./test
80483ae 80483ae
$ ./qemu/i386-linux-user/qemu-i386 ./test
0 80483ae
Cleaned up .byte row.
--
incomplete emulation of fstenv under TCG
https://bugs.launchpad.net/bugs/661696
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
Steps to reproduce:
1) Install Windows (tried XP and 7) in qemu (tried qemu without kvm and
qemu-kvm).
2) Get OllyDbg ( http://ollydbg.de/odbg200.zip ).
3) Use some Metasploit-encoded file, example included.
It is not a virus!
File was generated with Metasploit, command (if i remember it right):
`msfpayload windows/exec cmd=notepad R | msfencode -e x86/shikata_ga_nai -t exe
-o cmd_exec_notepad.shikata_ga_nai.exe`.
4) Launch the file under Windows in qemu, make sure it opens a notepad.
5) Open file under OllyDbg, run (F9) it there. It opens a notpad. Close OllyDbg.
6) Open file under OllyDbg, trace over (Ctrl+F12) it there. It fails with
`Access violation when writing to [some address]`.
Command: 316A 13, XOR DWORD PTR DS:[EDX+13],EBP
Under native Windows, the trace over command works fine.
Under VMware the trace works fine.
Under VirtualBox it also fails (checked in the spring).
$ qemu-kvm --version
QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008
Fabrice Bellard
[Qemu-devel] Re: [PATCH v2] pc: disable the BOCHS BIOS panic port
On 11/16/2010 01:28 PM, Bernhard Kohl wrote: We have an OS which writes to port 0x400 when probing for special hardware. This causes an exit of the VM. With SeaBIOS this port isn't used anyway. Signed-off-by: Bernhard Kohl --- Changes v1 -> v2: Keep the ports silent. Don't print debug output if DEBUG_BIOS is enabled which might be confusing. --- hw/pc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/pc.c b/hw/pc.c index 3bf3862..76eabe8 100644 --- a/hw/pc.c +++ b/hw/pc.c @@ -434,8 +434,8 @@ static void bochs_bios_write(void *opaque, uint32_t addr, uint32_t val) /* Bochs BIOS messages */ case 0x400: case 0x401: -fprintf(stderr, "BIOS panic at rombios.c, line %d\n", val); -exit(1); +/* used to be panic, now unused */ +break; case 0x402: case 0x403: #ifdef DEBUG_BIOS Reviewed-By: Paolo Bonzini Paolo
Re: [Qemu-devel] [PATCH 12/16] scsi-generic: use plain ioctl
On Fri, 2010-11-19 at 19:39 +0100, Christoph Hellwig wrote: > On Thu, Nov 18, 2010 at 03:47:36PM +0100, Hannes Reinecke wrote: > > > > aio_ioctl is emulated anyway and currently broken. > > What's broken about it currently? Mm, I do not recall this being broken in the first place..? There was a single issue with megasas+bdrv_aio_ioctl() with WinXP (that did not appear with lsi53c895a) that was mentioned on the list earlier in the year that required a patch to use bdev_ioctl(), but last I recall Hannes had already fixed this in recent megasas.c code w/ 32-bit MSFT guests. Also, this is what I have been with scsi_generic.c and scsi_bsg.c into TCM_loop in my v0.12.5 megasas tree, and I am not observing any obvious issues with AIO IOCTLs for SG_IO/BSG into Linux guests. I will give AIO IOCTL ops a run with these on v2.6.37-rc2 lock-less KVM host mode <-> TCM_Loop to verify against the v0.12.5 megasas tree. > > > So better use 'normal' ioctl here as there are no benefits > > on using the emulated async I/O call. > > There are huge benefits. Without it the whole scsi command execution > happens synchronously in the qemu main loop, blocking guest execution. > Indeed. Using bdrv_ioctl() in execute_command() will very effectively disable TCQ > 1 into the backend struct scsi_device. Hannes, did you run into another scenario why you needed to do this for megasas..? Other than this one piece the rest of the series looks very good. Thank you for putting these pieces together. --nab
Re: [Qemu-devel] [PATCH 12/16] scsi-generic: use plain ioctl
On 20 November 2010 00:41, Nicholas A. Bellinger wrote: > On Fri, 2010-11-19 at 19:39 +0100, Christoph Hellwig wrote: >> On Thu, Nov 18, 2010 at 03:47:36PM +0100, Hannes Reinecke wrote: >> > >> > aio_ioctl is emulated anyway and currently broken. >> >> What's broken about it currently? > > Mm, I do not recall this being broken in the first place..? There > was a single issue with megasas+bdrv_aio_ioctl() with WinXP (that did > not appear with lsi53c895a) that was mentioned on the list earlier in > the year that required a patch to use bdev_ioctl(), but last I recall > Hannes had already fixed this in recent megasas.c code w/ 32-bit MSFT > guests. Also, this is what I have been with scsi_generic.c and > scsi_bsg.c into TCM_loop in my v0.12.5 megasas tree, and I am not > observing any obvious issues with AIO IOCTLs for SG_IO/BSG into Linux > guests. > > I will give AIO IOCTL ops a run with these on v2.6.37-rc2 lock-less KVM > host mode <-> TCM_Loop to verify against the v0.12.5 megasas tree. Could this AIO ioctl breakage perhaps be the one I fixed here? http://web.archiveorange.com/archive/v/1XS1vROmfC7dN9wYxsmt The patch is defintely in the latest git... it works fine for me with my scsi-generic MMC command patches.
[Qemu-devel] Has the 'clone' bug been fixed?
I just downloaded qemu-0.12.5, compiled as i386-linux-user, and tried
to run a simple "fork" test.
Qemu failed to emulate fork(), only left an "Invalid argument" message.
I checked linux-user/system.c, and noticed the "~(CSIGNAL |
CLONE_NPTL_FLAGS2))" flags.
But, since I'm not very professional in kernel development, I have no
idea about how to rectify it.
I also searched the mailing list and found similar problems, but no
one prompts a reasonable solution.
The following info may be helpful.
fork.c =
#include
main()
{
int pid;
if ((pid = fork()) > 0) /* parent */
{
printf("parent\n");
wait();
printf("parent done\n");
}
else if (pid == 0) /* child */
{
printf("child: %d\n", getpid());
sleep(1);
exit(0);
}
else
{
perror("fork");
}
}
# gcc for.c -o fork
#./i386-linux-user/qemu-i386 ./a.out
fork: Invalid argument
jgj:~/qemu-0.12.5$ uname -a
Linux server 2.6.30-2-686 #1 SMP Fri Dec 4 00:53:20 UTC 2009 i686 GNU/Linux
jgj:~/qemu-0.12.5$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.4.5-4' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-targets=all --with-arch-32=i586
--with-tune=generic --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-4)
[Qemu-devel] [Bug 661696] Re: incomplete emulation of fstenv under TCG
Example patch. Works only for FLDZ and only in -singlestep mode. Based on version 0.12.5. ** Patch added: "Patch. Works only for FLDZ and only in -singlestep mode . Based on 0.12.5." https://bugs.launchpad.net/qemu/+bug/661696/+attachment/1738944/+files/patch.diff -- incomplete emulation of fstenv under TCG https://bugs.launchpad.net/bugs/661696 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Steps to reproduce: 1) Install Windows (tried XP and 7) in qemu (tried qemu without kvm and qemu-kvm). 2) Get OllyDbg ( http://ollydbg.de/odbg200.zip ). 3) Use some Metasploit-encoded file, example included. It is not a virus! File was generated with Metasploit, command (if i remember it right): `msfpayload windows/exec cmd=notepad R | msfencode -e x86/shikata_ga_nai -t exe -o cmd_exec_notepad.shikata_ga_nai.exe`. 4) Launch the file under Windows in qemu, make sure it opens a notepad. 5) Open file under OllyDbg, run (F9) it there. It opens a notpad. Close OllyDbg. 6) Open file under OllyDbg, trace over (Ctrl+F12) it there. It fails with `Access violation when writing to [some address]`. Command: 316A 13, XOR DWORD PTR DS:[EDX+13],EBP Under native Windows, the trace over command works fine. Under VMware the trace works fine. Under VirtualBox it also fails (checked in the spring). $ qemu-kvm --version QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard
[Qemu-devel] [Bug 661696] Re: incomplete emulation of fstenv under TCG
This was just an example of how it could be done. $ ./qemu-0.12.5/i386-linux-user/qemu-i386 -singlestep ./test 80483b4 80483b4 -- incomplete emulation of fstenv under TCG https://bugs.launchpad.net/bugs/661696 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Steps to reproduce: 1) Install Windows (tried XP and 7) in qemu (tried qemu without kvm and qemu-kvm). 2) Get OllyDbg ( http://ollydbg.de/odbg200.zip ). 3) Use some Metasploit-encoded file, example included. It is not a virus! File was generated with Metasploit, command (if i remember it right): `msfpayload windows/exec cmd=notepad R | msfencode -e x86/shikata_ga_nai -t exe -o cmd_exec_notepad.shikata_ga_nai.exe`. 4) Launch the file under Windows in qemu, make sure it opens a notepad. 5) Open file under OllyDbg, run (F9) it there. It opens a notpad. Close OllyDbg. 6) Open file under OllyDbg, trace over (Ctrl+F12) it there. It fails with `Access violation when writing to [some address]`. Command: 316A 13, XOR DWORD PTR DS:[EDX+13],EBP Under native Windows, the trace over command works fine. Under VMware the trace works fine. Under VirtualBox it also fails (checked in the spring). $ qemu-kvm --version QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard
Re: [Qemu-devel] [PULL] vhost, netdev, e1000, pci
On 11/16/2010 07:16 AM, Michael S. Tsirkin wrote: Here are some fixes I collected in my tree. Please merge. The following changes since commit 5fc9cfedfa09199e10b5f9b67dcd286bfeae4f7a: Fold send_all() wrapper unix_write() into one function (2010-11-03 12:48:09 -0500) Pulled. Thanks. Regards, Anthony Liguori are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git for_anthony Alex Williamson (2): e1000: Fix TCP checksum overflow with TSO PCI: Bus number from the bridge, not the device Michael S. Tsirkin (3): tap: clear vhost_net backend on cleanup tap: make set_offload a nop after netdev cleanup pci: allow hotplug removal of cold-plugged devices hw/acpi_piix4.c | 14 ++ hw/e1000.c |5 - hw/pci.c| 13 - hw/pci.h| 10 +- hw/pcie.c | 10 ++ net/tap.c |7 ++- 6 files changed, 43 insertions(+), 16 deletions(-)
