date:20101125

On Fri, Nov 26, 2010 at 12:38:28AM +, Paul Brook wrote:
> > This patch enables USB UHCI global suspend/resume feature. The OS will
> > stop the HC once all ports are suspended. If there is activity on the
> > port(s), an interrupt signalling remote wakeup will be triggered.
> 
> I'm pretty sure this is wrong.  Suspend/resume works based on physical 
> topology, i.e. the resume notification should go to the the port/hub to which 
> the device is connected, not directly to the host controller.

If the host controller is in global suspend state, and resume is
received on any of its root hub ports (given that remote wakeup is
enabled for the given port), the system will be interrupted if interrupt
enable bit is set.

2.1.2 USB STATUS REGISTER
I/O Address: Base + (02-03h)
Default Value: h
Attribute: Read/Write Clear
size: 16 bits
This register indicates pending interrupts and various states of the
Host Controller

Resume Detect. The Host Controller sets this bit to 1 when it receives
a “RESUME” signal from a USB device. This is only valid if the Host
Controller is in a global suspend state (bit 3 of Command register = 1).

2.1.7.1 Behavior Under Global or Selective Suspend Scenarios

Resume will be recognized in the USBSTS register (bit 2) if resume is
received on a suspended or enabled port when the Host Controller is in
the global suspend state (USBCMD register bit 3 is set).

4.2.1 RESUME RECEIVED
This event indicates that the HC received a RESUME signal from a device
on the USB during a global suspend. If
this interrupt is enabled in the HC Interrupt Enable register, a
hardware interrupt will be signaled to the system
allowing the USB to be brought out of the suspend state and returned to
normal operation.

You are correct in that USB HUB emulation does not propagate resume, but
this does not make this patch incorrect.

Re: [Qemu-devel] [patch 0/2] USB UHCI global suspend / remote wakeup

> This patch enables USB UHCI global suspend/resume feature. The OS will
> stop the HC once all ports are suspended. If there is activity on the
> port(s), an interrupt signalling remote wakeup will be triggered.

I'm pretty sure this is wrong.  Suspend/resume works based on physical 
topology, i.e. the resume notification should go to the the port/hub to which 
the device is connected, not directly to the host controller.

Paul

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum

2010-11-25 Thread François Revol

>> the people we are addressing and we would like to bring together is from the 
>> QEMU emulation community.
>> We are interested in running different ISAs mainly under Linux and Windows 
>> versions. There is a huge additional
> 
> You're about the first person in 1/2 year that actually said you care about 
> Windows hosts. Windows support for example is currently on the verge of 
> getting deprecated, because we're lacking a maintainer.

I suppose windows users are not as much used/interested/involved into free 
software development workflows, and probably don't bother even lurking on the 
developer mailing lists. They only shout when something breaks :p

>> interest from industry for this part to QEMU for embedded systems/SW 
>> development. The focus we have chosen
>> for the DATE conference is SystemC integration with QEMU emulation since the 
>> embedded systems and SystemC
>> community meets at DATE so that we expect several people from them to 
>> attend. However, as already written, we
>> basically failed to find any indication for contact point for the emulation 
>> community. Any pointers are highly appreciated.
> 
> What audience and talks do you expect to receive? I'm still trying to get a 
> full picture on what topics people would be interested in the most.

From what I understood, since it's part of a scientific event, it's mostly 
toward the CS scientific community, where conferences have quite specific rules.

> The main contact point for any qemu discussions is the qemu-devel mailing 
> list. We're a community, so these things should happen as open as possible.

The scientific "community" is only starting to grasp the idea of open work, 
they are more used to do things in their lab and only reveal stuff when it's 
time to publish, and often do not even talk about what doesn't concern their 
direct subject research, so often they use/contribute/write software without 
others knowing.
(it was one of the main subjects of the fOSSa conference this month btw 
)

> It's very hard to draw a clean line. A lot of people from the "KVM community" 
> are active maintainers of several layers in qemu these days. For example the 
> block layer, PCI devices, PowerPC. The communities are merging. In the 
> mid-term, there shouldn't even be a qemu-kvm fork of qemu anymore. Everybody 
> who does device emulation would just work on upstream qemu, regardless of the 
> intents. The same is happening for the Xen folks too btw. They're slowly 
> moving back towards upstream qemu as well.

That's good to hear, I only found out about the beagleboard qemu fork months 
after having to stick to the verdex target while having a overo gumstix 
hardware :p

As long as patches do not take 3 years to get in like my wacom-tablet fixes ;)

> So according to my calendar, I should be free on that week. So if you're 
> eager to have a keynote/session from "upstream qemu folks", I'd certainly be 
> interested in doing this. Getting people to contribute back would be so 
> awesome. I'm still getting sad to see qemu getting forked so often (android, 
> vbox, ...).
> 
> If however, we find a better candidate (ideas, suggestions anyone?) to give a 
> general session, I'll gladly step back.

As I said to them, I'd be happy to talk about our usage patterns and needs with 
Haiku development, but I don't know enough of QEMU's internals to detail this.

> The one thing I am not willing to do however, is to pay a 400 € registration 
> fee to have the honor of giving a talk. That just doesn't seem right to me.

As I said, scientific conferences have a quite specific set of rules, one being 
you pay to talk :p
Usually the labs handle the expense for the attendees, because this gives them 
exposure.
It's quite different from the FOSDEM or RMLL confs with free entry and best 
effort speaker reimbursement by sponsors :D

>> What about doing some kind of QEMU-focussed meeting at FOSDEM 2011? That 
>> event is much more open to actual users than some academic/commercial 
>> conference with registration.
> 
> From the fosdem homepage:
> 
>  We would like to inform all interested parties that the call for devrooms is 
> running at its end.
>  Coming Saturday, 16 October at 23.59 the call for devrooms closes.

Again, the virtualization devroom should give quite a lot of opportunities.

François.

Re: [Qemu-devel] [PATCH 13/15] scsi: Implement alloc_req_iov callback

> I must say I'd like to get rid of the chunking transfer in scsi-disk.
> To have it for scsi-disk only is really pointless, as you can
> potentially send exactly the same commands via scsi-generic.
> So for scsi-generic to work properly qemu need to be able to
> allocate the _entire_ data buffer. And hence qemu _must_ be able to
> allocate the same buffer for the scsi-disk emulation.
> So any malloc space arguments don't really work out here.
> 
> By the same reasoning we could remove the chunking altogether;
> any HBA _must_ be capable of issuing the entire data (if issued via
> scsi-generic) even today. So I don't really buy the argument of
> chunking being required for large I/Os.

We've been over this before. Your logic is fundamentally flawed.

In many cases The HBA simply doesn't know where the data is going to go until 
after the command has been issued.  Issuing the command (which may fail) and 
setting up the buffer to receive the data are separate operations, and there 
may be guest visible state in between. Even if you assume the initial command 
is accepted successfully, the DMA buffer may be submitted in several parts. If 
the device response does not full all these parts then we should not be 
accessing the unused ones. And this is assuming your HBA is DMA capable to 
start with - a USB mass storage device almost certainly isn't.

Even if you do know the full DMA buffer ahead of time, there's no guarantee 
that you'll actually be able to map it all at once. You have to assume that 
bounce buffers are required, and only a small chunk of the ram can be mapped 
at any point.

Combine this with the fact that the guest may submit arbitrarily large 
requests and you need some form of chunking. IIRC the passthrough support 
ignores the linux interface already restricts you to relatively small 
requests.

Paul

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum

2010-11-25 Thread François Revol

>>> For the emulation side, things look different. I'm not aware of any 
>>> traction on the emulation side of Qemu. Getting people together for that 
>>> one is certainly lacking. I'm not sure I'm the right person to talk to 
>>> there. If nobody else steps up, I could barely play the role of someone who 
>>> knows what he's talking about, but I'm myself more of a virtualization 
>>> person too.
>> 
>> What about doing some kind of QEMU-focussed meeting at FOSDEM 2011? That 
>> event is much more open to actual users than some academic/commercial 
>> conference with registration.
> 
> That might indeed be interesting. Are the registrations open still?

Not for the devrooms proposals, no.
Last year I managed the AltOS devroom, it was really interesting. I actually 
tried to get some talks about QEMU but I never get any reply btw :^)
I'm way too busy this year to even think about it.

However the CFP from the selected devroom themselves are mostly open:
http://fosdem.org/2011/call_for_participation
It might be possible to sneak in the embedded devroom for example, or the 
virtualization one which seems to be quite on topic. They cite OSZOO topic, I 
might try a talk about haiku.php I suppose.

François.

[Qemu-devel] [Bug 427612] Re: kvm sends caps lock key up event twice

2010-11-25 Thread Benjamin Drung

Attached the uploaded debdiff for maverick.

** Patch added: "qemu-kvm_0.12.5+noroms-0ubuntu7.1.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/427612/+attachment/1745373/+files/qemu-kvm_0.12.5%2Bnoroms-0ubuntu7.1.debdiff

** Changed in: qemu-kvm (Ubuntu Maverick)
   Status: New => Fix Committed

-- 
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: New
Status in “libsdl1.2” package in Ubuntu: Invalid
Status in “qemu-kvm” package in Ubuntu: Fix Released
Status in “libsdl1.2” source package in Maverick: Invalid
Status in “qemu-kvm” source package in Maverick: Fix Committed
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] [Bug 427612] Re: kvm sends caps lock key up event twice

2010-11-25 Thread Launchpad Bug Tracker

This bug was fixed in the package qemu-kvm - 0.13.0+noroms-0ubuntu8

---
qemu-kvm (0.13.0+noroms-0ubuntu8) natty; urgency=low

  * Add caps-lock-key-up-event.patch to enable normal up/down events for
Caps-Lock and Num-Lock keys by setting SDL_DISABLE_LOCK_KEYS (which
requires SDL > 1.2.14). This fixes handling of capslock when capslock is
mapped to something else in host system. (LP: #427612)
 -- Benjamin DrungWed, 24 Nov 2010 21:46:44 +0100

** Changed in: qemu-kvm (Ubuntu)
   Status: In Progress => Fix Released

-- 
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: New
Status in “libsdl1.2” package in Ubuntu: Invalid
Status in “qemu-kvm” package in Ubuntu: Fix Released
Status in “libsdl1.2” source package in Maverick: Invalid
Status in “qemu-kvm” source package in Maverick: Fix Committed
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] CFP: 1st International QEMU Users Forum


On 25.11.2010, at 23:53, Andreas Färber wrote:

> Hello,
> 
> Am 25.11.2010 um 12:03 schrieb Alexander Graf:
> 
>> On 25.11.2010, at 11:30, wolfgang mueller wrote:
>> 
>>> For the future, we are currently not planning a second Users' Forum and we 
>>> are open to forward the organization of a second workshop
>>> to anybody else.
>>> 
>>> Why don't you simply take this event as a first trigger to organize an QEMU 
>>> conference for Developers and users.
>>> We can help you by forwarding the email addresses of some of the people. I 
>>> can also help you if you want.
>>> This can be the start of a real great effort with huge benefit to the 
>>> community.
>> 
>> As stated above, things are more difficult than that, but I agree. We do 
>> have annual KVM Forum meetings where we gather all the virtualization people 
>> from Qemu as well and talk about things there. The slides and recordings are 
>> publicly available, if you're interested: 
>> http://www.linux-kvm.org/page/KVM_Forum_2010. In general, people surrounding 
>> KVM meet quite a bit.
>> 
>> For the emulation side, things look different. I'm not aware of any traction 
>> on the emulation side of Qemu. Getting people together for that one is 
>> certainly lacking. I'm not sure I'm the right person to talk to there. If 
>> nobody else steps up, I could barely play the role of someone who knows what 
>> he's talking about, but I'm myself more of a virtualization person too.
> 
> What about doing some kind of QEMU-focussed meeting at FOSDEM 2011? That 
> event is much more open to actual users than some academic/commercial 
> conference with registration.

From the fosdem homepage:

  We would like to inform all interested parties that the call for devrooms is 
running at its end.
  Coming Saturday, 16 October at 23.59 the call for devrooms closes.

So I guess this idea came too late. We will have another KVM/Kernel track 
during the Chemnitzer Linux Tage next year, but that's not quite the same.


Alex

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum

Wolfgang,

On 25.11.2010, at 15:54, wolfgang mueller wrote:

> Alexander,
> the people we are addressing and we would like to bring together is from the 
> QEMU emulation community.
> We are interested in running different ISAs mainly under Linux and Windows 
> versions. There is a huge additional

You're about the first person in 1/2 year that actually said you care about 
Windows hosts. Windows support for example is currently on the verge of getting 
deprecated, because we're lacking a maintainer.

> interest from industry for this part to QEMU for embedded systems/SW 
> development. The focus we have chosen
> for the DATE conference is SystemC integration with QEMU emulation since the 
> embedded systems and SystemC
> community meets at DATE so that we expect several people from them to attend. 
> However, as already written, we
> basically failed to find any indication for contact point for the emulation 
> community. Any pointers are highly appreciated.

What audience and talks do you expect to receive? I'm still trying to get a 
full picture on what topics people would be interested in the most.

The main contact point for any qemu discussions is the qemu-devel mailing list. 
We're a community, so these things should happen as open as possible.

> Virtualization  is not of any interest in that workshop as there if course 
> already exists the KVM forum you refered to.
> I understood from the available information and contacts that there is a 
> common consensus that the QEMU
> virtualization community is denoted as "KVM community" and not as "QEMU 
> community" which also brings the
> difference to the point, right? My understanding so far is that "QEMU 
> community" refers mainly to the software emulation
> people part.

It's very hard to draw a clean line. A lot of people from the "KVM community" 
are active maintainers of several layers in qemu these days. For example the 
block layer, PCI devices, PowerPC. The communities are merging. In the 
mid-term, there shouldn't even be a qemu-kvm fork of qemu anymore. Everybody 
who does device emulation would just work on upstream qemu, regardless of the 
intents. The same is happening for the Xen folks too btw. They're slowly moving 
back towards upstream qemu as well.

> 
> PS: I have no idea about the number of people who are on the 
> qemu-devel@nongnu.org list we are cc'ing.
> I hope there are not too many and that they are interested in our 
> communication. Otherwise, I apologize.

As long as you stick to inline answers and don't top post, I think they'll be 
very interested in reading this. By CC'ing qemu-devel we're making sure the 
right people get to read this. I'd assume the major reason we haven't had too 
many people jump into the discussion as well is because they're all eating 
turkeys atm :).

So according to my calendar, I should be free on that week. So if you're eager 
to have a keynote/session from "upstream qemu folks", I'd certainly be 
interested in doing this. Getting people to contribute back would be so 
awesome. I'm still getting sad to see qemu getting forked so often (android, 
vbox, ...).

If however, we find a better candidate (ideas, suggestions anyone?) to give a 
general session, I'll gladly step back.

The one thing I am not willing to do however, is to pay a 400 € registration 
fee to have the honor of giving a talk. That just doesn't seem right to me.

Alex

[Qemu-devel] [Bug 681613] Re: Failed to convert vmdk on MacOSX ppc

2010-11-25 Thread Masaki Muranaka


** Patch added: "0001-Enable-to-create-vmdk-headers-on-big-endian-machine.patch"
   
https://bugs.launchpad.net/bugs/681613/+attachment/1745371/+files/0001-Enable-to-create-vmdk-headers-on-big-endian-machine.patch

-- 
Failed to convert vmdk on MacOSX ppc
https://bugs.launchpad.net/bugs/681613
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
qemu-img -O vmdk raw-file.dd vmdk-file.vmdk
will failed with error.
This issue will be occured on all big endian environment.

[Qemu-devel] [Bug 681613] [NEW] Failed to convert vmdk on MacOSX ppc

2010-11-25 Thread Masaki Muranaka

Public bug reported:

qemu-img -O vmdk raw-file.dd vmdk-file.vmdk
will failed with error.
This issue will be occured on all big endian environment.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
Failed to convert vmdk on MacOSX ppc
https://bugs.launchpad.net/bugs/681613
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
qemu-img -O vmdk raw-file.dd vmdk-file.vmdk
will failed with error.
This issue will be occured on all big endian environment.

[Qemu-devel] Re: [Patch] Small fix for qemu APIC for Mac OS X support


On 25.11.2010, at 22:03, adq wrote:

> On 25 November 2010 11:46, Jan Kiszka  wrote:
>> Am 24.11.2010 12:00, Alexander Graf wrote:
>> According to to the Intel IA-32 Software Developers Manual Vol 3 page
>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>> 
>> Signed-off-by: Andrew de Quincey 
>> 
>> diff --git a/hw/apic.c b/hw/apic.c
>> index 5f4a87c..20304e0 100644
>> --- a/hw/apic.c
>> +++ b/hw/apic.c
>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
>> target_phys_addr_t addr)
>> val = s->id << 24;
>> break;
>> case 0x03: /* version */
>> -val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
>> +val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
> 
> What exactly changed between the versions? Did new registers get 
> introduced or subtle behavior change? Is there some proper documentation 
> on the changed between the apic versions?
 
 I've been trying to find out; I'm still searching intel's docs to find
 an 0x11 version to compare with :(
>>> 
>>> Please try very hard. I haven't found anything myself either yet, but 
>>> without a spec it's hard to justify these changes upstream :(.
>>> 
 The failure mode is that mac os X SL whines about the APIC being an
 unexpected version (0x11) and it wants 0x14 as a minimum.
>>> 
>>> Yup, I remember that issue. To really make this all useful, we also need to 
>>> change the numbers in KVM though.
>> 
>> Also, the version has to be set depending on the emulated CPU (even more
>> when there will be emulation differences).
> 
> Indeed. However, I've just been comparing the two docs (and yes it IS
> a huge pain in the bum!).
> 
> The differences between the pentium/P6 (0x11 "APIC") and pentium4/xeon
> (0x14 "xAPIC") so far are:
> * LVT themal sensor 0xfee0330 is new in xAPIC -- this is already
> implemented in hw/apic.c
> * APIC ID register is 8 bits in xAPIC, 4 bits in APIC (top 4 are
> undefined) -- already 8 bit wide in hw/apic.c
> * APIC LVT count should be 4 in APIC, 6 in xAPIC -- already hardcoded
> to 6 in hw/apic.c
> * Spurious interrupt vector should have the lower 4 bits hardcoded to
> 1 in APIC -- this is not done in hw/apic.c - they're modifable.
> * Base address of LAPIC can be changed using an MSR in xAPIC,
> suppposedly not possible in APIC - hw/apic.c allows it no matter what.

Very interesting indeed.

> 
> (I'm still reading)
> 
> From what I can see hw/apic.c already unconditionally supports all the
> features of the newer APICs anyway, and any changes are really just
> incremental tweaks.

Yes, if you can prove that the one we're emulating basically already is an 
xAPIC and the only difference is the incorrect version, then I'd completely Ack 
the patch.

> 
> The other major difference between APIC and xAPIC is how they talk to
> each other in hardware: APIC has an APIC bus, xAPIC uses the system
> bus. I suspect this isn't a concern for emulated hardware though...

The internal bus structure doesn't matter to the emulation, no :).


Alex

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support


On 25.11.2010, at 21:24, adq wrote:

> On 24 November 2010 11:00, Alexander Graf  wrote:
>> 
>> On 24.11.2010, at 03:40, adq wrote:
>> 
>>> On 23 November 2010 23:41, Alexander Graf  wrote:
 
 On 23.11.2010, at 22:25, adq wrote:
 
> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
> loads successfully (with appropriate kexts, applesmc ain't hooked up
> properly yet I see unfortunately).
 )
 AppleSMC emulation is upstream, but the ACPI entries are missing. Once you 
 add those, all is fine.
>>> 
>>> Ah yeah, I've just this minute added the DSDT entry from your patch
>>> for the SMC device and it now works with the vanilla SMC driver. Nice
>>> work!
>>> 
>>> It *is* annoying that IASL now erroneously(?) complains about the
>>> hypen in "Name (_CID, "smc-napa")" though.
>>> 
>>> Adding the HPET DSDT data causes it  to claim it can't support the
>>> hardware (and a zillion more DSDT errors); I'll have a play about with
>>> that (perhaps its just the new DSDT validation stuff)..
>> 
>> Interesting. I was also thinking that maybe we can leverage overriding 
>> mechanisms that are already available. Maybe it's possible to squeeze the 
>> HPET node into an SSDT. Maybe we need to override the whole DSDT from the 
>> command line.
> 
> The HPET issue was actually because the seabios already contained an
> HPET definition and mac os X didn't know quite what to do with a CPU
> with two APICs :)

HPET == APIC? And why would it have two?

> 
> I removed the spare HPET def, and it doesn't moan about unsupported
> hardware anymore.
> 
> However AppleIntelCPUPowerManagement dies with a bad opcode error and
> no useful information on why.. I get the impression that worked OK
> unmodified with your original suite of patches? Obviously if you
> disable the KEXT its no longer a problem, but it would be nice not to
> have to.

Are you using KVM? To have that kext do something reasonable, we need major 
tweaks in KVM. For simple use cases, ignoring some MSRs should be enough. Qemu 
ignores unknown MSRs by default.

> 10.6.5 still doesn't start the GUI though, and I've still no idea why yet.

Could be anything really :(. I assume you're already starting with -v? Mac OS X 
also stores crash dumps somewhere, so you could reboot into single user mode 
(-s) and check if you can make sense of anything there.

> Also, mac os x reports that an emulated e1000 device has an all-zero
> MAC address. I'm going to look into this first since the rtl8139 only
> has 32 bit drivers it seems.

Yeah, the e1000 didn't work for me either. The rtl8139 back then didn't work 
100% because of its broken timer implementation, but there should have been 
some fixes for that in the meantime. At least for the rtl8139 the driver was 
published open source on the apple developer web page. Not sure if that's still 
the case with 10.6.


Alex

Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk

On Thu, Nov 25, 2010 at 11:46:40AM -0800, Jeremy Fitzhardinge wrote:
> The latter.  There's a question over whether WRITE_BARRIER really
> supports empty barriers, since it appears that none of the existing
> backends implement it correctly - but on the other hand, the kernel
> blkback code does *try* to implement it, even though it fails.  This
> change makes empty WRITE_BARRIERS work in qemu, which is helpful because
> the upstream blkfront tries to use them.

So far so good.

> 
> But WRITE_BARRIER is fundamentally suboptimal for Linux's needs because
> it is a fully ordered barrier operation.  What Linux needs is a simple
> FLUSH operation which just makes sure that previously completed writes
> are fully flushed out of any caches and buffers and are really on
> durable storage.  It has no ordering requirements, so it doesn't prevent
> subsequent writes from being handled while the flush is going on.
> 
> Christoph is therefore recommending that we add a specific FLUSH
> operation to the protocol with these properties so that we can achieve
> the best performance.  But if the backend lacks FLUSH, we still need a
> reliable WRITE_BARRIER.

The problem is that qemu currently implements WRITE_BARRIER incorrectly,
empty or not.  The Linux barrier primitive, which appears to extent 1:1
to Xen implies ordering semantics, which the blkback implementation
implementes by translating the write barrier back to a bio with the
barrier bit set.   But the qemu backend does not impose any ordering,
so it gives you different behaviour from blkback.  Is there any formal
specification of the Xen block protocol?

In the end the empty WRITE_BARRIER after this patch is equivalent to a
flush, which is fine for that particular command.  The problem is that
a small minority of Linux filesystems actually relied on the ordering
semantics of a non-empty WRITE_BARRIER command, which qemu doesn't
respect.

But the patch doesn't make anything worse by also accepting empty
barrier writes, so I guess it's fine.  My initial reply was just
supposed to be a reminder about the big dragon lurking here.

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum


On 25.11.2010, at 23:53, Andreas Färber wrote:

> Hello,
> 
> Am 25.11.2010 um 12:03 schrieb Alexander Graf:
> 
>> On 25.11.2010, at 11:30, wolfgang mueller wrote:
>> 
>>> For the future, we are currently not planning a second Users' Forum and we 
>>> are open to forward the organization of a second workshop
>>> to anybody else.
>>> 
>>> Why don't you simply take this event as a first trigger to organize an QEMU 
>>> conference for Developers and users.
>>> We can help you by forwarding the email addresses of some of the people. I 
>>> can also help you if you want.
>>> This can be the start of a real great effort with huge benefit to the 
>>> community.
>> 
>> As stated above, things are more difficult than that, but I agree. We do 
>> have annual KVM Forum meetings where we gather all the virtualization people 
>> from Qemu as well and talk about things there. The slides and recordings are 
>> publicly available, if you're interested: 
>> http://www.linux-kvm.org/page/KVM_Forum_2010. In general, people surrounding 
>> KVM meet quite a bit.
>> 
>> For the emulation side, things look different. I'm not aware of any traction 
>> on the emulation side of Qemu. Getting people together for that one is 
>> certainly lacking. I'm not sure I'm the right person to talk to there. If 
>> nobody else steps up, I could barely play the role of someone who knows what 
>> he's talking about, but I'm myself more of a virtualization person too.
> 
> What about doing some kind of QEMU-focussed meeting at FOSDEM 2011? That 
> event is much more open to actual users than some academic/commercial 
> conference with registration.

That might indeed be interesting. Are the registrations open still?


Alex

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum

2010-11-25 Thread Andreas Färber


Hello,

Am 25.11.2010 um 12:03 schrieb Alexander Graf:


On 25.11.2010, at 11:30, wolfgang mueller wrote:

For the future, we are currently not planning a second Users' Forum  
and we are open to forward the organization of a second workshop

to anybody else.

Why don't you simply take this event as a first trigger to organize  
an QEMU conference for Developers and users.
We can help you by forwarding the email addresses of some of the  
people. I can also help you if you want.
This can be the start of a real great effort with huge benefit to  
the community.


As stated above, things are more difficult than that, but I agree.  
We do have annual KVM Forum meetings where we gather all the  
virtualization people from Qemu as well and talk about things there.  
The slides and recordings are publicly available, if you're  
interested: http://www.linux-kvm.org/page/KVM_Forum_2010. In  
general, people surrounding KVM meet quite a bit.


For the emulation side, things look different. I'm not aware of any  
traction on the emulation side of Qemu. Getting people together for  
that one is certainly lacking. I'm not sure I'm the right person to  
talk to there. If nobody else steps up, I could barely play the role  
of someone who knows what he's talking about, but I'm myself more of  
a virtualization person too.


What about doing some kind of QEMU-focussed meeting at FOSDEM 2011?  
That event is much more open to actual users than some academic/ 
commercial conference with registration.


Andreas

[Qemu-devel] Re: [Patch] Small fix for qemu APIC for Mac OS X support

2010-11-25 Thread adq

On 25 November 2010 11:46, Jan Kiszka  wrote:
> Am 24.11.2010 12:00, Alexander Graf wrote:
> According to to the Intel IA-32 Software Developers Manual Vol 3 page
> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>
> Signed-off-by: Andrew de Quincey 
>
> diff --git a/hw/apic.c b/hw/apic.c
> index 5f4a87c..20304e0 100644
> --- a/hw/apic.c
> +++ b/hw/apic.c
> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
> target_phys_addr_t addr)
>         val = s->id << 24;
>         break;
>     case 0x03: /* version */
> -        val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
> +        val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */

 What exactly changed between the versions? Did new registers get 
 introduced or subtle behavior change? Is there some proper documentation 
 on the changed between the apic versions?
>>>
>>> I've been trying to find out; I'm still searching intel's docs to find
>>> an 0x11 version to compare with :(
>>
>> Please try very hard. I haven't found anything myself either yet, but 
>> without a spec it's hard to justify these changes upstream :(.
>>
>>> The failure mode is that mac os X SL whines about the APIC being an
>>> unexpected version (0x11) and it wants 0x14 as a minimum.
>>
>> Yup, I remember that issue. To really make this all useful, we also need to 
>> change the numbers in KVM though.
>
> Also, the version has to be set depending on the emulated CPU (even more
> when there will be emulation differences).

Indeed. However, I've just been comparing the two docs (and yes it IS
a huge pain in the bum!).

The differences between the pentium/P6 (0x11 "APIC") and pentium4/xeon
(0x14 "xAPIC") so far are:
* LVT themal sensor 0xfee0330 is new in xAPIC -- this is already
implemented in hw/apic.c
* APIC ID register is 8 bits in xAPIC, 4 bits in APIC (top 4 are
undefined) -- already 8 bit wide in hw/apic.c
* APIC LVT count should be 4 in APIC, 6 in xAPIC -- already hardcoded
to 6 in hw/apic.c
* Spurious interrupt vector should have the lower 4 bits hardcoded to
1 in APIC -- this is not done in hw/apic.c - they're modifable.
* Base address of LAPIC can be changed using an MSR in xAPIC,
suppposedly not possible in APIC - hw/apic.c allows it no matter what.

(I'm still reading)

>From what I can see hw/apic.c already unconditionally supports all the
features of the newer APICs anyway, and any changes are really just
incremental tweaks.

The other major difference between APIC and xAPIC is how they talk to
each other in hardware: APIC has an APIC bus, xAPIC uses the system
bus. I suspect this isn't a concern for emulated hardware though...

[Qemu-devel] Re: [PATCH 14/15] megasas: LSI Megaraid SAS emulation

2010-11-25 Thread Sebastian Herbszt


Hannes Reinecke wrote:

+static int megasas_scsi_init(PCIDevice *dev)
+{
+MPTState *s = DO_UPCAST(MPTState, dev, dev);
+uint8_t *pci_conf;
+int i;
+
+pci_conf = s->dev.config;
+
+/* PCI Vendor ID (word) */
+pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_LSI_LOGIC);
+/* PCI device ID (word) */
+pci_config_set_device_id(pci_conf,  PCI_DEVICE_ID_LSI_SAS1078);
+/* PCI subsystem ID */
+pci_set_word(&pci_conf[PCI_SUBSYSTEM_VENDOR_ID], 0x1000);


PCI_VENDOR_ID_LSI_LOGIC


+pci_set_word(&pci_conf[PCI_SUBSYSTEM_ID], 0x1013);


What is 0x1013?


+/* PCI base class code */
+pci_config_set_class(pci_conf, PCI_CLASS_STORAGE_RAID);
+
+/* PCI latency timer = 0 */
+pci_conf[0x0d] = 0;


PCI_LATENCY_TIMER


+/* Interrupt pin 1 */
+pci_conf[0x3d] = 0x01;


pci_config_set_interrupt_pin()

Sebastian

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

2010-11-25 Thread adq

On 25 November 2010 11:28, Isaku Yamahata  wrote:
> On Wed, Nov 24, 2010 at 02:08:16PM +, adq wrote:
>> > Interesting. I was also thinking that maybe we can leverage overriding 
>> > mechanisms that are already available. Maybe it's possible to squeeze the 
>> > HPET node into an SSDT. Maybe we need to override the whole DSDT from the 
>> > command line.
>>
>> We'll definitely need to override the DSDT for the applesmc device. I
>> was thinking something along the lines of an additional DSDT binary
>> supplied with QEMU for use when emulating apple hardware as you
>> suggest.
>
> The patches for qemu and seabios have been floating around.
> I wrote them for Q35 chipset support, but no one has gotten interested in it.
> But now, you are there. I'm willing to rebase/resend them.

I'd definitely be interested to see those!

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

2010-11-25 Thread adq

On 24 November 2010 11:00, Alexander Graf  wrote:
>
> On 24.11.2010, at 03:40, adq wrote:
>
>> On 23 November 2010 23:41, Alexander Graf  wrote:
>>>
>>> On 23.11.2010, at 22:25, adq wrote:
>>>
 This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
 loads successfully (with appropriate kexts, applesmc ain't hooked up
 properly yet I see unfortunately).
>>> )
>>> AppleSMC emulation is upstream, but the ACPI entries are missing. Once you 
>>> add those, all is fine.
>>
>> Ah yeah, I've just this minute added the DSDT entry from your patch
>> for the SMC device and it now works with the vanilla SMC driver. Nice
>> work!
>>
>> It *is* annoying that IASL now erroneously(?) complains about the
>> hypen in "Name (_CID, "smc-napa")" though.
>>
>> Adding the HPET DSDT data causes it  to claim it can't support the
>> hardware (and a zillion more DSDT errors); I'll have a play about with
>> that (perhaps its just the new DSDT validation stuff)..
>
> Interesting. I was also thinking that maybe we can leverage overriding 
> mechanisms that are already available. Maybe it's possible to squeeze the 
> HPET node into an SSDT. Maybe we need to override the whole DSDT from the 
> command line.

The HPET issue was actually because the seabios already contained an
HPET definition and mac os X didn't know quite what to do with a CPU
with two APICs :)

I removed the spare HPET def, and it doesn't moan about unsupported
hardware anymore.

However AppleIntelCPUPowerManagement dies with a bad opcode error and
no useful information on why.. I get the impression that worked OK
unmodified with your original suite of patches? Obviously if you
disable the KEXT its no longer a problem, but it would be nice not to
have to.

10.6.5 still doesn't start the GUI though, and I've still no idea why yet.

Also, mac os x reports that an emulated e1000 device has an all-zero
MAC address. I'm going to look into this first since the rtl8139 only
has 32 bit drivers it seems.

Re: [Qemu-devel] [Bug 427612] Re: kvm sends caps lock key up event twice

2010-11-25 Thread Stefan Weil

Am 24.11.2010 22:44, schrieb Benjamin Drung:

Attached a new version of my patch. You find two branches linked to this
bug for maverick and natty. The patch sets SDL_DISABLE_LOCK_KEYS and get
rid of the complete workaround in qemu-kvm. This requires SDL >= 1.2.14.

For newer versions of SDL (those which use SDL_DISABLE_LOCK_KEYS
to disable special handling of the lock keys), your patch looks ok.
It is a working solution for maintainers of the latest Ubuntu releases.

But what about older versions? For those, your patch will make QEMU's
keyboard emulation unusable. Most older versions don't know
SDL_DISABLE_LOCK_KEYS. As far as I know, some SDL versions (from Debian
and Ubuntu) even used SDL_DISABLE_LOCK_KEYS with an inverted meaning.

I don't think we can simply ignore old or incompatible versions of SDL.
Therefore I suggest adding a runtime version check, so the emulation
can either use the old code (SDL < 1.2.14) or your new code (SDL >= 1.2.14).

The crucial point is whether "old" versions must be supported or not.
This is something which the QEMU community should decide.

Stefan Weil wrote:

The patch might fix part of the problem, but there remain more issues:

* SDL also sends an SDL_KEYUP event for caps lock when the
environment variable SDL_DISABLE_LOCK_KEYS is set.
This mode is very useful but currently unsupported by qemu/kvm.

Addressed by new patch.

* Num lock and caps lock are handled in a similar way by SDL.
The patch only handles caps lock. Maybe this is less important
because keyboard layouts which remap num lock are rare
(I don't know any).

Addressed by new patch.

* The keyboard status LEDs and the qemu client's keyboard status
can become unsynchronized if the input focus changes from qemu
to other applications.

Is this a regression of my patch or is it the case for the unpatched
qemu too?

That is no regression, but a weakness which existed from the
beginning. Your patch neither makes it better nor makes it worse.

** Patch added: "caps-lock-key-up-event-v2.patch"
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/427612/+attachment/1743919/+files/caps-lock-key-up-event-v2.patch

Just a small remark:
Inline patches (instead of links) are preferred on qemu-devel
because they make reading easier, and it's also easier for reviewers
to add comments.

Regards,
Stefan

Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk

2010-11-25 Thread Jeremy Fitzhardinge

On 11/25/2010 11:30 AM, Ian Jackson wrote:
> Christoph Hellwig writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and 
> qemu-xen: support empty write barriers in xen_disk"):
>> On Wed, Nov 24, 2010 at 10:18:40AM -0800, Jeremy Fitzhardinge wrote:
>>> Linux wants is a useful thing to do and implement (especially since it
>>> amounts to standardising the ?BSD extension).  I'm not sure of their
>>> precise semantics (esp WRT ordering), but I think its already OK.
>> The nice bit is that a pure flush does not imply any odering at all.
>> Which is how the current qemu driver implements the barrier requests
>> anyway, so that needs some fixing.
> Thanks for your comments.  Does that mean, though, that Stefano's
> patch is actually making the situation worse, or simply that it isn't
> making it as good as it should be ?

The latter.  There's a question over whether WRITE_BARRIER really
supports empty barriers, since it appears that none of the existing
backends implement it correctly - but on the other hand, the kernel
blkback code does *try* to implement it, even though it fails.  This
change makes empty WRITE_BARRIERS work in qemu, which is helpful because
the upstream blkfront tries to use them.

But WRITE_BARRIER is fundamentally suboptimal for Linux's needs because
it is a fully ordered barrier operation.  What Linux needs is a simple
FLUSH operation which just makes sure that previously completed writes
are fully flushed out of any caches and buffers and are really on
durable storage.  It has no ordering requirements, so it doesn't prevent
subsequent writes from being handled while the flush is going on.

Christoph is therefore recommending that we add a specific FLUSH
operation to the protocol with these properties so that we can achieve
the best performance.  But if the backend lacks FLUSH, we still need a
reliable WRITE_BARRIER.

(But it would be very sad that if, in practice, most backends in the
field fail empty WRITE_BARRIER operations, leaving guests with no
mechanism to force writes to stable storage.  In that case I guess we'll
need to look at some other hacky thing to try and make it work...)

J

Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk

2010-11-25 Thread Ian Jackson

Christoph Hellwig writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and 
qemu-xen: support empty write barriers in xen_disk"):
> On Wed, Nov 24, 2010 at 10:18:40AM -0800, Jeremy Fitzhardinge wrote:
> > Linux wants is a useful thing to do and implement (especially since it
> > amounts to standardising the ?BSD extension).  I'm not sure of their
> > precise semantics (esp WRT ordering), but I think its already OK.
> 
> The nice bit is that a pure flush does not imply any odering at all.
> Which is how the current qemu driver implements the barrier requests
> anyway, so that needs some fixing.

Thanks for your comments.  Does that mean, though, that Stefano's
patch is actually making the situation worse, or simply that it isn't
making it as good as it should be ?

If it's an improvement it should be applied it even if it's not
perfect, and it sounds to me like we don't want to wait for the more
complicated discussion to finish and produce code ?

Ian.

Re: [Qemu-devel] [PATCH REPOST] fw_cfg: Allow guest to read kernel etc via fast, synchronous "DMA"-type operation.

> I rebased this and rechecked it.  The *total* libguestfs boot time
> goes from 86 seconds down to 7.7 seconds.  The proportion of that
> attributable to loading the appliance is approximately 650 times [sic]
> faster.

Nack.

> +/* Target address and size for DMA operations.  This is only used
> + * during boot and across 32 and 64 bit architectures, so only writes
> + * to lower 4GB addresses are supported.
> + */
> +static uint32_t dma_addr = 0;
> +static uint32_t dma_size = 0;

Storing per-device state in global variables is just plain wrong.
Limiting addresses to 32-bits is just lame. You can do better.
It's also completely broken on big-endian hosts.

Paul

[Qemu-devel] [PATCH 4/4] block_int.h: Provide documentation for common block qdev properties

Document the options common to all block devices.

This comes from Kevin.

Signed-off-by: Amit Shah 
CC: Kevin Wolf 
---
 block_int.h |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/block_int.h b/block_int.h
index 88a2546..867c4e2 100644
--- a/block_int.h
+++ b/block_int.h
@@ -243,12 +243,14 @@ static inline unsigned int 
get_physical_block_exp(BlockConf *conf)
 }
 
 #define DEFINE_BLOCK_PROPERTIES(_state, _conf)  \
-DEFINE_PROP_DRIVE("drive", _state, _conf.bs, ""),   \
-DEFINE_PROP_UINT16("logical_block_size", _state,\
-   _conf.logical_block_size, 512, ""),  \
+DEFINE_PROP_DRIVE("drive", _state, _conf.bs, "The host drive details, 
specified by the -drive parameter"), \
+DEFINE_PROP_UINT16("logical_block_size", _state, _conf.logical_block_size, 
\
+   512, "Logical sector size of the disk"), \
 DEFINE_PROP_UINT16("physical_block_size", _state,   \
-   _conf.physical_block_size, 512, ""), \
-DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0, ""), \
-DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0, "")
+   _conf.physical_block_size, 512, "Physical sector size 
of the disk"), \
+DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0, \
+   "Minimal size for IO requests in bytes. Must be a power 
of two that is 512 or greater."), \
+DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0, \
+   "Size for IO requests that provides optimal performance 
(in bytes). Must be a power of two that is 512 or greater.")
 
 #endif /* BLOCK_INT_H */
-- 
1.7.3.2

[Qemu-devel] [PATCH 3/4] net.h: Add description fields for qdev properites

This results in an output like:

$ ./x86_64-softmmu/qemu-system-x86_64 -device virtio-net-pci,?

...

virtio-net-pci.mac=macaddr, The MAC address for the NIC.
virtio-net-pci.vlan=vlan, The VLAN to associate the NIC with.
virtio-net-pci.netdev=netdev, The peer net device to associate with this 
virtual NIC.

Signed-off-by: Amit Shah 
---
 net.h |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/net.h b/net.h
index 25e7968..b3be73c 100644
--- a/net.h
+++ b/net.h
@@ -20,9 +20,12 @@ typedef struct NICConf {
 } NICConf;
 
 #define DEFINE_NIC_PROPERTIES(_state, _conf)\
-DEFINE_PROP_MACADDR("mac",   _state, _conf.macaddr, ""),\
-DEFINE_PROP_VLAN("vlan", _state, _conf.vlan, ""),   \
-DEFINE_PROP_NETDEV("netdev", _state, _conf.peer, "")
+DEFINE_PROP_MACADDR("mac",   _state, _conf.macaddr, \
+"The MAC address for the NIC."),\
+DEFINE_PROP_VLAN("vlan", _state, _conf.vlan,\
+ "The VLAN to associate the NIC with."),\
+DEFINE_PROP_NETDEV("netdev", _state, _conf.peer,\
+   "The peer net device to associate with this virtual 
NIC.")
 
 /* VLANs support */
 
-- 
1.7.3.2

[Qemu-devel] [PATCH 2/4] virtio-serial: Add description fields for qdev properties

Document the parameters for the virtserialport and virtioconsole
devices.

Example:

$ ./x86_64-softmmu/qemu-system-x86_64 -device virtserialport,?
virtserialport.nr=uint32, The 'number' for the port for \
predictable port numbers. Use this to spawn ports if you \
plan to migrate the guest.

virtserialport.chardev=chr, The chardev to associate this port with.

virtserialport.name=string, Name for the port that's exposed to \
the guest for port discovery.

Signed-off-by: Amit Shah 
---
 hw/virtio-console.c |   17 ++---
 hw/virtio-serial.h  |   13 +
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index ccd277a..8a99a99 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -95,11 +95,13 @@ static VirtIOSerialPortInfo virtconsole_info = {
 .init  = virtconsole_initfn,
 .exit  = virtconsole_exitfn,
 .qdev.props = (Property[]) {
-DEFINE_PROP_UINT8("is_console", VirtConsole, port.is_console, 1, ""),
+DEFINE_PROP_UINT8("is_console", VirtConsole, port.is_console, 1,
+  PROP_VIRTSERIAL_IS_CONSOLE_DESC),
 DEFINE_PROP_UINT32("nr", VirtConsole, port.id, VIRTIO_CONSOLE_BAD_ID,
-   ""),
-DEFINE_PROP_CHR("chardev", VirtConsole, chr, ""),
-DEFINE_PROP_STRING("name", VirtConsole, port.name, ""),
+   PROP_VIRTSERIAL_NR_DESC),
+DEFINE_PROP_CHR("chardev", VirtConsole, chr, PROP_VIRTSERIAL_CHR_DESC),
+DEFINE_PROP_STRING("name", VirtConsole, port.name,
+   PROP_VIRTSERIAL_NAME_DESC),
 DEFINE_PROP_END_OF_LIST(),
 },
 };
@@ -133,9 +135,10 @@ static VirtIOSerialPortInfo virtserialport_info = {
 .exit  = virtconsole_exitfn,
 .qdev.props = (Property[]) {
 DEFINE_PROP_UINT32("nr", VirtConsole, port.id, VIRTIO_CONSOLE_BAD_ID,
-   ""),
-DEFINE_PROP_CHR("chardev", VirtConsole, chr, ""),
-DEFINE_PROP_STRING("name", VirtConsole, port.name, ""),
+   PROP_VIRTSERIAL_NR_DESC),
+DEFINE_PROP_CHR("chardev", VirtConsole, chr, PROP_VIRTSERIAL_CHR_DESC),
+DEFINE_PROP_STRING("name", VirtConsole, port.name,
+   PROP_VIRTSERIAL_NAME_DESC),
 DEFINE_PROP_END_OF_LIST(),
 },
 };
diff --git a/hw/virtio-serial.h b/hw/virtio-serial.h
index ff08c40..187d5e4 100644
--- a/hw/virtio-serial.h
+++ b/hw/virtio-serial.h
@@ -57,6 +57,19 @@ struct virtio_console_control {
 
 /* == In-qemu interface == */
 
+#define PROP_VIRTSERIAL_IS_CONSOLE_DESC \
+"An hvc console will be spawned in the guest if this is set."
+
+#define PROP_VIRTSERIAL_NR_DESC \
+"The 'number' for the port for predictable port numbers. Use this to " \
+"spawn ports if you plan to migrate the guest."
+
+#define PROP_VIRTSERIAL_CHR_DESC\
+"The chardev to associate this port with."
+
+#define PROP_VIRTSERIAL_NAME_DESC\
+"Name for the port that's exposed to the guest for port discovery."
+
 typedef struct VirtIOSerial VirtIOSerial;
 typedef struct VirtIOSerialBus VirtIOSerialBus;
 typedef struct VirtIOSerialPort VirtIOSerialPort;
-- 
1.7.3.2

[Qemu-devel] [PATCH 0/4] [RESEND] [REBASE] Auto-document qdev devices

Hello,

This is a rebase of the patchset I'd sent earlier.

The usual notes apply: this is just the start, just getting the
framework in place and a few examples so that people can then pick up
and start documenting their devices and options.  We want to see all
of the devices covered, and hopefully turn on build_bug_on() on an
empty doc string.

Maintainers should perhaps also look for patches that introduce
options without documentation.

That's the long-term goal (over 0.14).  For short-term, I'll be
preparing follow-on patches that add doc strings for a few more
options and perhaps bug people based on git history as to what
documentation is to be added for some options.

The earlier this patchset goes in the better since it'll reduce
conflicts and rebases needed.

If this looks acceptable, please apply!

Amit

Amit Shah (4):
  qdev: Add a description field for qdev properties for documentation
  virtio-serial: Add description fields for qdev properties
  net.h: Add description fields for qdev properites
  block_int.h: Provide documentation for common block qdev properties

 block_int.h |   14 +
 hw/a9mpcore.c   |2 +-
 hw/acpi_piix4.c |2 +-
 hw/apic.c   |4 +-
 hw/applesmc.c   |4 +-
 hw/arm11mpcore.c|4 +-
 hw/arm_sysctl.c |4 +-
 hw/armv7m.c |2 +-
 hw/cs4231a.c|6 ++--
 hw/debugcon.c   |6 ++--
 hw/eccmemctl.c  |2 +-
 hw/escc.c   |   16 +-
 hw/etraxfs_pic.c|3 +-
 hw/fdc.c|   10 +++---
 hw/fw_cfg.c |4 +-
 hw/gus.c|8 ++--
 hw/hda-audio.c  |2 +-
 hw/hpet.c   |4 +-
 hw/i2c.c|2 +-
 hw/ide/cmd646.c |2 +-
 hw/ide/isa.c|6 ++--
 hw/ide/qdev.c   |6 ++--
 hw/integratorcp.c   |2 +-
 hw/intel-hda.c  |6 ++--
 hw/ioh3420.c|6 ++--
 hw/ivshmem.c|   15 +
 hw/lance.c  |2 +-
 hw/m48t59.c |   12 
 hw/mc146818rtc.c|2 +-
 hw/ne2000-isa.c |4 +-
 hw/parallel.c   |8 ++--
 hw/pci.c|8 ++--
 hw/qdev-addr.h  |4 +-
 hw/qdev.c   |3 +-
 hw/qdev.h   |   75 +--
 hw/s390-virtio-bus.c|2 +-
 hw/sb16.c   |   10 +++---
 hw/scsi-bus.c   |2 +-
 hw/scsi-disk.c  |4 +-
 hw/serial.c |8 ++--
 hw/slavio_timer.c   |2 +-
 hw/smbus_eeprom.c   |2 +-
 hw/sparc32_dma.c|2 +-
 hw/sun4m.c  |2 +-
 hw/sun4m_iommu.c|2 +-
 hw/sun4u.c  |2 +-
 hw/syborg_fb.c  |4 +-
 hw/syborg_interrupt.c   |2 +-
 hw/syborg_keyboard.c|2 +-
 hw/syborg_pointer.c |4 +-
 hw/syborg_serial.c  |2 +-
 hw/syborg_timer.c   |2 +-
 hw/syborg_virtio.c  |6 ++--
 hw/tcx.c|   10 +++---
 hw/usb-ohci.c   |4 +-
 hw/usb-serial.c |   12 
 hw/virtio-blk.h |4 +-
 hw/virtio-console.c |   19 +++
 hw/virtio-net.h |   51 ---
 hw/virtio-pci.c |   22 +++---
 hw/virtio-serial.h  |   13 
 hw/virtio.h |2 +-
 hw/vt82c686.c   |2 +-
 hw/xilinx_ethlite.c |6 ++-
 hw/xilinx_intc.c|3 +-
 hw/xilinx_timer.c   |4 +-
 hw/xio3130_downstream.c |6 ++--
 hw/xio3130_upstream.c   |2 +-
 net.h   |9 --
 usb-linux.c |8 ++--
 70 files changed, 273 insertions(+), 224 deletions(-)

-- 
1.7.3.2

[Qemu-devel] [patch 1/2] add USBBusOps to USBBus

Needed for remote wakeup notification.

Signed-off-by: Marcelo Tosatti 

Index: qemu-kvm/hw/usb-bus.c
===
--- qemu-kvm.orig/hw/usb-bus.c
+++ qemu-kvm/hw/usb-bus.c
@@ -14,11 +14,12 @@ static struct BusInfo usb_bus_info = {
 static int next_usb_bus = 0;
 static QTAILQ_HEAD(, USBBus) busses = QTAILQ_HEAD_INITIALIZER(busses);
 
-void usb_bus_new(USBBus *bus, DeviceState *host)
+void usb_bus_new(USBBus *bus, DeviceState *host, USBBusOps *ops)
 {
 qbus_create_inplace(&bus->qbus, &usb_bus_info, host, NULL);
 bus->busnr = next_usb_bus++;
 bus->qbus.allow_hotplug = 1; /* Yes, we can */
+bus->ops = ops;
 QTAILQ_INIT(&bus->free);
 QTAILQ_INIT(&bus->used);
 QTAILQ_INSERT_TAIL(&busses, bus, next);
Index: qemu-kvm/hw/usb.c
===
--- qemu-kvm.orig/hw/usb.c
+++ qemu-kvm/hw/usb.c
@@ -229,3 +229,12 @@ void usb_send_msg(USBDevice *dev, int ms
 
 /* This _must_ be synchronous */
 }
+
+void usb_remote_wakeup(USBDevice *dev)
+{
+USBBus *bus = usb_bus_from_device(dev);
+
+if (bus->ops && bus->ops->remote_wakeup_cb) {
+bus->ops->remote_wakeup_cb(bus, dev);
+}
+}
Index: qemu-kvm/hw/usb.h
===
--- qemu-kvm.orig/hw/usb.h
+++ qemu-kvm/hw/usb.h
@@ -123,6 +123,7 @@
 #define USB_ENDPOINT_XFER_INT  3
 
 typedef struct USBBus USBBus;
+typedef struct USBBusOps USBBusOps;
 typedef struct USBPort USBPort;
 typedef struct USBDevice USBDevice;
 typedef struct USBDeviceInfo USBDeviceInfo;
@@ -294,8 +295,16 @@ void musb_set_size(MUSBState *s, int epn
 
 /* usb-bus.c */
 
+struct USBBusOps {
+/*
+ * Process remote wakeup request.
+ */
+void (*remote_wakeup_cb)(USBBus *bus, USBDevice *dev);
+};
+
 struct USBBus {
 BusState qbus;
+USBBusOps *ops;
 int busnr;
 int nfree;
 int nused;
@@ -304,7 +313,7 @@ struct USBBus {
 QTAILQ_ENTRY(USBBus) next;
 };
 
-void usb_bus_new(USBBus *bus, DeviceState *host);
+void usb_bus_new(USBBus *bus, DeviceState *host, USBBusOps *ops);
 USBBus *usb_bus_find(int busnr);
 void usb_qdev_register(USBDeviceInfo *info);
 void usb_qdev_register_many(USBDeviceInfo *info);
@@ -317,6 +326,7 @@ void usb_unregister_port(USBBus *bus, US
 int usb_device_attach(USBDevice *dev);
 int usb_device_detach(USBDevice *dev);
 int usb_device_delete_addr(int busnr, int addr);
+void usb_remote_wakeup(USBDevice *dev);
 
 static inline USBBus *usb_bus_from_device(USBDevice *d)
 {
Index: qemu-kvm/hw/usb-musb.c
===
--- qemu-kvm.orig/hw/usb-musb.c
+++ qemu-kvm/hw/usb-musb.c
@@ -342,7 +342,7 @@ struct MUSBState {
 s->ep[i].epnum = i;
 }
 
-usb_bus_new(&s->bus, NULL /* FIXME */);
+usb_bus_new(&s->bus, NULL /* FIXME */, NULL);
 usb_register_port(&s->bus, &s->port, s, 0, musb_attach);
 
 return s;
Index: qemu-kvm/hw/usb-ohci.c
===
--- qemu-kvm.orig/hw/usb-ohci.c
+++ qemu-kvm/hw/usb-ohci.c
@@ -1702,7 +1702,7 @@ static void usb_ohci_init(OHCIState *ohc
 
 ohci->name = dev->info->name;
 
-usb_bus_new(&ohci->bus, dev);
+usb_bus_new(&ohci->bus, dev, NULL);
 ohci->num_ports = num_ports;
 for (i = 0; i < num_ports; i++) {
 usb_register_port(&ohci->bus, &ohci->rhport[i].port, ohci, i, 
ohci_attach);
Index: qemu-kvm/hw/usb-uhci.c
===
--- qemu-kvm.orig/hw/usb-uhci.c
+++ qemu-kvm/hw/usb-uhci.c
@@ -1113,7 +1113,7 @@ static int usb_uhci_common_initfn(UHCISt
 pci_conf[PCI_INTERRUPT_PIN] = 4; // interrupt pin 3
 pci_conf[0x60] = 0x10; // release number
 
-usb_bus_new(&s->bus, &s->dev.qdev);
+usb_bus_new(&s->bus, &s->dev.qdev, NULL);
 for(i = 0; i < NB_PORTS; i++) {
 usb_register_port(&s->bus, &s->ports[i].port, s, i, uhci_attach);
 }

[Qemu-devel] [patch 2/2] support for UHCI suspend / remote wake up

This patch enables USB UHCI global suspend/resume feature. The OS will
stop the HC once all ports are suspended. If there is activity on the
port(s), an interrupt signalling remote wakeup will be triggered.

To enable autosuspend for the USB tablet on Linux guests:

echo auto > /sys/devices/pci:00/:00:01.2/usb1/1-1/power/level

It reduces CPU consumption of an idle FC12 guest from 2.7% to 0.3%.

Signed-off-by: Marcelo Tosatti 

Index: qemu-kvm/hw/usb-hid.c
===
--- qemu-kvm.orig/hw/usb-hid.c
+++ qemu-kvm/hw/usb-hid.c
@@ -412,6 +412,9 @@ static void usb_hid_changed(USBHIDState 
 
 if (hs->datain)
 hs->datain(hs->datain_opaque);
+
+if (hs->dev.remote_wakeup)
+usb_remote_wakeup(&hs->dev);
 }
 
 static void usb_mouse_event(void *opaque,
Index: qemu-kvm/hw/usb-uhci.c
===
--- qemu-kvm.orig/hw/usb-uhci.c
+++ qemu-kvm/hw/usb-uhci.c
@@ -59,6 +59,7 @@
 
 #define UHCI_PORT_RESET (1 << 9)
 #define UHCI_PORT_LSDA  (1 << 8)
+#define UHCI_PORT_RD(1 << 6)
 #define UHCI_PORT_ENC   (1 << 3)
 #define UHCI_PORT_EN(1 << 2)
 #define UHCI_PORT_CSC   (1 << 1)
@@ -501,6 +502,7 @@ static void uhci_ioport_writew(void *opa
 port->ctrl = (port->ctrl & 0x01fb) | (val & ~0x01fb);
 /* some bits are reset when a '1' is written to them */
 port->ctrl &= ~(val & 0x000a);
+port->ctrl &= ~(port->ctrl & 0x0040); /* clear port resume 
detected */
 }
 break;
 }
@@ -593,6 +595,41 @@ static void uhci_resume (void *opaque)
 }
 }
 
+static UHCIPort *find_port(UHCIState *s, USBDevice *d)
+{
+int i;
+
+for (i = 0; i < NB_PORTS; i++) {
+UHCIPort *port = &s->ports[i];
+
+if (d == port->port.dev) {
+return port;
+}
+}
+
+return NULL;
+}
+
+static void uhci_event(USBBus *bus, USBDevice *dev)
+{
+UHCIState *s = container_of(bus, UHCIState, bus);
+
+if (s->cmd & UHCI_CMD_EGSM) {
+UHCIPort *port = find_port(s, dev);
+
+if (!port) {
+return;
+}
+
+if (port->ctrl & UHCI_PORT_RD) {
+return;
+}
+
+port->ctrl |= UHCI_PORT_RD;
+uhci_resume(s);
+}
+}
+
 static void uhci_attach(USBPort *port1, USBDevice *dev)
 {
 UHCIState *s = port1->opaque;
@@ -1101,6 +1138,10 @@ static void uhci_map(PCIDevice *pci_dev,
 register_ioport_read(addr, 32, 1, uhci_ioport_readb, s);
 }
 
+static USBBusOps uhci_bus_ops = {
+.remote_wakeup_cb = uhci_event,
+};
+
 static int usb_uhci_common_initfn(UHCIState *s)
 {
 uint8_t *pci_conf = s->dev.config;
@@ -1113,7 +1154,7 @@ static int usb_uhci_common_initfn(UHCISt
 pci_conf[PCI_INTERRUPT_PIN] = 4; // interrupt pin 3
 pci_conf[0x60] = 0x10; // release number
 
-usb_bus_new(&s->bus, &s->dev.qdev, NULL);
+usb_bus_new(&s->bus, &s->dev.qdev, &uhci_bus_ops);
 for(i = 0; i < NB_PORTS; i++) {
 usb_register_port(&s->bus, &s->ports[i].port, s, i, uhci_attach);
 }

[Qemu-devel] [patch 0/2] USB UHCI global suspend / remote wakeup

See patch 2 for details.

v2: 
- Add remote wakeup callback in USBBus, as suggested by Gerd.

[Qemu-devel] [PATCH 6/6] ccid: add docs

Signed-off-by: Alon Levy 
---
 docs/ccid.txt   |  125 +
 docs/libcaccard.txt |  482 +++
 2 files changed, 607 insertions(+), 0 deletions(-)
 create mode 100644 docs/ccid.txt
 create mode 100644 docs/libcaccard.txt

diff --git a/docs/ccid.txt b/docs/ccid.txt
new file mode 100644
index 000..3af4f92
--- /dev/null
+++ b/docs/ccid.txt
@@ -0,0 +1,125 @@
+Qemu CCID Device Documentation.
+
+Contents
+1. USB CCID device
+2. Building
+3. Using ccid-card-emulated with hardware
+4. Using ccid-card-emulated with certificates
+5. Using ccid-card-passthru with client side hardware
+6. Using ccid-card-passthru with client side certificates
+7. Passthrough protocol scenario
+8. libcaccard
+
+1. USB CCID device
+
+The USB CCID device is a USB device implementing the CCID specification, which
+lets one connect smart card readers that implement the same spec. For more
+information see the specification:
+
+ Universal Serial Bus
+ Device Class: Smart Card
+ CCID
+ Specification for
+ Integrated Circuit(s) Cards Interface Devices
+ Revision 1.1
+ April 22rd, 2005
+
+Smartcard are used for authentication, single sign on, decryption in
+public/private schemes and digital signatures. A smartcard reader on the client
+cannot be used on a guest with simple usb passthrough since it will then not be
+available on the client, possibly locking the computer when it is "removed". On
+the other hand this device can let you use the smartcard on both the client and
+the guest machine. It is also possible to have a completely virtual smart card
+reader and smart card (i.e. not backed by a physical device) using this device.
+
+2. Building
+
+The cryptographic functions and access to the physical card is done via NSS.
+
+Installing NSS:
+
+In redhat/fedora:
+yum install nss-devel
+In ubuntu/debian:
+apt-get install libnss3-dev
+(not tested on ubuntu)
+
+Configuring and building:
+./configure --enable-smartcard && make
+
+3. Using ccid-card-emulated with hardware
+
+Assuming you have a working smartcard on the host with the current
+user, using NSS, qemu acts as another NSS client using ccid-card-emulated:
+
+qemu -usb -device usb-ccid -device ccid-card-emualated
+
+4. Using ccid-card-emulated with certificates
+
+You must create the certificates. This is a one time process. We use NSS
+certificates:
+
+certutil -d /etc/pki/nssdb -x -t "CT,CT,CT" -S -s "CN=cert1" -n cert1
+
+Note: you must have exactly three certificates.
+
+Assuming the current user can access the certificates (use certutil -L to
+verify), you can use the emulated card type with the certificates backend:
+
+qemu -usb -device usb-ccid -device 
ccid-card-emulated,backend=certificates,cert1=cert1,cert2=cert2,cert3=cert3
+
+5. Using ccid-card-passthru with client side hardware
+
+on the host specify the ccid-card-passthru device with a suitable chardev:
+
+qemu -chardev socket,server,host=0.0.0.0,port=2001,id=ccid,nowait -usb 
-device usb-ccid -device ccid-card-passthru,chardev=ccid
+
+on the client run vscclient, built when you built the libcaccard library:
+libcaccard/vscclient  2001
+
+6. Using ccid-card-passthru with client side certificates
+
+Run qemu as per #5, and run vscclient as follows:
+(Note: vscclient command line interface is in a state of change)
+
+libcaccard/vscclient -e "db=\"/etc/pki/nssdb\" use_hw=no 
soft=(,Test,CAC,,cert1,cert2,cert3)"  2001
+
+7. Passthrough protocol scenario
+
+This is a typical interchange of messages when using the passthru card device.
+usb-ccid is a usb device. It defaults to an unattached usb device on startup.
+usb-ccid expects a chardev and expects the protocol defined in
+cac_card/vscard_common.h to be passed over that.
+
+A typical interchange is:
+
+client event  |  vscclient   |passthru| usb-ccid  
|  guest event
+--
+  |  VSC_Init||   |
+  |  VSC_ReaderAdd   || attach|
+  |  ||   
|  sees new usb device.
+card inserted |  ||   |
+  |  VSC_ATR ||   |
+  |  ||   
|  guest operation, APDU transfer via CCID
+  |  |   VSC_APDU |   |
+  |  VSC_APDU||   |
+client<->physical |  ||   |
+card APDU exchange|  ||   |
+[APDU<->APDU repeats several times]  
+card removed  |  |

[Qemu-devel] [PATCH 1/6] usb-ccid: add CCID bus

A CCID device is a smart card reader. It is a USB device, defined at [1].
This patch introduces the usb-ccid device that is a ccid bus. Next patches will
introduce two card types to use it, a passthru card and an emulated card.

 [1] http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.

Signed-off-by: Alon Levy 
---
 Makefile.objs |1 +
 configure |   12 +
 hw/ccid.h |   34 ++
 hw/usb-ccid.c | 1342 +
 4 files changed, 1389 insertions(+), 0 deletions(-)
 create mode 100644 hw/ccid.h
 create mode 100644 hw/usb-ccid.c

diff --git a/Makefile.objs b/Makefile.objs
index 23b17ce..713131f 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -183,6 +183,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
 hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
 hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
 hw-obj-$(CONFIG_DMA) += dma.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o
 
 # PPC devices
 hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/configure b/configure
index 2917874..fb9eac2 100755
--- a/configure
+++ b/configure
@@ -332,6 +332,7 @@ zero_malloc=""
 trace_backend="nop"
 trace_file="trace"
 spice=""
+smartcard="no"
 
 # OS specific
 if check_define __linux__ ; then
@@ -739,6 +740,10 @@ for opt do
   ;;
   --enable-vhost-net) vhost_net="yes"
   ;;
+  --disable-smartcard) smartcard="no"
+  ;;
+  --enable-smartcard) smartcard="yes"
+  ;;
   --*dir)
   ;;
   *) echo "ERROR: unknown option $opt"; show_help="yes"
@@ -934,6 +939,8 @@ echo "  --trace-file=NAMEFull PATH,NAME of file to 
store traces"
 echo "   Default:trace-"
 echo "  --disable-spice  disable spice"
 echo "  --enable-spice   enable spice"
+echo "  --disable-smartcard  disable smartcard support"
+echo "  --enable-smartcard   enable smartcard support"
 echo ""
 echo "NOTE: The object files are built at the place where configure is 
launched"
 exit 1
@@ -2354,6 +2361,7 @@ echo "vhost-net support $vhost_net"
 echo "Trace backend $trace_backend"
 echo "Trace output file $trace_file-"
 echo "spice support $spice"
+echo "smartcard support $smartcard"
 
 if test $sdl_too_old = "yes"; then
 echo "-> Your SDL version is too old - please upgrade to have SDL support"
@@ -2617,6 +2625,10 @@ if test "$spice" = "yes" ; then
   echo "CONFIG_SPICE=y" >> $config_host_mak
 fi
 
+if test "$smartcard" = "yes" ; then
+  echo "CONFIG_SMARTCARD=y" >> $config_host_mak
+fi
+
 # XXX: suppress that
 if [ "$bsd" = "yes" ] ; then
   echo "CONFIG_BSD=y" >> $config_host_mak
diff --git a/hw/ccid.h b/hw/ccid.h
new file mode 100644
index 000..a38f971
--- /dev/null
+++ b/hw/ccid.h
@@ -0,0 +1,34 @@
+#ifndef __CCID_H__
+#define __CCID_H__
+
+#include "qdev.h"
+
+typedef struct CCIDCardState CCIDCardState;
+typedef struct CCIDCardInfo CCIDCardInfo;
+
+struct CCIDCardState {
+DeviceState qdev;
+};
+
+struct CCIDCardInfo {
+DeviceInfo qdev;
+void (*print)(Monitor *mon, CCIDCardState *card, int indent);
+const uint8_t *(*get_atr)(CCIDCardState *card, uint32_t *len);
+void (*apdu_from_guest)(CCIDCardState *card, const uint8_t *apdu, uint32_t 
len);
+int (*exitfn)(CCIDCardState *card);
+int (*initfn)(CCIDCardState *card);
+};
+
+void ccid_card_send_apdu_to_guest(CCIDCardState *card, uint8_t* apdu, uint32_t 
len);
+void ccid_card_card_removed(CCIDCardState *card);
+void ccid_card_card_inserted(CCIDCardState *card);
+void ccid_card_card_error(CCIDCardState *card, uint64_t error);
+void ccid_card_qdev_register(CCIDCardInfo *card);
+
+/* support guest visible insertion/removal of ccid devices based on actual
+ * devices connected/removed. Called by card implementation (passthru, local) 
*/
+int ccid_card_ccid_attach(CCIDCardState *card);
+void ccid_card_ccid_detach(CCIDCardState *card);
+
+#endif // __CCID_H__
+
diff --git a/hw/usb-ccid.c b/hw/usb-ccid.c
new file mode 100644
index 000..66c1dba
--- /dev/null
+++ b/hw/usb-ccid.c
@@ -0,0 +1,1342 @@
+/*
+ * CCID Device emulation
+ *
+ * Based on usb-serial.c:
+ * Copyright (c) 2006 CodeSourcery.
+ * Copyright (c) 2008 Samuel Thibault 
+ * Written by Paul Brook, reused for FTDI by Samuel Thibault,
+ * Reused for CCID by Alon Levy.
+ * Contributed to by Robert Relyea
+ * Copyright (c) 2010 Red Hat.
+ *
+ * This code is licenced under the LGPL.
+ */
+
+/* References:
+ *
+ * CCID Specification Revision 1.1 April 22nd 2005
+ *  "Universal Serial Bus, Device Class: Smart Card"
+ *  Specification for Integrated Circuit(s) Cards Interface Devices
+ *
+ * KNOWN BUGS
+ * 1. remove/insert can sometimes result in removed state instead of inserted.
+ * This is a result of the following:
+ *  symptom: dmesg shows ERMOTEIO (-121), pcscd shows -99. This happens
+ *  when we send a too short packet, seen in uhci-usb.c, resulting from
+ *  a urb requesting SPD and us returning a smaller packet.
+ *  Not sure which messages trigger this.
+ *
+ */
+
+#include "qemu-common.h"
+#include "qemu-error.h"
+#include "usb.h"

[Qemu-devel] [PATCH 5/6] add ccid-card-emulated device (v2)

changes from v1:
remove stale comments, use only c-style comments
bugfix, forgot to set recv_len
change reader name to 'Virtual Reader'

Signed-off-by: Alon Levy 
---
 Makefile.objs   |2 +-
 hw/ccid-card-emulated.c |  492 +++
 2 files changed, 493 insertions(+), 1 deletions(-)
 create mode 100644 hw/ccid-card-emulated.c

diff --git a/Makefile.objs b/Makefile.objs
index 82691c0..a494ee0 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -183,7 +183,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
 hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
 hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
 hw-obj-$(CONFIG_DMA) += dma.o
-hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o 
ccid-card-emulated.o
 
 # PPC devices
 hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/hw/ccid-card-emulated.c b/hw/ccid-card-emulated.c
new file mode 100644
index 000..828cc6c
--- /dev/null
+++ b/hw/ccid-card-emulated.c
@@ -0,0 +1,492 @@
+/*
+ * CCID Card Device. Emulated card.
+ *
+ * It can be used to provide access to the local hardware in a non exclusive
+ * way, or it can use certificates. It requires the usb-ccid bus.
+ *
+ * Usage 1: standard, mirror hardware reader+card:
+ * qemu .. -usb -device usb-ccid -device ccid-card-emulated
+ *
+ * Usage 2: use certificates, no hardware required
+ * one time: create the certificates:
+ *  for i in 1 2 3; do certutil -d /etc/pki/nssdb -x -t "CT,CT,CT" -S -s 
"CN=user$i" -n user$i; done 
+ * qemu .. -usb -device usb-ccid -device 
ccid-card-emulated,cert1=user1,cert2=user2,cert3=user3
+ *
+ * If you use a non default db for the certificates you can specify it using 
the db parameter.
+ *
+ *
+ * Copyright (c) 2010 Red Hat.
+ * Written by Alon Levy.
+ *
+ * This code is licenced under the LGPL.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "qemu-char.h"
+#include "monitor.h"
+#include "hw/ccid.h"
+
+#define DPRINTF(card, lvl, fmt, ...) \
+do { if (lvl <= card->debug) { printf("ccid-card-emul: %s: " fmt , __func__, 
## __VA_ARGS__); } } while (0)
+
+#define EMULATED_DEV_NAME "ccid-card-emulated"
+
+#define BACKEND_NSS_EMULATED "nss-emulated" /* the default */
+#define BACKEND_CERTIFICATES "certificates"
+
+typedef struct EmulatedState EmulatedState;
+
+enum {
+EMUL_READER_INSERT = 0,
+EMUL_READER_REMOVE,
+EMUL_CARD_INSERT,
+EMUL_CARD_REMOVE,
+EMUL_GUEST_APDU,
+EMUL_RESPONSE_APDU,
+EMUL_ERROR,
+};
+
+static const char* emul_event_to_string(uint32_t emul_event)
+{
+switch (emul_event) {
+case EMUL_READER_INSERT: return "EMUL_READER_INSERT";
+case EMUL_READER_REMOVE: return "EMUL_READER_REMOVE";
+case EMUL_CARD_INSERT: return "EMUL_CARD_INSERT";
+case EMUL_CARD_REMOVE: return "EMUL_CARD_REMOVE";
+case EMUL_GUEST_APDU: return "EMUL_GUEST_APDU";
+case EMUL_RESPONSE_APDU: return "EMUL_RESPONSE_APDU";
+case EMUL_ERROR: return "EMUL_ERROR";
+default:
+break;
+}
+return "UNKNOWN";
+}
+
+typedef struct EmulEvent {
+QSIMPLEQ_ENTRY(EmulEvent) entry;
+union {
+struct {
+uint32_t type;
+} gen;
+struct {
+uint32_t type;
+uint64_t code;
+} error;
+struct {
+uint32_t type;
+uint32_t len;
+uint8_t data[];
+} data;
+} p;
+} EmulEvent;
+
+#define MAX_ATR_SIZE 40
+struct EmulatedState {
+CCIDCardState base;
+uint8_t  debug;
+char*backend;
+char*cert1;
+char*cert2;
+char*cert3;
+char*db;
+uint8_t  atr[MAX_ATR_SIZE];
+uint8_t  atr_length;
+QSIMPLEQ_HEAD(event_list, EmulEvent) event_list;
+pthread_mutex_t event_list_mutex;
+VReader *reader;
+QSIMPLEQ_HEAD(guest_apdu_list, EmulEvent) guest_apdu_list;
+pthread_mutex_t vreader_mutex; /* and guest_apdu_list mutex */
+pthread_mutex_t handle_apdu_mutex;
+pthread_cond_t handle_apdu_cond;
+int  pipe[2];
+int  quit_apdu_thread;
+pthread_mutex_t apdu_thread_quit_mutex;
+pthread_cond_t apdu_thread_quit_cond;
+};
+
+static void emulated_apdu_from_guest(CCIDCardState *base, const uint8_t *apdu, 
uint32_t len)
+{
+EmulatedState *card = DO_UPCAST(EmulatedState, base, base);
+EmulEvent *event = (EmulEvent*)malloc(sizeof(EmulEvent) + len);
+
+assert(event);
+event->p.data.type = EMUL_GUEST_APDU;
+event->p.data.len = len;
+memcpy(event->p.data.data, apdu, len);
+pthread_mutex_lock(&card->vreader_mutex);
+QSIMPLEQ_INSERT_TAIL(&card->guest_apdu_list, event, entry);
+pthread_mutex_unlock(&card->vreader_mutex);
+pthread_cond_signal(&card->handle_apdu_cond);
+}
+
+static const uint8_t* emulated_get_atr(CCIDCardState *base, uint32_t *len)
+{
+EmulatedState *card = DO_UPCAST(EmulatedState, base, base);
+
+*len = card->atr_length;
+return card-

[Qemu-devel] [PATCH 4/6] libcaccard: update configure to build and use internal libcaccard

Signed-off-by: Alon Levy 
---
 Makefile|6 --
 Makefile.objs   |5 +
 Makefile.target |2 ++
 configure   |   24 
 libcaccard/Makefile |   18 ++
 5 files changed, 53 insertions(+), 2 deletions(-)
 create mode 100644 libcaccard/Makefile

diff --git a/Makefile b/Makefile
index 4e120a2..e673bf1 100644
--- a/Makefile
+++ b/Makefile
@@ -172,6 +172,8 @@ check-qlist: check-qlist.o qlist.o qint.o $(CHECK_PROG_DEPS)
 check-qfloat: check-qfloat.o qfloat.o $(CHECK_PROG_DEPS)
 check-qjson: check-qjson.o qfloat.o qint.o qdict.o qstring.o qlist.o qbool.o 
qjson.o json-streamer.o json-lexer.o json-parser.o $(CHECK_PROG_DEPS)
 
+QEMULIBS=libhw32 libhw64 libuser libdis libdis-user libcaccard
+
 clean:
 # avoid old build problems by removing potentially incorrect old files
rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h 
gen-op-arm.h
@@ -183,7 +185,7 @@ clean:
rm -f trace-dtrace.dtrace trace-dtrace.dtrace-timestamp
rm -f trace-dtrace.h trace-dtrace.h-timestamp
$(MAKE) -C tests clean
-   for d in $(ALL_SUBDIRS) libhw32 libhw64 libuser libdis libdis-user; do \
+   for d in $(ALL_SUBDIRS) $(QEMULIBS); do \
if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \
rm -f $$d/qemu-options.def; \
 done
@@ -194,7 +196,7 @@ distclean: clean
rm -f roms/seabios/config.mak roms/vgabios/config.mak
rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.dvi qemu-doc.fn 
qemu-doc.info qemu-doc.ky qemu-doc.log qemu-doc.pdf qemu-doc.pg qemu-doc.toc 
qemu-doc.tp qemu-doc.vr
rm -f qemu-tech.info qemu-tech.aux qemu-tech.cp qemu-tech.dvi 
qemu-tech.fn qemu-tech.info qemu-tech.ky qemu-tech.log qemu-tech.pdf 
qemu-tech.pg qemu-tech.toc qemu-tech.tp qemu-tech.vr
-   for d in $(TARGET_DIRS) libhw32 libhw64 libuser libdis libdis-user; do \
+   for d in $(TARGET_DIRS) $(QEMULIBS); do \
rm -rf $$d || exit 1 ; \
 done
 
diff --git a/Makefile.objs b/Makefile.objs
index 2059e89..82691c0 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -297,6 +297,11 @@ user-obj-y += qemu-timer-common.o
 endif
 endif
 
+##
+# smartcard
+
+libcaccard-y = cac.o event.o passthru.o vcard.o vreader.o vcard_emul_nss.o 
vcard_emul_type.o card_7816.o
+
 vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS)
 
 vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS)
diff --git a/Makefile.target b/Makefile.target
index 2800f47..7dd6932 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -341,6 +341,8 @@ obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y))
 
 endif # CONFIG_SOFTMMU
 
+obj-y += $(addprefix $(SRC_PATH)/libcaccard/, 
$(libcaccard-$(CONFIG_SMARTCARD)))
+
 obj-y += $(addprefix ../, $(trace-obj-y))
 obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o
 
diff --git a/configure b/configure
index fb9eac2..4b55904 100755
--- a/configure
+++ b/configure
@@ -2130,6 +2130,25 @@ EOF
   fi
 fi
 
+# check for libcaccard for smartcard support
+if test "$smartcard" != "no" ; then
+  smartcard_cflags="-I\$(SRC_PATH)/libcaccard"
+  smartcard_libs="-L\$(SRC_PATH)/libcaccard -lcaccard"
+  libcaccard_libs=$($pkgconfig --libs nss 2>/dev/null)
+  libcaccard_cflags=$($pkgconfig --cflags nss)
+  # TODO - what's the minimal nss version we support?
+  if $pkgconfig --atleast-version=3.12.8 nss; then
+smartcard="yes"
+QEMU_CFLAGS="$QEMU_CFLAGS $smartcard_cflags $libcaccard_cflags"
+LIBS="$libcaccard_libs $LIBS"
+  else
+if test "smartcard" = "yes" ; then
+  feature_not_found "smartcard"
+fi
+smartcard="no"
+  fi
+fi
+
 ##
 
 ##
@@ -2956,6 +2975,11 @@ fi
 if test "$target_darwin_user" = "yes" ; then
   echo "CONFIG_DARWIN_USER=y" >> $config_target_mak
 fi
+if test "$smartcard" = "yes" ; then
+  echo "subdir-$target: subdir-libcaccard" >> $config_host_mak
+  echo "libcaccard_libs=$libcaccard_libs" >> $config_host_mak
+  echo "libcaccard_cflags=$libcaccard_cflags" >> $config_host_mak
+fi
 list=""
 if test ! -z "$gdb_xml_files" ; then
   for x in $gdb_xml_files; do
diff --git a/libcaccard/Makefile b/libcaccard/Makefile
new file mode 100644
index 000..a339af1
--- /dev/null
+++ b/libcaccard/Makefile
@@ -0,0 +1,18 @@
+include ../Makefile.objs
+include ../config-host.mak
+include ../config-all-devices.mak
+include $(SRC_PATH)/rules.mak
+
+CFLAGS+=-fPIC
+
+libcaccard.so: $(libcaccard-y)
+   gcc -shared $(libcaccard_libs) -o $@ $^
+
+vscclient: $(libcaccard-y) vscclient.o
+   gcc $(libcaccard_libs) -o $@ $^
+
+all: libcaccard.so vscclient
+
+clean:
+   rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~ libcaccard.so
+
-- 
1.7.3.2

[Qemu-devel] [PATCH 0/6] usb-ccid (v7)

This patchset adds three new devices, usb-ccid, ccid-card-passthru and
ccid-card-emulated, providing a CCID bus, a simple passthru protocol
implementing card requiring a client, and a standalone emulated card.

It also introduces a new directory libcaccard with CAC card emulation,
CAC is a type of ISO 7816 smart card.

v6->v7 changes:
 * external libcaccard became internal directory libcaccard
  * statically link object files into qemu
  * produce libcaccard.so for usage by external projects
  * applied coding style to new code (please check me)
  - did not use the qemu options parsing for libcaccard, since
   it seems to draw large amounts of qemu code (monitor for instance).

v5->v6 changes:
 * really remove static debug (I apologize for claiming to have done so before)

v4->v5 changes:
 * rebased to latest
 * remove static debug in card devices
 * fix --enable-smartcard to link
 * stall instead of assert when exceeding BULK_OUT_DATA_SIZE
 * make ccid_reserve_recv_buf for too large len discard message, not exit
 * make ccid_reserve_recv_buf return void*
 * fix typo
 * remove commented code in VMState

v3->v4:
 * remove ccid field in CCIDBus
 * remove static debug in bus
 * add back docs

v2->v3:
 * split into bus (usb-ccid.c, uses ccid.h) and card (ccid-card-passthru.c).
 * removed documentation (being revised).

v1->v2:
 * all QSIMPLEQ turned into fixed sized rings
 * all allocated buffers turned into fixed size buffers
 * added migration support
 * added a message to tell client qemu has migrated to ip:port
  * for lack of monitor commands ip:port are 0:0, which causes the updated
   vscclient to connect to one port higher on the same host. will add monitor
   commands in a separate patch. tested with current setup.

Alon Levy (5):
  usb-ccid: add CCID bus
  ccid: add passthru card device
  libcaccard: update configure to build and use internal libcaccard
  add ccid-card-emulated device (v2)
  ccid: add docs

Robert Relyea (1):
  libcaccard: initial commit after coding style fixes

 Makefile |6 +-
 Makefile.objs|6 +
 Makefile.target  |2 +
 configure|   36 ++
 docs/ccid.txt|  125 
 docs/libcaccard.txt  |  482 +++
 hw/ccid-card-emulated.c  |  492 
 hw/ccid-card-passthru.c  |  277 +
 hw/ccid.h|   34 ++
 hw/usb-ccid.c| 1342 ++
 hw/vscard_common.h   |  130 
 libcaccard/Makefile  |   18 +
 libcaccard/cac.c |  411 +
 libcaccard/cac.h |   20 +
 libcaccard/card_7816.c   |  780 
 libcaccard/card_7816.h   |   60 ++
 libcaccard/card_7816t.h  |  163 +
 libcaccard/config.h  |   81 +++
 libcaccard/event.c   |  112 
 libcaccard/eventt.h  |   28 +
 libcaccard/link_test.c   |   20 +
 libcaccard/mutex.h   |   59 ++
 libcaccard/passthru.c|  608 +++
 libcaccard/passthru.h|   50 ++
 libcaccard/vcard.c   |  350 +++
 libcaccard/vcard.h   |   85 +++
 libcaccard/vcard_emul.h  |   59 ++
 libcaccard/vcard_emul_nss.c  | 1147 
 libcaccard/vcard_emul_type.c |   60 ++
 libcaccard/vcard_emul_type.h |   29 +
 libcaccard/vcardt.h  |   66 ++
 libcaccard/vevent.h  |   26 +
 libcaccard/vreader.c |  515 
 libcaccard/vreader.h |   53 ++
 libcaccard/vreadert.h|   23 +
 libcaccard/vscard_common.h   |  131 
 libcaccard/vscclient.c   |  710 ++
 37 files changed, 8594 insertions(+), 2 deletions(-)
 create mode 100644 docs/ccid.txt
 create mode 100644 docs/libcaccard.txt
 create mode 100644 hw/ccid-card-emulated.c
 create mode 100644 hw/ccid-card-passthru.c
 create mode 100644 hw/ccid.h
 create mode 100644 hw/usb-ccid.c
 create mode 100644 hw/vscard_common.h
 create mode 100644 libcaccard/Makefile
 create mode 100644 libcaccard/cac.c
 create mode 100644 libcaccard/cac.h
 create mode 100644 libcaccard/card_7816.c
 create mode 100644 libcaccard/card_7816.h
 create mode 100644 libcaccard/card_7816t.h
 create mode 100644 libcaccard/config.h
 create mode 100644 libcaccard/event.c
 create mode 100644 libcaccard/eventt.h
 create mode 100644 libcaccard/link_test.c
 create mode 100644 libcaccard/mutex.h
 create mode 100644 libcaccard/passthru.c
 create mode 100644 libcaccard/passthru.h
 create mode 100644 libcaccard/vcard.c
 create mode 100644 libcaccard/vcard.h
 create mode 100644 libcaccard/vcard_emul.h
 create mode 100644 libcaccard/vcard_emul_nss.c
 create mode 100644 libcaccard/vcard_emul_type.c
 create mode 100644 libcaccard/vcard_emul_type.h
 create mode 100644 libcaccard/vcardt.h
 create mode 100644 libcaccard/vevent.h
 create mode 100644 libcaccard/vreader.c
 create mode 100644 libcaccard/vreader.h
 create mode 10

[Qemu-devel] [PATCH 2/6] ccid: add passthru card device

For the client side utility vscclient, see libcac_card:

  libcac_card http://cgit.freedesktop.org/~alon/cac_card (temporary home)
  written by Robert Relyea 

Signed-off-by: Alon Levy 
---
 Makefile.objs   |2 +-
 hw/ccid-card-passthru.c |  277 +++
 hw/vscard_common.h  |  130 ++
 3 files changed, 408 insertions(+), 1 deletions(-)
 create mode 100644 hw/ccid-card-passthru.c
 create mode 100644 hw/vscard_common.h

diff --git a/Makefile.objs b/Makefile.objs
index 713131f..2059e89 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -183,7 +183,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
 hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
 hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
 hw-obj-$(CONFIG_DMA) += dma.o
-hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
 
 # PPC devices
 hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/hw/ccid-card-passthru.c b/hw/ccid-card-passthru.c
new file mode 100644
index 000..fbc4124
--- /dev/null
+++ b/hw/ccid-card-passthru.c
@@ -0,0 +1,277 @@
+/*
+ * CCID Card Device emulation
+ *
+ * Copyright (c) 2010 Red Hat.
+ * Written by Alon Levy.
+ *
+ * This code is licenced under the LGPL.
+ */
+
+#include "qemu-char.h"
+#include "monitor.h"
+#include "hw/ccid.h"
+#include "hw/vscard_common.h"
+
+#define DPRINTF(card, lvl, fmt, ...) \
+do { if (lvl <= card->debug) { printf("ccid-card: " fmt , ## __VA_ARGS__); } } 
while (0)
+
+/* Passthru card */
+
+
+// TODO: do we still need this?
+uint8_t DEFAULT_ATR[] = {
+/* From some example somewhere
+ 0x3B, 0xB0, 0x18, 0x00, 0xD1, 0x81, 0x05, 0xB1, 0x40, 0x38, 0x1F, 0x03, 0x28
+ */
+
+/* From an Athena smart card */
+ 0x3B, 0xD5, 0x18, 0xFF, 0x80, 0x91, 0xFE, 0x1F, 0xC3, 0x80, 0x73, 0xC8, 0x21, 
0x13, 0x08
+
+}; /* maximum size of ATR - from 7816-3 */
+
+
+#define PASSTHRU_DEV_NAME "ccid-card-passthru"
+#define VSCARD_IN_SIZE 65536
+#define MAX_ATR_SIZE40
+
+typedef struct PassthruState PassthruState;
+
+struct PassthruState {
+CCIDCardState base;
+CharDriverState *cs;
+uint8_t  vscard_in_data[VSCARD_IN_SIZE];
+uint32_t vscard_in_pos;
+uint32_t vscard_in_hdr;
+uint8_t  atr[MAX_ATR_SIZE];
+uint8_t  atr_length;
+uint8_t debug;
+};
+
+/* VSCard protocol over chardev
+ * This code should not depend on the card type.
+ * */
+
+static void ccid_card_vscard_send_msg(
+PassthruState *s, VSCMsgType type, reader_id_t reader_id,
+const uint8_t* payload, uint32_t length)
+{
+VSCMsgHeader scr_msg_header;
+
+scr_msg_header.type = type;
+scr_msg_header.reader_id = reader_id;
+scr_msg_header.length = length;
+qemu_chr_write(s->cs, (uint8_t*)&scr_msg_header, sizeof(VSCMsgHeader));
+qemu_chr_write(s->cs, payload, length);
+}
+
+static void ccid_card_vscard_send_apdu(
+PassthruState *s, const uint8_t* apdu, uint32_t length)
+{
+ccid_card_vscard_send_msg(s, VSC_APDU, VSCARD_MINIMAL_READER_ID, apdu, 
length);
+}
+
+static void ccid_card_vscard_send_error(
+PassthruState *s, reader_id_t reader_id, VSCErrorCode code)
+{
+VSCMsgError msg = {.code=code};
+
+ccid_card_vscard_send_msg(s, VSC_Error, reader_id, (uint8_t*)&msg, 
sizeof(msg));
+}
+
+static void ccid_card_vscard_send_init(PassthruState *s)
+{
+VSCMsgInit msg = {.version=VSCARD_VERSION};
+
+ccid_card_vscard_send_msg(s, VSC_Init, VSCARD_UNDEFINED_READER_ID,
+ (uint8_t*)&msg, sizeof(msg));
+}
+
+static int ccid_card_vscard_can_read(void *opaque)
+{
+return 65535;
+}
+
+static void ccid_card_vscard_handle_message(PassthruState *card,
+VSCMsgHeader* scr_msg_header)
+{
+uint8_t *data = (uint8_t*)&scr_msg_header[1];
+
+switch (scr_msg_header->type) {
+case VSC_ATR:
+DPRINTF(card, 1, "VSC_ATR %d\n", scr_msg_header->length);
+assert(scr_msg_header->length <= MAX_ATR_SIZE);
+memcpy(card->atr, data, scr_msg_header->length);
+card->atr_length = scr_msg_header->length;
+ccid_card_card_inserted(&card->base);
+break;
+case VSC_APDU:
+ccid_card_send_apdu_to_guest(&card->base, data, 
scr_msg_header->length);
+break;
+case VSC_CardRemove:
+DPRINTF(card, 1, "VSC_CardRemove\n");
+ccid_card_card_removed(&card->base);
+break;
+case VSC_Init:
+break;
+case VSC_Error:
+ccid_card_card_error(&card->base, *(uint64_t*)data);
+break;
+case VSC_ReaderAdd:
+if (ccid_card_ccid_attach(&card->base) < 0) {
+ccid_card_vscard_send_error(card, VSCARD_UNDEFINED_READER_ID,
+  VSC_CANNOT_ADD_MORE_READERS);
+} else {
+ccid_card_vscard_send_msg(card, VSC_ReaderAddResponse,
+ VSCARD_MINIMAL_READER_ID, NULL, 
0);
+}
+b

[Qemu-devel] [Bug 661696] Re: incomplete emulation of fstenv under TCG

2010-11-25 Thread Chalkerx

Ok. Here is a full patch to QEMU 0.13.

Works with and without -singlestep.
Works with all fpu instructions.

Should also work with fsave.

** Patch added: "Bug fix. For version 0.13. This patch fixes the bug (for me) 
completely."
   
https://bugs.launchpad.net/qemu/+bug/661696/+attachment/1744859/+files/qemu-0.13.0-fix_fstenv.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

Re: [Qemu-devel] [PATCH 13/15] scsi: Implement alloc_req_iov callback

On 11/25/2010 04:29 PM, Christoph Hellwig wrote:
> On Thu, Nov 25, 2010 at 09:53:25AM +0100, Hannes Reinecke wrote:
>> Looked into it.
>> Sure I could be doing it for scsi-disk; for scsi-generic it won't
>> work, though. And it's not much of a code-share to have from it;
>> you'll end up with something like:
> 
> Yes, and that is a good start to completely get rid of the non-iovec
> version.  Keeping two parallel APIs around that have slighly mismatching
> semantics is a bad idea.  And for scsi-generic in the version in your
> the difference is even worse and more subtile.
> 
> I think the only way to get this interface future proof is to unify
> it.  That is always pass an iovec from the HBA driver, and make the
> length chunking an explicitly flag passed to ->alloc_req instead of
> an implicit one when using the old interface.  Then refactor the code
> currently resetting.
> 
I don't think that'll work. It's only in send_command() when the CDB
is parsed, and only then we do know how much data we should be
expecting.
If you have a iovec passed in this doesn't matter as you can't
really enlarge it. But in the other case you really need the size if
you want to allocate a buffer large enough to hold the data.

I must say I'd like to get rid of the chunking transfer in scsi-disk.
To have it for scsi-disk only is really pointless, as you can
potentially send exactly the same commands via scsi-generic.
So for scsi-generic to work properly qemu need to be able to
allocate the _entire_ data buffer. And hence qemu _must_ be able to
allocate the same buffer for the scsi-disk emulation.
So any malloc space arguments don't really work out here.

By the same reasoning we could remove the chunking altogether;
any HBA _must_ be capable of issuing the entire data (if issued via
scsi-generic) even today. So I don't really buy the argument of
chunking being required for large I/Os.

But then, I've been down that road already.
With no large success.

> Talking about scsi-generic, how is the auto request-sense in 
> scsi_read_data and the mode select snooping in scsi_write_complete
> supposed to for for the iovec interface?
> 
The sense code is actually a property of the device, no the command.
And a REQUEST_SENSE command will just return the status of the last
command. So the sense buffer is always stored with the device
in SCSIGenericState and can be retrieved at will.

But you are correct, the MODE SELECT snooping needs to be modified.
No big deal, though.

>> And for the naming:
>> The SCSI stack is using 'req' for every function accepting
>> SCSIRequest as an argument:
>>
>> hw/scsi.h:
>> SCSIRequest *scsi_req_alloc(size_t size, SCSIDevice *d,
>>   uint32_t tag, uint32_t lun);
>> void scsi_req_free(SCSIRequest *req);
>>
>> int scsi_req_parse(SCSIRequest *req, uint8_t *buf);
>> void scsi_req_print(SCSIRequest *req);
>> void scsi_req_complete(SCSIRequest *req);
>>
>> So using 'alloc_req' and 'free_req' is in line with this naming
>> scheme. Using 'alloc_request' and 'free_request' really looked odd
>> in the light of the general usage.
> 
> Keeping the method names is fine, but please name the implementations
> matching it, e.g.
> 
> scsi_alloc_req and co.
> 
> And yes, using the scsi_ prefix is a bit confusing with the generic
> code also using it, eventually the disk driver should use scsi_disk
> and the generic driver scsi_generic prefixes.
> 
Ah, now I think I see what you mean.
You were think along these lines:

static SCSIDeviceInfo scsi_generic_info = {
.qdev.name= "scsi-generic",
.qdev.desc= "pass through generic scsi device (/dev/sg*)",
.qdev.size= sizeof(SCSIGenericState),
.qdev.reset   = scsi_generic_reset,
.init = scsi_generic_initfn,
.destroy  = scsi_destroy,
.alloc_req= scsi_generic_alloc_req,
.alloc_req_iov  = scsi_generic_alloc_req_iovec,
.free_req = scsi_generic_free_req,
.send_command = scsi_send_command,
.read_data= scsi_read_data,

correct?
Yeah, that's easy to do.

> And in general it would be nice if you could simplify answer to reviews.
> If something that the reviewer requests doesn't make sense state so in
> reply instead of silently ignoring it.

Will do in the future.

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)

[Qemu-devel] Re: PATCH: QEMU support for UHCI suspend / remote wake up


  Hi,


+dev->info->remote_wakeup_cb = uhci_event;



diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..16de1c9 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -189,6 +189,11 @@ struct USBDeviceInfo {
   */
  int (*handle_data)(USBDevice *dev, USBPacket *p);

+/*
+ * Process remote wakeup request.
+ */
+void (*remote_wakeup_cb)(USBDevice *dev);
+


No way.  DeviceInfo holds informations about the device 
*implementation*.  Multiple instances will share that, placing runtime 
data there is just plain wrong.


Also this is a callback from the usb device to the usb host adapter, not 
the other way around.  I'd suggest to create a USBBusOps for host 
adapter callbacks and and stick it into USBBus.


cheers,
  Gerd

[Qemu-devel] PATCH: QEMU support for UHCI suspend / remote wake up


This patch enables USB UHCI global suspend/resume feature. The OS will
stop the HC once all ports are suspended. If there is activity on the
port(s), an interrupt signalling remote wakeup will be triggered.

To enable autosuspend for the USB tablet on Linux guests:

echo auto > /sys/devices/pci:00/:00:01.2/usb1/1-1/power/level

It reduces CPU consumption of an idle FC12 guest from 2.7% to 0.3%.

Signed-off-by: Marcelo Tosatti 

diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index 882d933..b7a4dc1 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -412,6 +412,9 @@ static void usb_hid_changed(USBHIDState *hs)
 
 if (hs->datain)
 hs->datain(hs->datain_opaque);
+
+if (hs->dev.remote_wakeup)
+usb_remote_wakeup(&hs->dev);
 }
 
 static void usb_mouse_event(void *opaque,
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 1d83400..674cb0c 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -59,6 +59,7 @@
 
 #define UHCI_PORT_RESET (1 << 9)
 #define UHCI_PORT_LSDA  (1 << 8)
+#define UHCI_PORT_RD(1 << 6)
 #define UHCI_PORT_ENC   (1 << 3)
 #define UHCI_PORT_EN(1 << 2)
 #define UHCI_PORT_CSC   (1 << 1)
@@ -501,6 +502,7 @@ static void uhci_ioport_writew(void *opaque, uint32_t addr, 
uint32_t val)
 port->ctrl = (port->ctrl & 0x01fb) | (val & ~0x01fb);
 /* some bits are reset when a '1' is written to them */
 port->ctrl &= ~(val & 0x000a);
+port->ctrl &= ~(port->ctrl & 0x0040); /* clear port resume 
detected */
 }
 break;
 }
@@ -593,6 +595,43 @@ static void uhci_resume (void *opaque)
 }
 }
 
+static UHCIPort *find_port(UHCIState *s, USBDevice *d)
+{
+int i;
+
+for (i = 0; i < NB_PORTS; i++) {
+UHCIPort *port = &s->ports[i];
+
+if (d == port->port.dev) {
+return port;
+}
+}
+
+return NULL;
+}
+
+static void uhci_event(USBDevice *dev)
+{
+USBBus *bus = usb_bus_from_device(dev);
+UHCIState *s = container_of(bus, UHCIState, bus);
+
+if (s->cmd & UHCI_CMD_EGSM) {
+UHCIPort *port = find_port(s, dev);
+
+if (!port) {
+return;
+}
+
+if (port->ctrl & UHCI_PORT_RD) {
+return;
+}
+
+port->ctrl |= UHCI_PORT_RD;
+
+uhci_resume(s);
+}
+}
+
 static void uhci_attach(USBPort *port1, USBDevice *dev)
 {
 UHCIState *s = port1->opaque;
@@ -602,6 +641,7 @@ static void uhci_attach(USBPort *port1, USBDevice *dev)
 if (port->port.dev) {
 usb_attach(port1, NULL);
 }
+dev->info->remote_wakeup_cb = uhci_event;
 /* set connect status */
 port->ctrl |= UHCI_PORT_CCS | UHCI_PORT_CSC;
 
diff --git a/hw/usb.c b/hw/usb.c
index a326bcf..9b24d49 100644
--- a/hw/usb.c
+++ b/hw/usb.c
@@ -229,3 +229,9 @@ void usb_send_msg(USBDevice *dev, int msg)
 
 /* This _must_ be synchronous */
 }
+
+void usb_remote_wakeup(USBDevice *dev)
+{
+if (dev->info->remote_wakeup_cb)
+dev->info->remote_wakeup_cb(dev);
+}
diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..16de1c9 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -189,6 +189,11 @@ struct USBDeviceInfo {
  */
 int (*handle_data)(USBDevice *dev, USBPacket *p);
 
+/*
+ * Process remote wakeup request.
+ */
+void (*remote_wakeup_cb)(USBDevice *dev);
+
 const char *product_desc;
 
 /* handle legacy -usbdevice command line options */
@@ -317,6 +322,7 @@ void usb_unregister_port(USBBus *bus, USBPort *port);
 int usb_device_attach(USBDevice *dev);
 int usb_device_detach(USBDevice *dev);
 int usb_device_delete_addr(int busnr, int addr);
+void usb_remote_wakeup(USBDevice *dev);
 
 static inline USBBus *usb_bus_from_device(USBDevice *d)
 {

Re: [Qemu-devel] [PATCH 13/15] scsi: Implement alloc_req_iov callback

On Thu, Nov 25, 2010 at 09:53:25AM +0100, Hannes Reinecke wrote:
> Looked into it.
> Sure I could be doing it for scsi-disk; for scsi-generic it won't
> work, though. And it's not much of a code-share to have from it;
> you'll end up with something like:

Yes, and that is a good start to completely get rid of the non-iovec
version.  Keeping two parallel APIs around that have slighly mismatching
semantics is a bad idea.  And for scsi-generic in the version in your
the difference is even worse and more subtile.

I think the only way to get this interface future proof is to unify
it.  That is always pass an iovec from the HBA driver, and make the
length chunking an explicitly flag passed to ->alloc_req instead of
an implicit one when using the old interface.  Then refactor the code
currently resetting.

Talking about scsi-generic, how is the auto request-sense in 
scsi_read_data and the mode select snooping in scsi_write_complete
supposed to for for the iovec interface?

> And for the naming:
> The SCSI stack is using 'req' for every function accepting
> SCSIRequest as an argument:
> 
> hw/scsi.h:
> SCSIRequest *scsi_req_alloc(size_t size, SCSIDevice *d,
>   uint32_t tag, uint32_t lun);
> void scsi_req_free(SCSIRequest *req);
> 
> int scsi_req_parse(SCSIRequest *req, uint8_t *buf);
> void scsi_req_print(SCSIRequest *req);
> void scsi_req_complete(SCSIRequest *req);
> 
> So using 'alloc_req' and 'free_req' is in line with this naming
> scheme. Using 'alloc_request' and 'free_request' really looked odd
> in the light of the general usage.

Keeping the method names is fine, but please name the implementations
matching it, e.g.

scsi_alloc_req and co.

And yes, using the scsi_ prefix is a bit confusing with the generic
code also using it, eventually the disk driver should use scsi_disk
and the generic driver scsi_generic prefixes.

And in general it would be nice if you could simplify answer to reviews.
If something that the reviewer requests doesn't make sense state so in
reply instead of silently ignoring it.

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum

2010-11-25 Thread wolfgang mueller


Alexander,
the people we are addressing and we would like to bring together is from 
the QEMU emulation community.
We are interested in running different ISAs mainly under Linux and 
Windows versions. There is a huge additional
interest from industry for this part to QEMU for embedded systems/SW 
development. The focus we have chosen
for the DATE conference is SystemC integration with QEMU emulation since 
the embedded systems and SystemC
community meets at DATE so that we expect several people from them to 
attend. However, as already written, we
basically failed to find any indication for contact point for the 
emulation community. Any pointers are highly appreciated.


Virtualization  is not of any interest in that workshop as there if 
course already exists the KVM forum you refered to.
I understood from the available information and contacts that there is a 
common consensus that the QEMU
virtualization community is denoted as "KVM community" and not as "QEMU 
community" which also brings the
difference to the point, right? My understanding so far is that "QEMU 
community" refers mainly to the software emulation

people part.

PS: I have no idea about the number of people who are on the 
qemu-devel@nongnu.org list we are cc'ing.
I hope there are not too many and that they are interested in our 
communication. Otherwise, I apologize.


w.


On 25.11.2010 12:03, Alexander Graf wrote:

Wolfgang,

On 25.11.2010, at 11:30, wolfgang mueller wrote:


Dear Alexander Graf,
thank you for contacting me.
I hope that I am right when I understand your below email as a 
complaint that we have not contacted you before organizing

this event.


The complaint is mostly that you have not approached the community, 
yes :).


First of all, we understand our event not as an official QEMU event 
nor have we stated this anywhere or that that we are the

owners of QEMU.

Let me explain about the background of the Workshop.
We as QEMU users, occasionally meet other QEMU users at conferences 
and we observed that the number was significantly growing
during the last years (thanks to the excellent work of the 
developers). We googled for any contacts to other QEMU users and
did neither found any workshop nor any mailing list or anything 
similar we could contact. The only thing we found as a main contact
was Fabrice  Bellard and a huge set of developers (~3000). We saw 
Fabrice Bellard as the "owner" and contacted him. Unfortunately

he rejected as he has no longer interest in QEMU.


I guess we should really remove most traces of Fabrice if he isn't 
even helpful enough to direct you to the mailing list. The maintainer 
situation should be explained in the MAINTAINERS file in the qemu 
source tree. Apparently the last attempt to redo that file and make it 
contain actual current information failed. Sigh.


There is a group of people with commit rights to the source tree. Each 
of them have special and in general different fields of interest. 
There are also several submaintainers who keep track of subsystems, 
but don't have commit rights and route everything through the few 
people with commit rights.


In general, it's similar to the Linux kernel, but with a schizophrenic 
Linus.


So the "right thing" to do would have been to send a mail to the 
qemu-devel mailing list, asking for feedback. The right people 
definitely do read the list.


As we did not find any current "leader" or dedicated leading group 
beyond the web site, we decided to move on since we were interested
to get the QEMU users together to join efforts and exchange ideas and 
developments (The alternative would have been to contact
all over 3000 QEMU developers and to discuss with them the 
organization of such a event. However, from the first idea to the
possibility to get it accepted in the framework of the DATE 
conference were very few weeks so that we did not see it as a viable

alternative).

I now understand that we obviously missed your role in that community 
as the leader or one of the leaders and qemu-devel@nongnu.org
as the community or part of the community. Therefore, we apologize 
that we did not contact you or qemu-de...@nongnu.org.


Don't worry about me. I feel myself in general rather representing 
minorities in qemu. The closest to a "leader" position in qemu these 
days is probably Anthony Liguori. CC'ing him.




However, currently though already very late, we could offer you that 
you can join and and we can list you as a third organizer.
But you have to make an immediate decision as the DATE program will 
go to print in about 10 days. Otherwise you will be only

listed on the web.

Additionally, we are still looking for a person who is giving a 
general 45-minute QEMU tutorial/overview. As we were enforce by the
hosting DATE conference to put a name there, please just take it as a 
placeholder for the worst case that we do not find anybody else.

Are you interested or anybody from qemu-de...@nongnu.org?


This is exactly the reason I a

[Qemu-devel] Re: [PATCH 14/15] megasas: LSI Megaraid SAS emulation

On Thu, Nov 25, 2010 at 2:50 PM, Hannes Reinecke  wrote:
> On 11/25/2010 03:36 PM, Stefan Hajnoczi wrote:
>> On Wed, Nov 24, 2010 at 11:16 AM, Hannes Reinecke  wrote:
>>> +static int megasas_pd_get_info_submit(SCSIDevice * sdev, int lun,
>>> +                                      struct megasas_cmd_t *cmd)
>>> +{
>>> +    struct mfi_pd_info * info = cmd->iov_buf;
>>> +    uint8_t cmdbuf[6];
>>> +    SCSIRequest *req;
>>> +
>>> +    if (info->inquiry_data[4] == 0) {
>>> +        /* Additional length is zero, resubmit */
>>> +        megasas_setup_inquiry(cmdbuf, 0, info->inquiry_data,
>>> +                              sizeof(info->inquiry_data));
>>> +        req = sdev->info->alloc_req(sdev, (uint32_t) -1, lun);
>>> +        if (!req) {
>>> +            return MFI_STAT_FLASH_ALLOC_FAIL;
>>> +        }
>>> +        DPRINTF_DCMD("PD get info submit std inquiry to dev %d\n", lun);
>>> +        req->hba_private = cmd;
>>> +        if (cmd->sdev->info->send_command(req, cmdbuf) > 0)
>>> +            cmd->sdev->info->read_data(req);
>>> +        return MFI_STAT_INVALID_STATUS;
>>
>> Here...
>>
>>> +    } else if (info->vpd_page83[3] == 0) {
>>> +        /* Additional length is zero, resubmit */
>>> +        megasas_setup_inquiry(cmdbuf, 0x83,(uint8_t *)info->vpd_page83,
>>> +                              sizeof(info->vpd_page83));
>>> +        req = sdev->info->alloc_req(sdev, (uint32_t) -1, lun);
>>> +        if (!req) {
>>> +            return MFI_STAT_FLASH_ALLOC_FAIL;
>>> +        }
>>> +        DPRINTF_DCMD("PD get info submit vpd inquiry to dev %d\n", lun);
>>> +        req->hba_private = cmd;
>>> +        if (cmd->sdev->info->send_command(req, cmdbuf) > 0)
>>> +            cmd->sdev->info->read_data(req);
>>> +        return MFI_STAT_INVALID_STATUS;
>>
>> ...and here I can't tell for sure if an error status is returned
>> intentionally or whether this is an if statement without {}-related
>> bug.
>>
>> On one hand it looks like it could be intentional.  On the other hand
>> we went through the trouble of sending an inquiry command that may
>> have succeeded but we're still returning an error status.
>>
>
> MFI_STAT_INVALID_STATUS is _not_ an error status. It's used
> internally to signal that a command is still being processed.
> ->read_data() itself doesn't have a meaningful return code;
> we need to wait for the ->complete callback to get results.
> So we're returning MFI_STAT_INVALID_STATUS to signal this condition.
>
> So that's ok.

Okay, thanks for explaining.

Stefan

[Qemu-devel] Re: [PATCH 14/15] megasas: LSI Megaraid SAS emulation

On 11/25/2010 03:36 PM, Stefan Hajnoczi wrote:
> On Wed, Nov 24, 2010 at 11:16 AM, Hannes Reinecke  wrote:
>> +static int megasas_pd_get_info_submit(SCSIDevice * sdev, int lun,
>> +  struct megasas_cmd_t *cmd)
>> +{
>> +struct mfi_pd_info * info = cmd->iov_buf;
>> +uint8_t cmdbuf[6];
>> +SCSIRequest *req;
>> +
>> +if (info->inquiry_data[4] == 0) {
>> +/* Additional length is zero, resubmit */
>> +megasas_setup_inquiry(cmdbuf, 0, info->inquiry_data,
>> +  sizeof(info->inquiry_data));
>> +req = sdev->info->alloc_req(sdev, (uint32_t) -1, lun);
>> +if (!req) {
>> +return MFI_STAT_FLASH_ALLOC_FAIL;
>> +}
>> +DPRINTF_DCMD("PD get info submit std inquiry to dev %d\n", lun);
>> +req->hba_private = cmd;
>> +if (cmd->sdev->info->send_command(req, cmdbuf) > 0)
>> +cmd->sdev->info->read_data(req);
>> +return MFI_STAT_INVALID_STATUS;
> 
> Here...
> 
>> +} else if (info->vpd_page83[3] == 0) {
>> +/* Additional length is zero, resubmit */
>> +megasas_setup_inquiry(cmdbuf, 0x83,(uint8_t *)info->vpd_page83,
>> +  sizeof(info->vpd_page83));
>> +req = sdev->info->alloc_req(sdev, (uint32_t) -1, lun);
>> +if (!req) {
>> +return MFI_STAT_FLASH_ALLOC_FAIL;
>> +}
>> +DPRINTF_DCMD("PD get info submit vpd inquiry to dev %d\n", lun);
>> +req->hba_private = cmd;
>> +if (cmd->sdev->info->send_command(req, cmdbuf) > 0)
>> +cmd->sdev->info->read_data(req);
>> +return MFI_STAT_INVALID_STATUS;
> 
> ...and here I can't tell for sure if an error status is returned
> intentionally or whether this is an if statement without {}-related
> bug.
> 
> On one hand it looks like it could be intentional.  On the other hand
> we went through the trouble of sending an inquiry command that may
> have succeeded but we're still returning an error status.
> 

MFI_STAT_INVALID_STATUS is _not_ an error status. It's used
internally to signal that a command is still being processed.
->read_data() itself doesn't have a meaningful return code;
we need to wait for the ->complete callback to get results.
So we're returning MFI_STAT_INVALID_STATUS to signal this condition.

So that's ok.

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 1/5] block: add discard support

On Thu, Nov 25, 2010 at 1:57 PM, Christoph Hellwig  wrote:
> +int bdrv_discard(BlockDriverState *bs, int64_t sector_num, int nb_sectors)
> +{
> +    if (!bs->drv || !bs->drv->bdrv_discard)
> +        return 0;

!bs->drv is normally -ENOMEDIUM.  Perhaps we shouldn't lump it in with
!bs->drv->bdrv_discard.

Stefan

Re: [Qemu-devel] [PATCH 06/15] scsi: Update sense code handling

2010-11-25 Thread Kevin Wolf

Am 24.11.2010 12:16, schrieb Hannes Reinecke:
> The SCSI spec has a quite detailed list of sense codes available.
> It even mandates the use of specific ones for some failure cases.
> The current implementation just has one type of 'generic' error
> which is actually a violation of the spec in certain cases.
> This patch introduces various predefined sense codes to have the
> sense code reporting more in line with the spec.
> 
> Signed-off-by: Hannes Reinecke 
> Acked-by: Christoph Hellwig 
> ---
>  hw/scsi-bus.c |   92 
>  hw/scsi-disk.c|  109 
> +++--
>  hw/scsi-generic.c |   76 ++---
>  hw/scsi.h |   38 ++
>  4 files changed, 239 insertions(+), 76 deletions(-)
> 
> diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
> index 93f0e9a..afdf0ad 100644
> --- a/hw/scsi-bus.c
> +++ b/hw/scsi-bus.c
> @@ -388,6 +388,98 @@ int scsi_req_parse(SCSIRequest *req, uint8_t *buf)
>  return 0;
>  }
>  
> +/*
> + * Predefined sense codes
> + */
> +
> +/* No sense data available */
> +const struct SCSISense sense_code_NO_SENSE = {
> +.key = NO_SENSE , .asc = 0x00 , .ascq = 0x00
> +};
> +
> +/* LUN not ready, Manual intervention required */
> +const struct SCSISense sense_code_LUN_NOT_READY = {
> +.key = NOT_READY, .asc = 0x04, .ascq = 0x03
> +};
> +
> +/* LUN not ready, Medium not present */
> +const struct SCSISense sense_code_NO_MEDIUM = {
> +.key = NOT_READY, .asc = 0x3a, .ascq = 0x00
> +};
> +
> +/* Hardware error, internal target failure */
> +const struct SCSISense sense_code_TARGET_FAILURE = {
> +.key = HARDWARE_ERROR, .asc = 0x44, .ascq = 0x00
> +};
> +
> +/* Illegal request, invalid command operation code */
> +const struct SCSISense sense_code_INVALID_OPCODE = {
> +.key = ILLEGAL_REQUEST, .asc = 0x20, .ascq = 0x00
> +};
> +
> +/* Illegal request, LBA out of range */
> +const struct SCSISense sense_code_LBA_OUT_OF_RANGE = {
> +.key = ILLEGAL_REQUEST, .asc = 0x21, .ascq = 0x00
> +};
> +
> +/* Illegal request, Invalid field in CDB */
> +const struct SCSISense sense_code_INVALID_FIELD = {
> +.key = ILLEGAL_REQUEST, .asc = 0x24, .ascq = 0x00
> +};
> +
> +/* Illegal request, LUN not supported */
> +const struct SCSISense sense_code_LUN_NOT_SUPPORTED = {
> +.key = ILLEGAL_REQUEST, .asc = 0x25, .ascq = 0x00
> +};
> +
> +/* Command aborted, I/O process terminated */
> +const struct SCSISense sense_code_IO_ERROR = {
> +.key = ABORTED_COMMAND, .asc = 0x00, .ascq = 0x06
> +};
> +
> +/* Command aborted, I_T Nexus loss occurred */
> +const struct SCSISense sense_code_I_T_NEXUS_LOSS = {
> +.key = ABORTED_COMMAND, .asc = 0x29, .ascq = 0x07
> +};
> +
> +/* Command aborted, Logical Unit failure */
> +const struct SCSISense sense_code_LUN_FAILURE = {
> +.key = ABORTED_COMMAND, .asc = 0x3e, .ascq = 0x01
> +};
> +
> +/*
> + * scsi_build_sense
> + *
> + * Build a sense buffer
> + */
> +int scsi_build_sense(SCSISense sense, uint8_t *buf, int len, int fixed)
> +{
> +if (len < 8)
> +return 0;
> +if (fixed && len < 14)
> +return 0;
> +
> +memset(buf, 0, len);
> +if (fixed) {
> +/* Return fixed format sense buffer */
> +buf[0] = 0xf0;
> +buf[2] = sense.key;
> +buf[7] = 7;
> +buf[12] = sense.asc;
> +buf[13] = sense.ascq;
> +len = 14;

My spec says: "Device servers shall return at least 18 bytes of
parameter data in response to a REQUEST SENSE command if the allocation
length is 18 or greater and the DESC bit is set to zero."

So should this be MIN(len, 18) instead?

Kevin

[Qemu-devel] Re: [PATCH 14/15] megasas: LSI Megaraid SAS emulation

On Wed, Nov 24, 2010 at 11:16 AM, Hannes Reinecke  wrote:
> +static int megasas_pd_get_info_submit(SCSIDevice * sdev, int lun,
> +                                      struct megasas_cmd_t *cmd)
> +{
> +    struct mfi_pd_info * info = cmd->iov_buf;
> +    uint8_t cmdbuf[6];
> +    SCSIRequest *req;
> +
> +    if (info->inquiry_data[4] == 0) {
> +        /* Additional length is zero, resubmit */
> +        megasas_setup_inquiry(cmdbuf, 0, info->inquiry_data,
> +                              sizeof(info->inquiry_data));
> +        req = sdev->info->alloc_req(sdev, (uint32_t) -1, lun);
> +        if (!req) {
> +            return MFI_STAT_FLASH_ALLOC_FAIL;
> +        }
> +        DPRINTF_DCMD("PD get info submit std inquiry to dev %d\n", lun);
> +        req->hba_private = cmd;
> +        if (cmd->sdev->info->send_command(req, cmdbuf) > 0)
> +            cmd->sdev->info->read_data(req);
> +        return MFI_STAT_INVALID_STATUS;

Here...

> +    } else if (info->vpd_page83[3] == 0) {
> +        /* Additional length is zero, resubmit */
> +        megasas_setup_inquiry(cmdbuf, 0x83,(uint8_t *)info->vpd_page83,
> +                              sizeof(info->vpd_page83));
> +        req = sdev->info->alloc_req(sdev, (uint32_t) -1, lun);
> +        if (!req) {
> +            return MFI_STAT_FLASH_ALLOC_FAIL;
> +        }
> +        DPRINTF_DCMD("PD get info submit vpd inquiry to dev %d\n", lun);
> +        req->hba_private = cmd;
> +        if (cmd->sdev->info->send_command(req, cmdbuf) > 0)
> +            cmd->sdev->info->read_data(req);
> +        return MFI_STAT_INVALID_STATUS;

...and here I can't tell for sure if an error status is returned
intentionally or whether this is an if statement without {}-related
bug.

On one hand it looks like it could be intentional.  On the other hand
we went through the trouble of sending an inquiry command that may
have succeeded but we're still returning an error status.

Stefan

Re: [Qemu-devel] [PATCH 2/5] scsi-disk: support WRITE SAME (16) with unmap bit

2010-11-25 Thread malc

On Thu, 25 Nov 2010, Christoph Hellwig wrote:

> Support discards via the WRITE SAME command with the unmap bit set, and
> tell the initiator about the support for it via the block limit and the
> new thin provisioning EVPD pages.  Also fix the comment which incorrectly
> describedthe block limits EVPD page.
> 
Tabs again.

-- 
mailto:av1...@comtv.ru

Re: [Qemu-devel] [PATCH 4/5] ide: add TRIM support

2010-11-25 Thread malc

On Thu, 25 Nov 2010, Christoph Hellwig wrote:

> Add support for the data set management command, and the TRIM sub function
> in it.

Tabs.

[..snip..]

-- 
mailto:av1...@comtv.ru

Re: [Qemu-devel] [PATCH 1/5] block: add discard support

2010-11-25 Thread malc

On Thu, 25 Nov 2010, Christoph Hellwig wrote:

> Add a new bdrv_discard method to free blocks in a mapping image, and a new
> drive property to set the granularity for these discard.  If no discard
> granularity support is set discard support is disabled.
> 
> Signed-off-by: Christoph Hellwig 
> 
> Index: qemu/block.c
> ===
> --- qemu.orig/block.c 2010-11-25 12:34:10.580256183 +0100
> +++ qemu/block.c  2010-11-25 12:34:41.761254654 +0100
> @@ -1499,6 +1499,13 @@ int bdrv_has_zero_init(BlockDriverState
>  return 1;
>  }
>  
> +int bdrv_discard(BlockDriverState *bs, int64_t sector_num, int nb_sectors)
> +{
> +if (!bs->drv || !bs->drv->bdrv_discard)
> +return 0;
> +return bs->drv->bdrv_discard(bs, sector_num, nb_sectors);
> +}
> +
>  /*
>   * Returns true iff the specified sector is present in the disk image. 
> Drivers
>   * not implementing the functionality are assumed to not support backing 
> files,
> Index: qemu/block.h
> ===
> --- qemu.orig/block.h 2010-11-25 12:34:10.589253738 +0100
> +++ qemu/block.h  2010-11-25 12:34:12.148012156 +0100
> @@ -146,6 +146,7 @@ int bdrv_flush(BlockDriverState *bs);
>  void bdrv_flush_all(void);
>  void bdrv_close_all(void);
>  
> +int bdrv_discard(BlockDriverState *bs, int64_t sector_num, int nb_sectors);
>  int bdrv_has_zero_init(BlockDriverState *bs);
>  int bdrv_is_allocated(BlockDriverState *bs, int64_t sector_num, int 
> nb_sectors,
>   int *pnum);
> Index: qemu/block_int.h
> ===
> --- qemu.orig/block_int.h 2010-11-25 12:34:10.595254018 +0100
> +++ qemu/block_int.h  2010-11-25 12:34:12.150013832 +0100
> @@ -73,6 +73,8 @@ struct BlockDriver {
>  BlockDriverCompletionFunc *cb, void *opaque);
>  BlockDriverAIOCB *(*bdrv_aio_flush)(BlockDriverState *bs,
>  BlockDriverCompletionFunc *cb, void *opaque);
> +int (*bdrv_discard)(BlockDriverState *bs, int64_t sector_num,
> +int nb_sectors);
>  
>  int (*bdrv_aio_multiwrite)(BlockDriverState *bs, BlockRequest *reqs,
>  int num_reqs);
> @@ -227,6 +229,7 @@ typedef struct BlockConf {
>  uint16_t logical_block_size;
>  uint16_t min_io_size;
>  uint32_t opt_io_size;
> +uint32_t discard_granularity;
>  } BlockConf;
>  
>  static inline unsigned int get_physical_block_exp(BlockConf *conf)
> @@ -249,6 +252,8 @@ static inline unsigned int get_physical_
>  DEFINE_PROP_UINT16("physical_block_size", _state,   \
> _conf.physical_block_size, 512), \
>  DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0),  \
> -DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0)
> +DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0), \
> +DEFINE_PROP_UINT32("discard_granularity", _state, \
> + _conf.discard_granularity, 0)

Tab here.

>  
>  #endif /* BLOCK_INT_H */
> Index: qemu/block/raw.c
> ===
> --- qemu.orig/block/raw.c 2010-11-25 12:34:10.601259605 +0100
> +++ qemu/block/raw.c  2010-11-25 12:34:12.155004124 +0100
> @@ -65,6 +65,11 @@ static int raw_probe(const uint8_t *buf,
> return 1; /* everything can be opened as raw image */
>  }
>  
> +static int raw_discard(BlockDriverState *bs, int64_t sector_num, int 
> nb_sectors)
> +{
> +return bdrv_discard(bs->file, sector_num, nb_sectors);
> +}
> +
>  static int raw_is_inserted(BlockDriverState *bs)
>  {
>  return bdrv_is_inserted(bs->file);
> @@ -130,6 +135,7 @@ static BlockDriver bdrv_raw = {
>  .bdrv_aio_readv = raw_aio_readv,
>  .bdrv_aio_writev= raw_aio_writev,
>  .bdrv_aio_flush = raw_aio_flush,
> +.bdrv_discard   = raw_discard,
>  
>  .bdrv_is_inserted   = raw_is_inserted,
>  .bdrv_eject = raw_eject,
> 

-- 
mailto:av1...@comtv.ru

[Qemu-devel] Re: [RfC PATCH] spice: qmp windup: connection events & info command.

2010-11-25 Thread Luiz Capitulino

On Thu, 25 Nov 2010 12:42:52 +0100
Gerd Hoffmann  wrote:

>Hi,
> 
> > The first thing we have to check with Daniel is whether or not we're
> > providing the info they would need/expect,
> 
> Daniel?
> 
> > apart from that I have the
> > following general comments:
> >
> >   1. It's missing documentation in QMP/qmp-events.txt and qmp-commands.hx
> >  (yeah, docs are far from code, hope to fix soon)
> 
> Ok.
> 
> >   2. Can you please split this in two patches? One adding the events and
> >  the other adding the query command
> 
> Doesn't make that much sense IMHO as the both provide quite simliar 
> informations (i.e. "info spice" gives you a list of connections with 
> pretty much the same info provided by the events).

Still, they're different interfaces, also it's going to be a little bit harder
to review now that you're going to introduce the docs in the same patch.

> >> +/*
> >> + * generic print handler for hmp 'info $what'
> >> + * simply pretty-print the josn representation
> >> + */
> >> +#if defined(CONFIG_SPICE) /* because 'info spice' is the only user */
> >> +static void do_info_generic_print(Monitor *mon, const QObject *data)
> >> +{
> >> +QString *json = qobject_to_json_pretty(data);
> >> +monitor_printf(mon, "%s\n", qstring_get_str(json));
> >> +QDECREF(json);
> >> +}
> >> +#endif
> >
> > We definitely need a generic print handler, but I don't that stringifying
> > JSON makes a minimal good user interface.
> 
> Well, this is the pretty json version which prints stuff multi-line and 
> with intention.  Certainly not perfect but reasonable readable with 
> minimum effort.  We can replace it with something else when it shows up.

We have refused introducing json as part of our interface with the user
in the past, and it was a good decision: json doesn't make a good user
interface.

We have two options here:

 1. Write a default (user friendly) printer function. Doesn't have to be
fancy, it could just print lists as CSV sequences and dicts like:

   key1: value
   key2: value

Of course it has to handle nested objects.

 2. Write a regular, specific print function, as all info commands available
under QMP do

> 
> >> +static QList *channel_list_get(void)
> >> +{
> >> +ChannelList *item;
> >> +QList *list;
> >> +QDict *dict;
> >> +
> >> +list = qlist_new();
> >> +QTAILQ_FOREACH(item,&channel_list, link) {
> >> +dict = qdict_new();
> >> +add_addr_info(dict,&item->info->paddr, item->info->plen);
> >> +add_channel_info(dict, item->info);
> >> +qlist_append_obj(list, QOBJECT(dict));
> >
> > You can use qlist_append() and drop the QOBJECT() usage.
> >
> 
> Ok.
> 
> cheers,
>Gerd
>

[Qemu-devel] [PATCH 5/5] raw-posix: add discard support

Add support to discard blocks in a raw image residing on an XFS filesystem
by calling the XFS_IOC_UNRESVSP64 ioctl to punch holes.  Support for other
hole punching mechanisms can be added when they become available.

Signed-off-by: Christoph Hellwig 

Index: qemu/block/raw-posix.c
===
--- qemu.orig/block/raw-posix.c 2010-11-25 12:51:18.474004263 +0100
+++ qemu/block/raw-posix.c  2010-11-25 13:00:42.220003844 +0100
@@ -69,6 +69,10 @@
 #include 
 #endif
 
+#ifdef CONFIG_XFS
+#include 
+#endif
+
 //#define DEBUG_FLOPPY
 
 //#define DEBUG_BLOCK
@@ -120,6 +124,9 @@ typedef struct BDRVRawState {
 #endif
 uint8_t *aligned_buf;
 unsigned aligned_buf_size;
+#ifdef CONFIG_XFS
+int is_xfs : 1;
+#endif
 } BDRVRawState;
 
 static int fd_open(BlockDriverState *bs);
@@ -196,6 +203,12 @@ static int raw_open_common(BlockDriverSt
 #endif
 }
 
+#ifdef CONFIG_XFS
+if (platform_test_xfs_fd(s->fd)) {
+s->is_xfs = 1;
+}
+#endif
+
 return 0;
 
 out_free_buf:
@@ -740,6 +753,36 @@ static int raw_flush(BlockDriverState *b
 return qemu_fdatasync(s->fd);
 }
 
+#ifdef CONFIG_XFS
+static int xfs_discard(BDRVRawState *s, int64_t sector_num, int nb_sectors)
+{
+struct xfs_flock64 fl;
+
+memset(&fl, 0, sizeof(fl));
+fl.l_whence = SEEK_SET;
+fl.l_start = sector_num << 9;
+fl.l_len = (int64_t)nb_sectors << 9;
+
+if (xfsctl(NULL, s->fd, XFS_IOC_UNRESVSP64, &fl) < 0) {
+printf("cannot punch hole (%s)\n", strerror(errno));
+return -errno;
+}
+
+return 0;
+}
+#endif
+
+static int raw_discard(BlockDriverState *bs, int64_t sector_num, int 
nb_sectors)
+{
+BDRVRawState *s = bs->opaque;
+
+#ifdef CONFIG_XFS
+if (s->is_xfs)
+return xfs_discard(s, sector_num, nb_sectors);
+#endif
+
+return 0;
+}
 
 static QEMUOptionParameter raw_create_options[] = {
 {
@@ -761,6 +804,7 @@ static BlockDriver bdrv_file = {
 .bdrv_close = raw_close,
 .bdrv_create = raw_create,
 .bdrv_flush = raw_flush,
+.bdrv_discard = raw_discard,
 
 .bdrv_aio_readv = raw_aio_readv,
 .bdrv_aio_writev = raw_aio_writev,
Index: qemu/configure
===
--- qemu.orig/configure 2010-11-25 12:51:18.484004891 +0100
+++ qemu/configure  2010-11-25 13:00:42.222004263 +0100
@@ -288,6 +288,7 @@ xen=""
 linux_aio=""
 attr=""
 vhost_net=""
+xfs=""
 
 gprof="no"
 debug_tcg="no"
@@ -1393,6 +1394,27 @@ EOF
 fi
 
 ##
+# xfsctl() probe, used for raw-posix
+if test "$xfs" != "no" ; then
+  cat > $TMPC << EOF
+#include 
+int main(void)
+{
+xfsctl(NULL, 0, 0, NULL);
+return 0;
+}
+EOF
+  if compile_prog "" "" ; then
+xfs="yes"
+  else
+if test "$xfs" = "yes" ; then
+  feature_not_found "uuid"
+fi
+xfs=no
+  fi
+fi
+
+##
 # vde libraries probe
 if test "$vde" != "no" ; then
   vde_libs="-lvdeplug"
@@ -2354,6 +2376,7 @@ echo "vhost-net support $vhost_net"
 echo "Trace backend $trace_backend"
 echo "Trace output file $trace_file-"
 echo "spice support $spice"
+echo "xfsctl support$xfs"
 
 if test $sdl_too_old = "yes"; then
 echo "-> Your SDL version is too old - please upgrade to have SDL support"
@@ -2499,6 +2522,9 @@ fi
 if test "$uuid" = "yes" ; then
   echo "CONFIG_UUID=y" >> $config_host_mak
 fi
+if test "$xfs" = "yes" ; then
+  echo "CONFIG_XFS=y" >> $config_host_mak
+fi
 qemu_version=`head $source_path/VERSION`
 echo "VERSION=$qemu_version" >>$config_host_mak
 echo "PKGVERSION=$pkgversion" >>$config_host_mak

[Qemu-devel] [PATCH 3/5] make dma_bdrv_io available to drivers

Make dma_bdrv_io available for drivers, and pass an explicit I/O function
instead of hardcoding bdrv_aio_readv/bdrv_aio_writev.  This is required
to implement non-READ/WRITE dma commands in the ide driver, e.g. the
upcoming TRIM support.

Signed-off-by: Christoph Hellwig 

Index: qemu/dma-helpers.c
===
--- qemu.orig/dma-helpers.c 2010-11-23 14:13:42.178253390 +0100
+++ qemu/dma-helpers.c  2010-11-23 14:14:45.186253110 +0100
@@ -47,6 +47,7 @@ typedef struct {
 target_phys_addr_t sg_cur_byte;
 QEMUIOVector iov;
 QEMUBH *bh;
+DMAIOFunc *io_func;
 } DMAAIOCB;
 
 static void dma_bdrv_cb(void *opaque, int ret);
@@ -116,13 +117,8 @@ static void dma_bdrv_cb(void *opaque, in
 return;
 }
 
-if (dbs->is_write) {
-dbs->acb = bdrv_aio_writev(dbs->bs, dbs->sector_num, &dbs->iov,
-   dbs->iov.size / 512, dma_bdrv_cb, dbs);
-} else {
-dbs->acb = bdrv_aio_readv(dbs->bs, dbs->sector_num, &dbs->iov,
-  dbs->iov.size / 512, dma_bdrv_cb, dbs);
-}
+dbs->acb = dbs->io_func(dbs->bs, dbs->sector_num, &dbs->iov,
+dbs->iov.size / 512, dma_bdrv_cb, dbs);
 if (!dbs->acb) {
 dma_bdrv_unmap(dbs);
 qemu_iovec_destroy(&dbs->iov);
@@ -144,12 +140,12 @@ static AIOPool dma_aio_pool = {
 .cancel = dma_aio_cancel,
 };
 
-static BlockDriverAIOCB *dma_bdrv_io(
+BlockDriverAIOCB *dma_bdrv_io(
 BlockDriverState *bs, QEMUSGList *sg, uint64_t sector_num,
-BlockDriverCompletionFunc *cb, void *opaque,
-int is_write)
+DMAIOFunc *io_func, BlockDriverCompletionFunc *cb,
+void *opaque, int is_write)
 {
-DMAAIOCB *dbs =  qemu_aio_get(&dma_aio_pool, bs, cb, opaque);
+DMAAIOCB *dbs = qemu_aio_get(&dma_aio_pool, bs, cb, opaque);
 
 dbs->acb = NULL;
 dbs->bs = bs;
@@ -158,6 +154,7 @@ static BlockDriverAIOCB *dma_bdrv_io(
 dbs->sg_cur_index = 0;
 dbs->sg_cur_byte = 0;
 dbs->is_write = is_write;
+dbs->io_func = io_func;
 dbs->bh = NULL;
 qemu_iovec_init(&dbs->iov, sg->nsg);
 dma_bdrv_cb(dbs, 0);
@@ -173,12 +170,12 @@ BlockDriverAIOCB *dma_bdrv_read(BlockDri
 QEMUSGList *sg, uint64_t sector,
 void (*cb)(void *opaque, int ret), void 
*opaque)
 {
-return dma_bdrv_io(bs, sg, sector, cb, opaque, 0);
+return dma_bdrv_io(bs, sg, sector, bdrv_aio_readv, cb, opaque, 0);
 }
 
 BlockDriverAIOCB *dma_bdrv_write(BlockDriverState *bs,
  QEMUSGList *sg, uint64_t sector,
  void (*cb)(void *opaque, int ret), void 
*opaque)
 {
-return dma_bdrv_io(bs, sg, sector, cb, opaque, 1);
+return dma_bdrv_io(bs, sg, sector, bdrv_aio_writev, cb, opaque, 1);
 }
Index: qemu/dma.h
===
--- qemu.orig/dma.h 2010-11-23 14:13:42.185253809 +0100
+++ qemu/dma.h  2010-11-23 14:14:45.186253110 +0100
@@ -32,6 +32,14 @@ void qemu_sglist_add(QEMUSGList *qsg, ta
  target_phys_addr_t len);
 void qemu_sglist_destroy(QEMUSGList *qsg);
 
+typedef BlockDriverAIOCB *DMAIOFunc(BlockDriverState *bs, int64_t sector_num,
+ QEMUIOVector *iov, int nb_sectors,
+ BlockDriverCompletionFunc *cb, void *opaque);
+
+BlockDriverAIOCB *dma_bdrv_io(BlockDriverState *bs,
+  QEMUSGList *sg, uint64_t sector_num,
+  DMAIOFunc *io_func, BlockDriverCompletionFunc 
*cb,
+  void *opaque, int is_write);
 BlockDriverAIOCB *dma_bdrv_read(BlockDriverState *bs,
 QEMUSGList *sg, uint64_t sector,
 BlockDriverCompletionFunc *cb, void *opaque);

[Qemu-devel] [PATCH 2/5] scsi-disk: support WRITE SAME (16) with unmap bit

Support discards via the WRITE SAME command with the unmap bit set, and
tell the initiator about the support for it via the block limit and the
new thin provisioning EVPD pages.  Also fix the comment which incorrectly
describedthe block limits EVPD page.

Signed-off-by: Christoph Hellwig 

Index: qemu/hw/scsi-disk.c
===
--- qemu.orig/hw/scsi-disk.c2010-11-23 14:14:27.259253110 +0100
+++ qemu/hw/scsi-disk.c 2010-11-23 14:31:41.190253529 +0100
@@ -444,8 +444,10 @@ static int scsi_disk_emulate_inquiry(SCS
 buflen += id_len;
 break;
 }
-case 0xb0: /* block device characteristics */
+case 0xb0: /* block limits */
 {
+unsigned int unmap_sectors =
+s->qdev.conf.discard_granularity / s->qdev.blocksize;
 unsigned int min_io_size =
 s->qdev.conf.min_io_size / s->qdev.blocksize;
 unsigned int opt_io_size =
@@ -465,6 +467,21 @@ static int scsi_disk_emulate_inquiry(SCS
 outbuf[13] = (opt_io_size >> 16) & 0xff;
 outbuf[14] = (opt_io_size >> 8) & 0xff;
 outbuf[15] = opt_io_size & 0xff;
+
+/* optimal unmap granularity */
+outbuf[28] = (unmap_sectors >> 24) & 0xff;
+outbuf[29] = (unmap_sectors >> 16) & 0xff;
+outbuf[30] = (unmap_sectors >> 8) & 0xff;
+outbuf[31] = unmap_sectors & 0xff;
+break;
+}
+case 0xb2: /* thin provisioning */
+{
+outbuf[3] = buflen = 8;
+outbuf[4] = 0;
+outbuf[5] = 0x40;  /* write same with unmap supported */
+outbuf[6] = 0;
+outbuf[7] = 0;
 break;
 }
 default:
@@ -932,6 +949,11 @@ static int scsi_disk_emulate_command(SCS
 outbuf[11] = 0;
 outbuf[12] = 0;
 outbuf[13] = get_physical_block_exp(&s->qdev.conf);
+
+/* set TPE bit if the format supports discard */
+if (s->qdev.conf.discard_granularity)
+outbuf[14] = 0x80;
+
 /* Protection, exponent and lowest lba field left blank. */
 buflen = req->cmd.xfer;
 break;
@@ -1128,6 +1150,30 @@ static int32_t scsi_send_command(SCSIDev
 goto illegal_lba;
 }
 break;
+case WRITE_SAME_16:
+DPRINTF("WRITE SAME(16) (sector %" PRId64 ", count %d)\n", lba, len);
+
+if (lba > s->max_lba) {
+goto illegal_lba;
+}
+
+/*
+ * We only support WRITE SAME with the unmap bit set for now.
+ */
+if (!(buf[1] & 0x8)) {
+goto fail;
+}
+
+rc = bdrv_discard(s->bs, lba * s->cluster_size, len * s->cluster_size);
+if (rc < 0) {
+/* XXX: better error code ?*/
+goto fail;
+}
+
+scsi_req_set_status(&r->req, GOOD, NO_SENSE);
+scsi_req_complete(&r->req);
+scsi_remove_request(r);
+return 0;
 default:
DPRINTF("Unknown SCSI command (%2.2x)\n", buf[0]);
 fail:
Index: qemu/hw/scsi-defs.h
===
--- qemu.orig/hw/scsi-defs.h2010-11-23 14:14:27.267253040 +0100
+++ qemu/hw/scsi-defs.h 2010-11-23 14:23:37.995253808 +0100
@@ -84,6 +84,7 @@
 #define MODE_SENSE_10 0x5a
 #define PERSISTENT_RESERVE_IN 0x5e
 #define PERSISTENT_RESERVE_OUT 0x5f
+#define WRITE_SAME_16 0x93
 #define MAINTENANCE_IN0xa3
 #define MAINTENANCE_OUT   0xa4
 #define MOVE_MEDIUM   0xa5

[Qemu-devel] [PATCH 4/5] ide: add TRIM support

Add support for the data set management command, and the TRIM sub function
in it.

Signed-off-by: Christoph Hellwig 

Index: qemu/hw/ide/core.c
===
--- qemu.orig/hw/ide/core.c 2010-11-25 12:33:40.961255346 +0100
+++ qemu/hw/ide/core.c  2010-11-25 13:00:28.415005802 +0100
@@ -145,6 +145,8 @@ static void ide_identify(IDEState *s)
 put_le16(p + 66, 120);
 put_le16(p + 67, 120);
 put_le16(p + 68, 120);
+if (dev && dev->conf.discard_granularity)
+put_le16(p + 69, (1 << 14));   /* determinate TRIM behavior */
 put_le16(p + 80, 0xf0); /* ata3 -> ata6 supported */
 put_le16(p + 81, 0x16); /* conforms to ata5 */
 /* 14=NOP supported, 5=WCACHE supported, 0=SMART supported */
@@ -171,6 +173,8 @@ static void ide_identify(IDEState *s)
 dev = s->unit ? s->bus->slave : s->bus->master;
 if (dev && dev->conf.physical_block_size)
 put_le16(p + 106, 0x6000 | get_physical_block_exp(&dev->conf));
+if (dev && dev->conf.discard_granularity)
+put_le16(p + 169, 1);  /* TRIM support */
 
 memcpy(s->identify_data, p, sizeof(s->identify_data));
 s->identify_set = 1;
@@ -1787,6 +1791,128 @@ static void ide_clear_hob(IDEBus *bus)
 bus->ifs[1].select &= ~(1 << 7);
 }
 
+typedef struct TrimAIOCB {
+BlockDriverAIOCB common;
+QEMUBH *bh;
+int ret;
+} TrimAIOCB;
+
+static void trim_aio_cancel(BlockDriverAIOCB *acb)
+{
+TrimAIOCB *iocb = container_of(acb, TrimAIOCB, common);
+
+qemu_bh_delete(iocb->bh);
+iocb->bh = NULL;
+qemu_aio_release(iocb);
+}
+
+static AIOPool trim_aio_pool = {
+.aiocb_size = sizeof(TrimAIOCB),
+.cancel = trim_aio_cancel,
+};
+
+static void ide_trim_bh_cb(void *opaque)
+{
+TrimAIOCB *iocb = opaque;
+
+iocb->common.cb(iocb->common.opaque, iocb->ret);
+
+qemu_bh_delete(iocb->bh);
+iocb->bh = NULL;
+
+qemu_aio_release(iocb);
+}
+
+static BlockDriverAIOCB *ide_issue_trim(BlockDriverState *bs,
+int64_t sector_num, QEMUIOVector *qiov, int nb_sectors,
+BlockDriverCompletionFunc *cb, void *opaque)
+{
+TrimAIOCB *iocb;
+int i, j, ret;
+
+iocb = qemu_aio_get(&trim_aio_pool, bs, cb, opaque);
+iocb->bh = qemu_bh_new(ide_trim_bh_cb, iocb);
+iocb->ret = 0;
+
+for (j = 0; j < qiov->niov; j++) {
+uint64_t *buffer = qiov->iov[j].iov_base;
+
+   for (i = 0; i < qiov->iov[j].iov_len / 8; i++) {
+   /* 6-byte LBA + 2-byte range per entry */
+   uint64_t entry = le64_to_cpu(buffer[i]);
+   uint64_t sector = entry & 0xULL;
+   uint16_t count = entry >> 48;
+
+   if (count == 0)
+break;
+
+   ret = bdrv_discard(bs, sector * 512, count * 512);
+if (!iocb->ret)
+iocb->ret = ret;
+   }
+}
+
+qemu_bh_schedule(iocb->bh);
+
+return &iocb->common;
+}
+
+static void ide_trim_dma_cb(void *opaque, int ret)
+{
+BMDMAState *bm = opaque;
+IDEState *s = bmdma_active_if(bm);
+int n;
+int64_t sector_num;
+
+if (ret < 0) {
+if (ide_handle_rw_error(s, -ret,  BM_STATUS_DMA_RETRY))
+return;
+}
+
+n = s->io_buffer_size >> 9;
+sector_num = ide_get_sector(s);
+if (n > 0) {
+dma_buf_commit(s, 0);
+sector_num += n;
+ide_set_sector(s, sector_num);
+s->nsector -= n;
+}
+
+/* end of transfer ? */
+if (s->nsector == 0) {
+s->status = READY_STAT | SEEK_STAT;
+ide_set_irq(s->bus);
+eot:
+bm->status &= ~BM_STATUS_DMAING;
+bm->status |= BM_STATUS_INT;
+bm->dma_cb = NULL;
+bm->unit = -1;
+bm->aiocb = NULL;
+return;
+}
+
+n = s->nsector;
+s->io_buffer_size = n * 512;
+/* launch next transfer */
+if (dma_buf_prepare(bm, 0) == 0)
+goto eot;
+#ifdef DEBUG_AIO
+printf("aio_write: sector_num=%" PRId64 " n=%d\n", sector_num, n);
+#endif
+bm->aiocb = dma_bdrv_io(s->bs, &s->sg, sector_num, ide_issue_trim,
+ide_trim_dma_cb, bm, 1);
+ide_dma_submit_check(s, ide_trim_dma_cb, bm);
+}
+
+static void ide_trim(IDEState *s)
+{
+s->status = READY_STAT | SEEK_STAT | DRQ_STAT | BUSY_STAT;
+s->io_buffer_index = 0;
+s->io_buffer_size = 0;
+s->is_read = 0;
+ide_dma_start(s, ide_trim_dma_cb);
+}
+
 void ide_ioport_write(void *opaque, uint32_t addr, uint32_t val)
 {
 IDEBus *bus = opaque;
@@ -1866,6 +1992,17 @@ void ide_ioport_write(void *opaque, uint
 break;
 
 switch(val) {
+case WIN_DSM:
+switch (s->feature) {
+case DSM_TRIM:
+if (!s->bs)
+   goto abort_cmd;
+ide_trim(s);
+break;
+default:
+   goto abort_cmd;
+}
+break;
 case WIN_IDENTIFY:

[Qemu-devel] [PATCH 1/5] block: add discard support

Add a new bdrv_discard method to free blocks in a mapping image, and a new
drive property to set the granularity for these discard.  If no discard
granularity support is set discard support is disabled.

Signed-off-by: Christoph Hellwig 

Index: qemu/block.c
===
--- qemu.orig/block.c   2010-11-25 12:34:10.580256183 +0100
+++ qemu/block.c2010-11-25 12:34:41.761254654 +0100
@@ -1499,6 +1499,13 @@ int bdrv_has_zero_init(BlockDriverState
 return 1;
 }
 
+int bdrv_discard(BlockDriverState *bs, int64_t sector_num, int nb_sectors)
+{
+if (!bs->drv || !bs->drv->bdrv_discard)
+return 0;
+return bs->drv->bdrv_discard(bs, sector_num, nb_sectors);
+}
+
 /*
  * Returns true iff the specified sector is present in the disk image. Drivers
  * not implementing the functionality are assumed to not support backing files,
Index: qemu/block.h
===
--- qemu.orig/block.h   2010-11-25 12:34:10.589253738 +0100
+++ qemu/block.h2010-11-25 12:34:12.148012156 +0100
@@ -146,6 +146,7 @@ int bdrv_flush(BlockDriverState *bs);
 void bdrv_flush_all(void);
 void bdrv_close_all(void);
 
+int bdrv_discard(BlockDriverState *bs, int64_t sector_num, int nb_sectors);
 int bdrv_has_zero_init(BlockDriverState *bs);
 int bdrv_is_allocated(BlockDriverState *bs, int64_t sector_num, int nb_sectors,
int *pnum);
Index: qemu/block_int.h
===
--- qemu.orig/block_int.h   2010-11-25 12:34:10.595254018 +0100
+++ qemu/block_int.h2010-11-25 12:34:12.150013832 +0100
@@ -73,6 +73,8 @@ struct BlockDriver {
 BlockDriverCompletionFunc *cb, void *opaque);
 BlockDriverAIOCB *(*bdrv_aio_flush)(BlockDriverState *bs,
 BlockDriverCompletionFunc *cb, void *opaque);
+int (*bdrv_discard)(BlockDriverState *bs, int64_t sector_num,
+int nb_sectors);
 
 int (*bdrv_aio_multiwrite)(BlockDriverState *bs, BlockRequest *reqs,
 int num_reqs);
@@ -227,6 +229,7 @@ typedef struct BlockConf {
 uint16_t logical_block_size;
 uint16_t min_io_size;
 uint32_t opt_io_size;
+uint32_t discard_granularity;
 } BlockConf;
 
 static inline unsigned int get_physical_block_exp(BlockConf *conf)
@@ -249,6 +252,8 @@ static inline unsigned int get_physical_
 DEFINE_PROP_UINT16("physical_block_size", _state,   \
_conf.physical_block_size, 512), \
 DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0),  \
-DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0)
+DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0), \
+DEFINE_PROP_UINT32("discard_granularity", _state, \
+   _conf.discard_granularity, 0)
 
 #endif /* BLOCK_INT_H */
Index: qemu/block/raw.c
===
--- qemu.orig/block/raw.c   2010-11-25 12:34:10.601259605 +0100
+++ qemu/block/raw.c2010-11-25 12:34:12.155004124 +0100
@@ -65,6 +65,11 @@ static int raw_probe(const uint8_t *buf,
return 1; /* everything can be opened as raw image */
 }
 
+static int raw_discard(BlockDriverState *bs, int64_t sector_num, int 
nb_sectors)
+{
+return bdrv_discard(bs->file, sector_num, nb_sectors);
+}
+
 static int raw_is_inserted(BlockDriverState *bs)
 {
 return bdrv_is_inserted(bs->file);
@@ -130,6 +135,7 @@ static BlockDriver bdrv_raw = {
 .bdrv_aio_readv = raw_aio_readv,
 .bdrv_aio_writev= raw_aio_writev,
 .bdrv_aio_flush = raw_aio_flush,
+.bdrv_discard   = raw_discard,
 
 .bdrv_is_inserted   = raw_is_inserted,
 .bdrv_eject = raw_eject,

[Qemu-devel] [PATCH 0/5] add TRIM/UNMAP support

This patchset adds support for the ATA TRIM and SCSI WRITE SAME with
unmap commands, which allow reclaiming free space from a backing image.

The user facing implementation is pretty complete, but not really
efficient because the underlying bdrv_discard implementation doesn't
use the aio implementation yet.  The reason for that is that the SCSI
layer doesn't really allow any asynchronous commands except for
READ/WRITE by design, and implementing the ATA TRIM command with it's
multiple ranges is rather painful, and combined with the SCSI limitation
I didn't bother yet.  The only backend support so far is the XFS hole
punching ioctl, but others can be added easily when they become
available.  A virtio implementation for a discard command would also
be pretty easy, but until we actually support a better backend then
a plain sparse file it's not worth using for production enviroments
anyway, but more for playing with the thin provisioning infrastructure,
or observing guest behaviour when TRIM / unmap is supported.

If the support is enabled and the backend doesn't support hole punching
the TRIM / WRITE SAME commands become no-ops so that migration from
hosts supporting or not supporting it works.

[Qemu-devel] Re: [PATCH v2] correct migrate_set_speed's args_type

2010-11-25 Thread Luiz Capitulino

On Thu, 25 Nov 2010 09:06:05 +0800
Wen Congyang  wrote:

> The args_type of migrate_set_speed in qmp-commands.hx is wrong.
> When we set migrate speed by json, qemu will be core dumped.
> 
> This bug was caused by 07de3e60b05 and hence affects master only.
> 
> Signed-off-by: Wen Congyang 

Applied, thanks.

> 
> ---
>  qmp-commands.hx |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index 793cf1c..16bdb08 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -495,7 +495,7 @@ EQMP
>  
>  {
>  .name   = "migrate_set_speed",
> -.args_type  = "value:f",
> +.args_type  = "value:o",
>  .params = "value",
>  .help   = "set maximum speed (in bytes) for migrations",
>  .user_print = monitor_user_noop,
> -- 1.7.1 
>

Re: [Qemu-devel] [PATCH] Make SCSI HBA configurable


On 25.11.2010, at 14:22, Paul Brook wrote:

>> On 25.11.2010, at 11:59, Paul Brook wrote:
 This patch introduces configuration variables
 CONFIG_SCSI_LSI
 CONFIG_SCSI_MEGASAS
 and renames the existing CONFIG_ESP to CONFIG_SCSI_ESP.
 With this the available SCSI HBAs can be configured for each
 target configuration instead of compiling it in for everyone.
>>> 
>>> No. These are both PCI devices, I see no particularly good reason to make
>>> them optional. At minimum they should be enabled by default on all
>>> configs.
>>> 
>>> The ESP controller is different because it is't a general purpose device,
>>> and only makes sense on certain systems.
>> 
>> RH needs to compile out as much as they can from the code base, because
>> they state that they support everything that's compiled in. So making as
>> much as possible optional is good. And I don't see why we should limit
>> ourselves here.
> 
> My second point (should be enabled by default) still applies.  Your patch 
> removes the lsi controller from the default arm-softmmu config, which is 
> definitely wrong.

My patches don't even touch the LSI controller. I guess you meant Hannes.
But I agree. Enablement-wise nothing should change before and after the patch.


Alex

Re: [Qemu-devel] [PATCH] Make SCSI HBA configurable

> On 25.11.2010, at 11:59, Paul Brook wrote:
> >> This patch introduces configuration variables
> >> CONFIG_SCSI_LSI
> >> CONFIG_SCSI_MEGASAS
> >> and renames the existing CONFIG_ESP to CONFIG_SCSI_ESP.
> >> With this the available SCSI HBAs can be configured for each
> >> target configuration instead of compiling it in for everyone.
> > 
> > No. These are both PCI devices, I see no particularly good reason to make
> > them optional. At minimum they should be enabled by default on all
> > configs.
> > 
> > The ESP controller is different because it is't a general purpose device,
> > and only makes sense on certain systems.
> 
> RH needs to compile out as much as they can from the code base, because
> they state that they support everything that's compiled in. So making as
> much as possible optional is good. And I don't see why we should limit
> ourselves here.

My second point (should be enabled by default) still applies.  Your patch 
removes the lsi controller from the default arm-softmmu config, which is 
definitely wrong.

Paul

Re: [Qemu-devel] [PATCH] Make SCSI HBA configurable

On 25.11.2010, at 11:59, Paul Brook wrote:

>> This patch introduces configuration variables
>> CONFIG_SCSI_LSI
>> CONFIG_SCSI_MEGASAS
>> and renames the existing CONFIG_ESP to CONFIG_SCSI_ESP.
>> With this the available SCSI HBAs can be configured for each
>> target configuration instead of compiling it in for everyone.
> 
> No. These are both PCI devices, I see no particularly good reason to make 
> them 
> optional. At minimum they should be enabled by default on all configs.
> 
> The ESP controller is different because it is't a general purpose device, and 
> only makes sense on certain systems.

RH needs to compile out as much as they can from the code base, because they 
state that they support everything that's compiled in. So making as much as 
possible optional is good. And I don't see why we should limit ourselves here.

Alex

Re: [Qemu-devel] [PATCH 08/12] ahci: add ahci emulation

> > less than half of the targets are big-endian. If it's broken on
> > big-endian there should be a comment somewhere documenting this, so we
> > know to fix it.
> 
> Well, it's stated in the cover letter and the same is true for almost every
> PCI device in qemu we have today. So what would you prefer? Add the device
> in every default config? Have a pci combination .mak that we can include
> on all pci capable machines so we don't end up patching 50 files for every
> device?

Yes, something like that.

Paul

Re: [Qemu-devel] [PATCH 08/12] ahci: add ahci emulation

On 25.11.2010, at 13:45, Paul Brook wrote:

>> On 25.11.2010, at 13:28, Paul Brook wrote:
 Makefile.objs  |1 +
 default-configs/i386-softmmu.mak   |1 +
 default-configs/x86_64-softmmu.mak |1 +
>>> 
>>> Why are you only enabling this on x86?  PCI devices, especially things
>>> like SATA controllers, should be completely target independent.
>> 
>> Because without the mmio series it breaks on big endian devices and we have
>> to start somewhere :).
> 
> less than half of the targets are big-endian. If it's broken on big-endian 
> there should be a comment somewhere documenting this, so we know to fix it.

Well, it's stated in the cover letter and the same is true for almost every PCI 
device in qemu we have today.
So what would you prefer? Add the device in every default config? Have a pci 
combination .mak that we can include on all pci capable machines so we don't 
end up patching 50 files for every device?

Alex

Re: [Qemu-devel] [PATCH 08/12] ahci: add ahci emulation

> On 25.11.2010, at 13:28, Paul Brook wrote:
> >> Makefile.objs  |1 +
> >> default-configs/i386-softmmu.mak   |1 +
> >> default-configs/x86_64-softmmu.mak |1 +
> > 
> > Why are you only enabling this on x86?  PCI devices, especially things
> > like SATA controllers, should be completely target independent.
> 
> Because without the mmio series it breaks on big endian devices and we have
> to start somewhere :).

less than half of the targets are big-endian. If it's broken on big-endian 
there should be a comment somewhere documenting this, so we know to fix it.

Paul

Re: [Qemu-devel] [PATCH 08/12] ahci: add ahci emulation

On 25.11.2010, at 13:28, Paul Brook wrote:

>> Makefile.objs  |1 +
>> default-configs/i386-softmmu.mak   |1 +
>> default-configs/x86_64-softmmu.mak |1 +
> 
> 
> Why are you only enabling this on x86?  PCI devices, especially things like 
> SATA controllers, should be completely target independent.

Because without the mmio series it breaks on big endian devices and we have to 
start somewhere :).

Alex

Re: [Qemu-devel] [PATCH 08/12] ahci: add ahci emulation

>  Makefile.objs  |1 +
>  default-configs/i386-softmmu.mak   |1 +
>  default-configs/x86_64-softmmu.mak |1 +


Why are you only enabling this on x86?  PCI devices, especially things like 
SATA controllers, should be completely target independent.

Paul

[Qemu-devel] Re: [PATCH 00/15] [RFC] MMIO endianness cleanup

> The way mmio endianness is currently implemented is horrifying.

Agreed.

> #ifdef TARGET_WORDS_BIGENDIAN
> val = bswap32(val);
> #endif
> 
> With the move to get device code only compiled once, this has
> become harder and harder to justify though, since we don't know
> the target endianness during compile time.

Not just that, it's wrong to start with.  I've used machines with both native 
and cross-endian 16550 based UARTs.
 
> So my solution to the issue is to make every device define if
> it's a little, big or native (target) endianness device. This
> basically tells the layers below what endianness the device
> expects mmio to occur in. Little endian devices on little endian
> hosts don't swap. On big endian hosts they do. Same the other
> way around.
> 
> The only reason I added "native" endianness is that we have some
> PV devices like the fw_cfg that expect qemu's broken behavior.
> These devices are the minority though. In the long run I'd expect
> to see most code be committed with either of the two endianness
> choices.

I'd prefer to avoid this, or at least document it as a temporary hack that 
should be removed.  If a device can exist in either endian, then we really 
want to push this decision down to the board-level code.

One of the reasons I haven't bothered fixing this yet is that this feels like 
something that should be a device/bus property.  e.g. PCI devices/busses are 
always little-endian[1], as as mentioned above some devices come in both 
flavors.  I guess we can go with your approach for now, and make sure we fix 
this properly when we introduce bus-specific registration functions.

Paul

[1] Ignoring magical byteswapping cpu-pci bridges, but they're broken by 
design, and thankfully quite rare.

[Qemu-devel] Re: [Patch] Small fix for qemu APIC for Mac OS X support

2010-11-25 Thread Jan Kiszka

Am 24.11.2010 12:00, Alexander Graf wrote:
 According to to the Intel IA-32 Software Developers Manual Vol 3 page
 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.

 Signed-off-by: Andrew de Quincey 

 diff --git a/hw/apic.c b/hw/apic.c
 index 5f4a87c..20304e0 100644
 --- a/hw/apic.c
 +++ b/hw/apic.c
 @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
 target_phys_addr_t addr)
 val = s->id << 24;
 break;
 case 0x03: /* version */
 -val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
 +val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
>>>
>>> What exactly changed between the versions? Did new registers get introduced 
>>> or subtle behavior change? Is there some proper documentation on the 
>>> changed between the apic versions?
>>
>> I've been trying to find out; I'm still searching intel's docs to find
>> an 0x11 version to compare with :(
> 
> Please try very hard. I haven't found anything myself either yet, but without 
> a spec it's hard to justify these changes upstream :(.
> 
>> The failure mode is that mac os X SL whines about the APIC being an
>> unexpected version (0x11) and it wants 0x14 as a minimum.
> 
> Yup, I remember that issue. To really make this all useful, we also need to 
> change the numbers in KVM though.

Also, the version has to be set depending on the emulated CPU (even more
when there will be emulation differences).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: [RfC PATCH] spice: qmp windup: connection events & info command.


  Hi,


The first thing we have to check with Daniel is whether or not we're
providing the info they would need/expect,


Daniel?


apart from that I have the
following general comments:

  1. It's missing documentation in QMP/qmp-events.txt and qmp-commands.hx
 (yeah, docs are far from code, hope to fix soon)


Ok.


  2. Can you please split this in two patches? One adding the events and
 the other adding the query command


Doesn't make that much sense IMHO as the both provide quite simliar 
informations (i.e. "info spice" gives you a list of connections with 
pretty much the same info provided by the events).



+/*
+ * generic print handler for hmp 'info $what'
+ * simply pretty-print the josn representation
+ */
+#if defined(CONFIG_SPICE) /* because 'info spice' is the only user */
+static void do_info_generic_print(Monitor *mon, const QObject *data)
+{
+QString *json = qobject_to_json_pretty(data);
+monitor_printf(mon, "%s\n", qstring_get_str(json));
+QDECREF(json);
+}
+#endif


We definitely need a generic print handler, but I don't that stringifying
JSON makes a minimal good user interface.


Well, this is the pretty json version which prints stuff multi-line and 
with intention.  Certainly not perfect but reasonable readable with 
minimum effort.  We can replace it with something else when it shows up.



+static QList *channel_list_get(void)
+{
+ChannelList *item;
+QList *list;
+QDict *dict;
+
+list = qlist_new();
+QTAILQ_FOREACH(item,&channel_list, link) {
+dict = qdict_new();
+add_addr_info(dict,&item->info->paddr, item->info->plen);
+add_channel_info(dict, item->info);
+qlist_append_obj(list, QOBJECT(dict));


You can use qlist_append() and drop the QOBJECT() usage.



Ok.

cheers,
  Gerd

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

2010-11-25 Thread Isaku Yamahata

On Wed, Nov 24, 2010 at 02:08:16PM +, adq wrote:
> > Interesting. I was also thinking that maybe we can leverage overriding 
> > mechanisms that are already available. Maybe it's possible to squeeze the 
> > HPET node into an SSDT. Maybe we need to override the whole DSDT from the 
> > command line.
> 
> We'll definitely need to override the DSDT for the applesmc device. I
> was thinking something along the lines of an additional DSDT binary
> supplied with QEMU for use when emulating apple hardware as you
> suggest.

The patches for qemu and seabios have been floating around.
I wrote them for Q35 chipset support, but no one has gotten interested in it.
But now, you are there. I'm willing to rebase/resend them.
-- 
yamahata

Re: [Qemu-devel] [PATCH] Make SCSI HBA configurable

> This patch introduces configuration variables
> CONFIG_SCSI_LSI
> CONFIG_SCSI_MEGASAS
> and renames the existing CONFIG_ESP to CONFIG_SCSI_ESP.
> With this the available SCSI HBAs can be configured for each
> target configuration instead of compiling it in for everyone.

No. These are both PCI devices, I see no particularly good reason to make them 
optional. At minimum they should be enabled by default on all configs.

The ESP controller is different because it is't a general purpose device, and 
only makes sense on certain systems.

Paul

Re: [Qemu-devel] [PATCH 08/11] ahci: add ahci emulation

2010-11-25 Thread Isaku Yamahata

On Thu, Nov 25, 2010 at 08:07:39AM +0100, Alexander Graf wrote:
> +static int pci_ahci_init(PCIDevice *dev)
> +{
> +struct AHCIPCIState *d;
> +d = DO_UPCAST(struct AHCIPCIState, card, dev);
> +
> +pci_config_set_vendor_id(d->card.config, PCI_VENDOR_ID_INTEL);
> +pci_config_set_device_id(d->card.config,
> + PCI_DEVICE_ID_INTEL_ICH7_AHCI_RAID);
> +d->card.config[PCI_COMMAND] = PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
> +  PCI_COMMAND_MASTER;

command register is 16bit width. So please use pci_set_word().


> +pci_config_set_class(d->card.config, PCI_CLASS_STORAGE_SATA);
> +pci_config_set_prog_interface(d->card.config, AHCI_PROGMODE_MAJOR_REV_1);
> +
> +d->card.config[PCI_CACHE_LINE_SIZE] = 0x08;  /* Cache line size */
> +d->card.config[PCI_LATENCY_TIMER]   = 0x00;  /* Latency timer */
> +d->card.config[PCI_HEADER_TYPE] = PCI_HEADER_TYPE_NORMAL;

Please don't overwrite multifunction bit. Just drop this line, then
pci generic layer will take care of it.


> +pci_config_set_interrupt_pin(d->card.config, 1);
> +
> +qemu_register_reset(ahci_reset, d);
> +
> +/* XXX BAR size should be 1k, but that breaks, so bump it to 4k for now 
> */
> +pci_register_bar(&d->card, 5, 0x1000, PCI_BASE_ADDRESS_SPACE_MEMORY,
> + ahci_pci_map);
> +
> +msi_init(dev, 0x50, 1, true, false);
> +
> +ahci_init(&d->ahci, &dev->qdev);
> +d->ahci.irq = d->card.irq[0];
> +
> +return 0;
> +}

-- 
yamahata

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum

Wolfgang,

On 25.11.2010, at 11:30, wolfgang mueller wrote:

> Dear Alexander Graf,
> thank you for contacting me. 
> I hope that I am right when I understand your below email as a complaint that 
> we have not contacted you before organizing 
> this event.

The complaint is mostly that you have not approached the community, yes :).

> First of all, we understand our event not as an official QEMU event nor have 
> we stated this anywhere or that that we are the 
> owners of QEMU.
> 
> Let me explain about the background of the Workshop.
> We as QEMU users, occasionally meet other QEMU users at conferences and we 
> observed that the number was significantly growing
> during the last years (thanks to the excellent work of the developers). We 
> googled for any contacts to other QEMU users and 
> did neither found any workshop nor any mailing list or anything similar we 
> could contact. The only thing we found as a main contact 
> was Fabrice  Bellard and a huge set of developers (~3000). We saw Fabrice 
> Bellard as the "owner" and contacted him. Unfortunately 
> he rejected as he has no longer interest in QEMU. 

I guess we should really remove most traces of Fabrice if he isn't even helpful 
enough to direct you to the mailing list. The maintainer situation should be 
explained in the MAINTAINERS file in the qemu source tree. Apparently the last 
attempt to redo that file and make it contain actual current information 
failed. Sigh.

There is a group of people with commit rights to the source tree. Each of them 
have special and in general different fields of interest. There are also 
several submaintainers who keep track of subsystems, but don't have commit 
rights and route everything through the few people with commit rights.

In general, it's similar to the Linux kernel, but with a schizophrenic Linus.

So the "right thing" to do would have been to send a mail to the qemu-devel 
mailing list, asking for feedback. The right people definitely do read the list.

> As we did not find any current "leader" or dedicated leading group beyond the 
> web site, we decided to move on since we were interested
> to get the QEMU users together to join efforts and exchange ideas and 
> developments (The alternative would have been to contact
> all over 3000 QEMU developers and to discuss with them the organization of 
> such a event. However, from the first idea to the
> possibility to get it accepted in the framework of the DATE conference were 
> very few weeks so that we did not see it as a viable
> alternative).
> 
> I now understand that we obviously missed your role in that community as the 
> leader or one of the leaders and qemu-devel@nongnu.org
> as the community or part of the community. Therefore, we apologize that we 
> did not contact you or qemu-de...@nongnu.org.

Don't worry about me. I feel myself in general rather representing minorities 
in qemu. The closest to a "leader" position in qemu these days is probably 
Anthony Liguori. CC'ing him.

> 
> However, currently though already very late, we could offer you that you can 
> join and and we can list you as a third organizer.
> But you have to make an immediate decision as the DATE program will go to 
> print in about 10 days. Otherwise you will be only
> listed on the web.
> 
> Additionally, we are still looking for a person who is giving a general 
> 45-minute QEMU tutorial/overview. As we were enforce by the
> hosting DATE conference to put a name there, please just take it as a 
> placeholder for the worst case that we do not find anybody else.
> Are you interested or anybody from qemu-de...@nongnu.org? 

This is exactly the reason I approached you sceptic on the whole thing. Qemu is 
_very_ diverse. It ranges from prototyping non-existing hardware over 
user-space only emulation to virtualization. Each of the different aspects have 
their very own issues and traction. The group that's the most active currently 
is the virtualization crowd. Which target audience are you going for?

> 
> Finally, I actually do not share your concerns that people register to get 
> more information "about command line switches to virtualize 
> on x86 hardware". I really would expect that people read the programme before 
> they register. However, maybe you know the community 
> better than I do.

After checking on the pricing for previous years I agree with you :).

> 
> For the future, we are currently not planning a second Users' Forum and we 
> are open to forward the organization of a second workshop
> to anybody else.
> 
> Why don't you simply take this event as a first trigger to organize an QEMU 
> conference for Developers and users.
> We can help you by forwarding the email addresses of some of the people. I 
> can also help you if you want.
> This can be the start of a real great effort with huge benefit to the 
> community.

As stated above, things are more difficult than that, but I agree. We do have 
annual KVM Forum meetings where we gather all the v

Re: [Qemu-devel] [PATCH 00/15] [RFC] MMIO endianness cleanup

2010-11-25 Thread Gleb Natapov

On Thu, Nov 25, 2010 at 11:18:26AM +0100, Gerd Hoffmann wrote:
> On 11/25/10 08:35, Alexander Graf wrote:
> >The way mmio endianness is currently implemented is horrifying.
> >
> >In the real world, CPUs have an endianness and write out data
> >to the memory bus. Instead of RAM, a receiving side here can be
> >a device. This device gets a byte stream again and needs to
> >make sense of it.
> >
> >Since big endian systems write big endian numbers into memory
> >while little endian systems write little endian numbers there,
> >the device and software on the CPU need to be aware of this.
> >
> >In practice, most devices these days (ISA, PCI) assume that
> >the data is little endian. So to communicate with such a device
> >from the CPU's side, the OS byte swaps all MMIO.
> >
> >In qemu however, we simply pass the register value we find on
> >to the device. So any byte mangling the guest does to compensate
> >for the transfer screw us up by exposing byte swapped MMIO
> >on the device's side.
> >
> >The way this has been fixed historically is by constructs like
> >this one:
> >
> >#ifdef TARGET_WORDS_BIGENDIAN
> > val = bswap32(val);
> >#endif
> >
> >With the move to get device code only compiled once, this has
> >become harder and harder to justify though, since we don't know
> >the target endianness during compile time.
> >
> >It's especially bad since it doesn't make any sense at all to
> >clutter all the device code with endianness workarounds, aside
> >from the fact that about 80% of the device code currently does
> >the wrong thing :).
> >
> >So my solution to the issue is to make every device define if
> >it's a little, big or native (target) endianness device. This
> >basically tells the layers below what endianness the device
> >expects mmio to occur in. Little endian devices on little endian
> >hosts don't swap. On big endian hosts they do. Same the other
> >way around.
> >
> >The only reason I added "native" endianness is that we have some
> >PV devices like the fw_cfg that expect qemu's broken behavior.
> >These devices are the minority though. In the long run I'd expect
> >to see most code be committed with either of the two endianness
> >choices.
> >
> >The patch set also includes a bunch of conversions for devices
> >that were already aware of endianness.
> >
> >This is an RFC, so please comment as much as you can :).
> 
> Seen 
> http://git.qemu.org/qemu.git/commit/?id=acd1c812b5548c8426e093075362b6d4119db6ac
> ?
> 
> I think it make sense to either extend it so it works for mmio too
> (and add the endian awareness along the way) or create something
> simliar for mmio.
> 
FWTW when I asked why addr and data in IORange are 64bit I was told that it
is intended for use with MMIO too.

--
Gleb.

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum

2010-11-25 Thread wolfgang mueller


Dear Alexander Graf,
thank you for contacting me.
I hope that I am right when I understand your below email as a complaint 
that we have not contacted you before organizing

this event.

First of all, we understand our event not as an official QEMU event nor 
have we stated this anywhere or that that we are the

owners of QEMU.

Let me explain about the background of the Workshop.
We as QEMU users, occasionally meet other QEMU users at conferences and 
we observed that the number was significantly growing
during the last years (thanks to the excellent work of the developers). 
We googled for any contacts to other QEMU users and
did neither found any workshop nor any mailing list or anything similar 
we could contact. The only thing we found as a main contact
was Fabrice  Bellard and a huge set of developers (~3000). We saw 
Fabrice Bellard as the "owner" and contacted him. Unfortunately

he rejected as he has no longer interest in QEMU.

As we did not find any current "leader" or dedicated leading group 
beyond the web site, we decided to move on since we were interested
to get the QEMU users together to join efforts and exchange ideas and 
developments (The alternative would have been to contact
all over 3000 QEMU developers and to discuss with them the organization 
of such a event. However, from the first idea to the
possibility to get it accepted in the framework of the DATE conference 
were very few weeks so that we did not see it as a viable

alternative).

I now understand that we obviously missed your role in that community as 
the leader or one of the leaders and qemu-devel@nongnu.org
as the community or part of the community. Therefore, we apologize that 
we did not contact you or qemu-de...@nongnu.org.


However, currently though already very late, we could offer you that you 
can join and and we can list you as a third organizer.
But you have to make an immediate decision as the DATE program will go 
to print in about 10 days. Otherwise you will be only

listed on the web.

Additionally, we are still looking for a person who is giving a general 
45-minute QEMU tutorial/overview. As we were enforce by the
hosting DATE conference to put a name there, please just take it as a 
placeholder for the worst case that we do not find anybody else.

Are you interested or anybody from qemu-de...@nongnu.org?

Finally, I actually do not share your concerns that people register to 
get more information "about command line switches to virtualize
on x86 hardware". I really would expect that people read the programme 
before they register. However, maybe you know the community

better than I do.

For the future, we are currently not planning a second Users' Forum and 
we are open to forward the organization of a second workshop

to anybody else.

Why don't you simply take this event as a first trigger to organize an 
QEMU conference for Developers and users.
We can help you by forwarding the email addresses of some of the people. 
I can also help you if you want.
This can be the start of a real great effort with huge benefit to the 
community.


w.

On 23.11.2010 12:25, Alexander Graf wrote:


On 19.10.2010, at 15:42, Wolfgang Mueller wrote:


*
   Call for Presentations
  1st International QEMU Users Forum

  March 18th, 2011, Grenoble, France
*

Deadlines:
Extended abstract Nov 28th, 2010
Notification of acceptanceNov 30th, 2010


While I appreciate your efforts to organize this event, I would have 
preferred to see some coordination with the Qemu community before 
simply announcing an "official" Qemu event.


From what I gathered on your preliminary schedule 
(http://www.date-conference.com/date11-workshop-W8), the main focus of 
this event is SystemC integration. I'm not sure this is what I would 
call a "Users Forum". It sounds more like a want-to-be developer 
meeting to discuss integration aspects of other projects with Qemu.


This too is a noble goal, but from the announcement you might end up 
getting real end-users come to this event and be very disappointed, 
because they would like to hear about command line switches to 
virtualize on x86 hardware.


So in general, I would really like to see you coordinate better with 
qemu-devel before announcing something that could potentially work out 
bad for Qemu's reputation, even if it's meant with good intentions.



Thank You,

Alex




--
-- wolfgang
___
Wolfgang Mueller  wolfg...@acm.org   adt.cs.upb.de/wolfgang
Paderborn University/C-LAB, Fuerstenallee 11,  33098 Paderborn, Germany
Phone:(++)49-5251.60.6134   Fax:(++)49-5251.60.6065
___
This message (plus attachments) is  confidential and may be  subject to
lawyer-client privilege. Use without  permi

Re: [Qemu-devel] [PATCH 00/15] [RFC] MMIO endianness cleanup


On 11/25/10 08:35, Alexander Graf wrote:

The way mmio endianness is currently implemented is horrifying.

In the real world, CPUs have an endianness and write out data
to the memory bus. Instead of RAM, a receiving side here can be
a device. This device gets a byte stream again and needs to
make sense of it.

Since big endian systems write big endian numbers into memory
while little endian systems write little endian numbers there,
the device and software on the CPU need to be aware of this.

In practice, most devices these days (ISA, PCI) assume that
the data is little endian. So to communicate with such a device
from the CPU's side, the OS byte swaps all MMIO.

In qemu however, we simply pass the register value we find on
to the device. So any byte mangling the guest does to compensate
for the transfer screw us up by exposing byte swapped MMIO
on the device's side.

The way this has been fixed historically is by constructs like
this one:

#ifdef TARGET_WORDS_BIGENDIAN
 val = bswap32(val);
#endif

With the move to get device code only compiled once, this has
become harder and harder to justify though, since we don't know
the target endianness during compile time.

It's especially bad since it doesn't make any sense at all to
clutter all the device code with endianness workarounds, aside
from the fact that about 80% of the device code currently does
the wrong thing :).

So my solution to the issue is to make every device define if
it's a little, big or native (target) endianness device. This
basically tells the layers below what endianness the device
expects mmio to occur in. Little endian devices on little endian
hosts don't swap. On big endian hosts they do. Same the other
way around.

The only reason I added "native" endianness is that we have some
PV devices like the fw_cfg that expect qemu's broken behavior.
These devices are the minority though. In the long run I'd expect
to see most code be committed with either of the two endianness
choices.

The patch set also includes a bunch of conversions for devices
that were already aware of endianness.

This is an RFC, so please comment as much as you can :).


Seen 
http://git.qemu.org/qemu.git/commit/?id=acd1c812b5548c8426e093075362b6d4119db6ac 
?


I think it make sense to either extend it so it works for mmio too (and 
add the endian awareness along the way) or create something simliar for 
mmio.


cheers,
  Gerd

Re: [Qemu-devel] [PATCH 00/15] [RFC] MMIO endianness cleanup


On 25.11.2010, at 11:18, Gerd Hoffmann wrote:

> On 11/25/10 08:35, Alexander Graf wrote:
>> The way mmio endianness is currently implemented is horrifying.
>> 
>> In the real world, CPUs have an endianness and write out data
>> to the memory bus. Instead of RAM, a receiving side here can be
>> a device. This device gets a byte stream again and needs to
>> make sense of it.
>> 
>> Since big endian systems write big endian numbers into memory
>> while little endian systems write little endian numbers there,
>> the device and software on the CPU need to be aware of this.
>> 
>> In practice, most devices these days (ISA, PCI) assume that
>> the data is little endian. So to communicate with such a device
>> from the CPU's side, the OS byte swaps all MMIO.
>> 
>> In qemu however, we simply pass the register value we find on
>> to the device. So any byte mangling the guest does to compensate
>> for the transfer screw us up by exposing byte swapped MMIO
>> on the device's side.
>> 
>> The way this has been fixed historically is by constructs like
>> this one:
>> 
>> #ifdef TARGET_WORDS_BIGENDIAN
>> val = bswap32(val);
>> #endif
>> 
>> With the move to get device code only compiled once, this has
>> become harder and harder to justify though, since we don't know
>> the target endianness during compile time.
>> 
>> It's especially bad since it doesn't make any sense at all to
>> clutter all the device code with endianness workarounds, aside
>> from the fact that about 80% of the device code currently does
>> the wrong thing :).
>> 
>> So my solution to the issue is to make every device define if
>> it's a little, big or native (target) endianness device. This
>> basically tells the layers below what endianness the device
>> expects mmio to occur in. Little endian devices on little endian
>> hosts don't swap. On big endian hosts they do. Same the other
>> way around.
>> 
>> The only reason I added "native" endianness is that we have some
>> PV devices like the fw_cfg that expect qemu's broken behavior.
>> These devices are the minority though. In the long run I'd expect
>> to see most code be committed with either of the two endianness
>> choices.
>> 
>> The patch set also includes a bunch of conversions for devices
>> that were already aware of endianness.
>> 
>> This is an RFC, so please comment as much as you can :).
> 
> Seen 
> http://git.qemu.org/qemu.git/commit/?id=acd1c812b5548c8426e093075362b6d4119db6ac
>  ?
> 
> I think it make sense to either extend it so it works for mmio too (and add 
> the endian awareness along the way) or create something simliar for mmio.

We only have a single opaque for mmio, so I don't see the value-add. There is a 
simple mmio version already in rwhandler.c btw.

http://git.qemu.org/qemu.git/commit/?id=049f7adbd547969ba013fed13c0a26c1f62a4a71


Alex

Re: [Qemu-devel] Re: [PATCH 0/5]

On Thu, Nov 25, 2010 at 2:30 AM, FUJITA Tomonori
 wrote:
> On Wed, 24 Nov 2010 13:38:59 +
> Stefan Hajnoczi  wrote:
>
>> > This series adds rebased support for the hw/scsi-bsg.c backstore for 
>> > scsi-bus
>> > compatible HBA emulation in QEMU-KVM on Linux hosts supporting the BSG 
>> > driver
>> > against current mainline qemu-kvm.git/master code.
>>
>> I don't know the Linux SCSI stack, so some basic questions for you :).
>>
>> With scsi-generic I can send SCSI commands to a device.  How is bsg
>> different?  The bsg code looks cleaner than sg but they both boil down
>> to issuing SCSI requests using the Linux block layer AFAICT.
>>
>> Can you explain what advantages this patch series brings over scsi-generic?
>
> The main reason why we invented bsg is that we need the common
> interface to send non SCSI commands. For example, we already use bsg
> for FC stuff:
>
> http://lwn.net/Articles/326338/
>
> We can use the common interface rather than each HW specific interface.
>
> From the perspective of SCSI, the major advantage of bsg is supporting
> bidi commands. I'm not sure qemu will ever need bidi pass through
> support though.

Thanks for the explanations Christoph and Tomonori.

Stefan

[Qemu-devel] Re: [RFC][PATCH v3 00/11] virtagent: host/guest RPC communication agent

Hi,

On (Wed) Nov 10 2010 [19:37:19], Michael Roth wrote:
> EXAMPLE USAGE:
> 
> The commandline options are a little convoluted right now; this will 
> addressed in later revisions.
> 
>  - Configure guest agent to talk to host via virtio-serial
> # start guest with virtio-serial/virtproxy/virtagent. for example 
> (RHEL6rc1):
> qemu \
> -chardev virtproxy,id=test0,virtagent=on \
> -device virtio-serial \
> -device virtserialport,chardev=test0,name=virtagent0 \
> -monitor stdio
> ...
> # in the guest:
> ./qemu-vp -c virtserial-open:/dev/virtio-ports/virtagent0:- -g
> ...
> # monitor commands
> (qemu) agent_viewdmesg
> [139311.710326] wlan0: deauthenticating from 00:30:bd:f7:12:d5 by local 
> choice (reason=3)
> [139323.469857] wlan0: deauthenticating from 00:21:29:cd:41:ee by local 
> choice (reason=3)
> ...
> [257683.375646] wlan0: authenticated
> [257683.375684] wlan0: associate with AP 00:30:bd:f7:12:d5 (try 1)
> [257683.377932] wlan0: RX AssocResp from 00:30:bd:f7:12:d5 (capab=0x411 
> status=0 aid=4)
> [257683.377940] wlan0: associated
> 
> (qemu) agent_viewfile /proc/meminfo

It would be better to have a command and sub-commands rather than
different commands for viewing different kinds of files:

(qemu) agent view dmesg
(qemu) agent view /proc/meminfo

Amit

Re: [Qemu-devel] [PATCH 1/1] iscsi: add iSCSI block device support

2010-11-25 Thread Kevin Wolf

Am 25.11.2010 06:22, schrieb ronnie sahlberg:
> Nicholas,
> below.
> 
> On Thu, Nov 25, 2010 at 3:32 PM, Nicholas A. Bellinger
>  wrote:
> 
>> But existing code aside, I think having a small userspace iSCSI
>> initiator built into QEMU that 'just works' across all host environments
>> would be a pretty useful thing, even if the scalibility / scope is
>> limited compared to existing kernel host level iSCSI initiator stacks,
>> et al.  I have not yet had a chance to look at Ronnie's code, but would
>> be interested to understand how the threading model currently functions.
>>
>> Ronnie, I would recommending following Kevin's earlier advice and split
>> your work into a reviewable series of commits (preferrably generated by
>> git-format-patch) and repost the series for feedback to qemu-devel.  You
>> can read that as coded language for 'you will want to learn git to
>> submit your patch', but it really does work.  ;)
> 
> Thanks,
> 
> I will work on the suggestions over the weekend, so Ill resend either
> this weekend or next weekend.
> So don't spend/waste time reviewing now.
> 
> As for the threading model.
> Currently it is not threads safe, so all calls into the library would
> have to be protected through a mutex if used from concurrent threads.
> I couldn't see any such mutexes when looking at sheepdog as an
> example, so do the block drivers need to be threads-safe in qemu?

No, block drivers are not threaded currently. You don't have to take
care of that yourself, everything is already protected by a mutex.

> One goal of the library is to be 100% async and to never make any
> blocking syscalls.
> So the library will never block and should be able to reach good
> performance, even with one single thread.

That would match what other block drivers do.

Kevin

Re: [Qemu-devel] Re: [PATCH] scsi-generic: bugfixes for 'SCSIRequest' conversion


Right now, I've somewhat come up with:

   - client request occurs
   - call device send_command()
   - if result is 0, assume my complete() was called with
 SCSI_REASON_DONE
   - else, use sign of result for transfer direction, store the
 absolute value as the total expected transfer len and call
 the device scsi_data_read()/write() and wait for complete()
   - when complete() is called:
 - if SCSI_REASON_DONE, complete client request
 - else perform the client "DMA" for "arg" bytes
 - call the device scsi_data_read()/write() again


No, this is exactly as I'm expecting the SCSI layer to work.


Yes.


So from the light of this the patch to scsi-generic is valid.


Yes.


And it really looks like papering over a bug in the lsi HBA code.


Indeed.  If the patch breaks lsi I'd agree that it is lsi's fault. 
Anyone tested whenever current upstream lsi actually breaks with the 
patch applied?


I've attempted to convert lsi to use iovecs a while ago, and *that* 
version definitively had problems with short transfers, so maybe this is 
a leftover from those days where scsi hacking was based on that branch ...


cheers,
  Gerd

Re: [Qemu-devel] Re: [PATCH] scsi-generic: bugfixes for 'SCSIRequest' conversion

2010-11-25 Thread Benjamin Herrenschmidt

On Thu, 2010-11-25 at 10:06 +0100, Hannes Reinecke wrote:
> No, this is exactly as I'm expecting the SCSI layer to work.
> So from the light of this the patch to scsi-generic is valid.
> And it really looks like papering over a bug in the lsi HBA code.

Ok. I have no special case tho for a complete() coming for data with 0
in arg. I will just skip the DMA part and call read/write again until I
get SCSI_REASON_DONE.

Cheers,
Ben.

Re: [Qemu-devel] Re: [PATCH] scsi-generic: bugfixes for 'SCSIRequest' conversion

On 11/25/2010 10:01 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-11-25 at 09:50 +0100, Gerd Hoffmann wrote:
>> On 11/25/10 09:46, Benjamin Herrenschmidt wrote:
>>
>>> So far tho, it appears that I can (at least with scsi-disk) rely on
>>> always been eventually called with SCSI_REASON_DONE so my code (and
>>> maybe the usb-msd code too, I haven't verified) relies on that to
>>> complete requests... Is that incorrect ?
>>
>> Yes.
> 
> Well, so far it works :-) But I suppose I must be lucky.. I must admit
> that it's very unclear how that SCSI "stack" is meant to be used from
> the HBA standpoint.
> 
> Right now, I've somewhat come up with:
> 
>   - client request occurs
>   - call device send_command()
>   - if result is 0, assume my complete() was called with 
> SCSI_REASON_DONE
>   - else, use sign of result for transfer direction, store the
> absolute value as the total expected transfer len and call
> the device scsi_data_read()/write() and wait for complete()
>   - when complete() is called:
> - if SCSI_REASON_DONE, complete client request
> - else perform the client "DMA" for "arg" bytes
> - call the device scsi_data_read()/write() again
> 
No, this is exactly as I'm expecting the SCSI layer to work.
So from the light of this the patch to scsi-generic is valid.
And it really looks like papering over a bug in the lsi HBA code.

Gerd?

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] scsi-generic: bugfixes for 'SCSIRequest' conversion

2010-11-25 Thread Benjamin Herrenschmidt

On Thu, 2010-11-25 at 09:50 +0100, Gerd Hoffmann wrote:
> On 11/25/10 09:46, Benjamin Herrenschmidt wrote:
> 
> > So far tho, it appears that I can (at least with scsi-disk) rely on
> > always been eventually called with SCSI_REASON_DONE so my code (and
> > maybe the usb-msd code too, I haven't verified) relies on that to
> > complete requests... Is that incorrect ?
> 
> Yes.

Well, so far it works :-) But I suppose I must be lucky.. I must admit
that it's very unclear how that SCSI "stack" is meant to be used from
the HBA standpoint.

Right now, I've somewhat come up with:

  - client request occurs
  - call device send_command()
  - if result is 0, assume my complete() was called with 
SCSI_REASON_DONE
  - else, use sign of result for transfer direction, store the
absolute value as the total expected transfer len and call
the device scsi_data_read()/write() and wait for complete()
  - when complete() is called:
- if SCSI_REASON_DONE, complete client request
- else perform the client "DMA" for "arg" bytes
- call the device scsi_data_read()/write() again

So far it seems to work with scsi-disk but maybe I miss something in
which case I would very much enjoy being corrected :-)

Cheers,
Ben.

[Qemu-devel] [PATCH 10/15] ppc4xx_pci: Declare as little endian

This patch replaces explicit bswaps with endianness hints to the
mmio layer.

Signed-off-by: Alexander Graf 
---
 hw/ppc4xx_pci.c |   17 ++---
 1 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/hw/ppc4xx_pci.c b/hw/ppc4xx_pci.c
index f2ecece..f62f1f9 100644
--- a/hw/ppc4xx_pci.c
+++ b/hw/ppc4xx_pci.c
@@ -24,7 +24,6 @@
 #include "ppc4xx.h"
 #include "pci.h"
 #include "pci_host.h"
-#include "bswap.h"
 
 #undef DEBUG
 #ifdef DEBUG
@@ -102,10 +101,6 @@ static void pci4xx_cfgaddr_writel(void *opaque, 
target_phys_addr_t addr,
 {
 PPC4xxPCIState *ppc4xx_pci = opaque;
 
-#ifdef TARGET_WORDS_BIGENDIAN
-value = bswap32(value);
-#endif
-
 ppc4xx_pci->pci_state.config_reg = value & ~0x3;
 }
 
@@ -120,10 +115,6 @@ static void ppc4xx_pci_reg_write4(void *opaque, 
target_phys_addr_t offset,
 {
 struct PPC4xxPCIState *pci = opaque;
 
-#ifdef TARGET_WORDS_BIGENDIAN
-value = bswap32(value);
-#endif
-
 /* We ignore all target attempts at PCI configuration, effectively
  * assuming a bidirectional 1:1 mapping of PLB and PCI space. */
 
@@ -251,10 +242,6 @@ static uint32_t ppc4xx_pci_reg_read4(void *opaque, 
target_phys_addr_t offset)
 value = 0;
 }
 
-#ifdef TARGET_WORDS_BIGENDIAN
-value = bswap32(value);
-#endif
-
 return value;
 }
 
@@ -373,7 +360,7 @@ PCIBus *ppc4xx_pci_init(CPUState *env, qemu_irq pci_irqs[4],
 /* CFGADDR */
 index = cpu_register_io_memory(pci4xx_cfgaddr_read,
pci4xx_cfgaddr_write, controller,
-   DEVICE_NATIVE_ENDIAN);
+   DEVICE_LITTLE_ENDIAN);
 if (index < 0)
 goto free;
 cpu_register_physical_memory(config_space + PCIC0_CFGADDR, 4, index);
@@ -386,7 +373,7 @@ PCIBus *ppc4xx_pci_init(CPUState *env, qemu_irq pci_irqs[4],
 
 /* Internal registers */
 index = cpu_register_io_memory(pci_reg_read, pci_reg_write, controller,
-   DEVICE_NATIVE_ENDIAN);
+   DEVICE_LITTLE_ENDIAN);
 if (index < 0)
 goto free;
 cpu_register_physical_memory(registers, PCI_REG_SIZE, index);
-- 
1.6.0.2

[Qemu-devel] [PATCH 01/15] exec: introduce endianness swapped mmio

The way we're currently modeling mmio is too simplified. We assume that
every device has the same endianness as the target CPU. In reality,
most devices are little endian (all PCI and ISA ones I'm aware of). Some
are big endian (special system devices) and a very little fraction is
target native endian (fw_cfg).

So instead of assuming every device to be native endianness, let's move
to a model where the device tells us which endianness it's in.

That way we can compile the devices only once and get rid of all the ugly
swap will be done by the underlying layer.

For the same of readability, this patch only introduces the helper framework
but doesn't allow the registering code to set its endianness yet.

Signed-off-by: Alexander Graf 
---
 cpu-common.h |4 ++
 exec.c   |  122 ++
 2 files changed, 126 insertions(+), 0 deletions(-)

diff --git a/cpu-common.h b/cpu-common.h
index a543b5d..839b236 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -20,6 +20,10 @@
 
 #if !defined(CONFIG_USER_ONLY)
 
+#define DEVICE_NATIVE_ENDIAN  0
+#define DEVICE_BIG_ENDIAN 1
+#define DEVICE_LITTLE_ENDIAN  2
+
 /* address in the RAM (different from a physical address) */
 typedef unsigned long ram_addr_t;
 
diff --git a/exec.c b/exec.c
index db9ff55..f54a360 100644
--- a/exec.c
+++ b/exec.c
@@ -3336,6 +3336,109 @@ static int get_free_io_mem_idx(void)
 return -1;
 }
 
+/*
+ * Usually, devices operate in little endian mode. There are devices out
+ * there that operate in big endian too. Each device gets byte swapped
+ * mmio if plugged onto a CPU that does the other endianness.
+ *
+ * CPU  Device   swap?
+ *
+ * little   little   no
+ * little   big  yes
+ * big  little   yes
+ * big  big  no
+ */
+#ifdef TARGET_WORDS_BIGENDIAN
+
+typedef struct SwapEndianContainer {
+CPUReadMemoryFunc *read[3];
+CPUWriteMemoryFunc *write[3];
+void *opaque;
+} SwapEndianContainer;
+
+static uint32_t swapendian_mem_readb (void *opaque, target_phys_addr_t addr)
+{
+uint32_t val;
+SwapEndianContainer *c = opaque;
+val = c->read[0](c->opaque, addr);
+return val;
+}
+
+static uint32_t swapendian_mem_readw(void *opaque, target_phys_addr_t addr)
+{
+uint32_t val;
+SwapEndianContainer *c = opaque;
+val = bswap16(c->read[1](c->opaque, addr));
+return val;
+}
+
+static uint32_t swapendian_mem_readl(void *opaque, target_phys_addr_t addr)
+{
+uint32_t val;
+SwapEndianContainer *c = opaque;
+val = bswap32(c->read[2](c->opaque, addr));
+return val;
+}
+
+static CPUReadMemoryFunc * const swapendian_readfn[3]={
+swapendian_mem_readb,
+swapendian_mem_readw,
+swapendian_mem_readl
+};
+
+static void swapendian_mem_writeb(void *opaque, target_phys_addr_t addr,
+  uint32_t val)
+{
+SwapEndianContainer *c = opaque;
+c->write[0](c->opaque, addr, val);
+}
+
+static void swapendian_mem_writew(void *opaque, target_phys_addr_t addr,
+  uint32_t val)
+{
+SwapEndianContainer *c = opaque;
+c->write[1](c->opaque, addr, bswap16(val));
+}
+
+static void swapendian_mem_writel(void *opaque, target_phys_addr_t addr,
+  uint32_t val)
+{
+SwapEndianContainer *c = opaque;
+c->write[2](c->opaque, addr, bswap32(val));
+}
+
+static CPUWriteMemoryFunc * const swapendian_writefn[3]={
+swapendian_mem_writeb,
+swapendian_mem_writew,
+swapendian_mem_writel
+};
+
+static void swapendian_init(int io_index)
+{
+SwapEndianContainer *c = qemu_malloc(sizeof(SwapEndianContainer));
+int i;
+
+/* Swap mmio for big endian targets */
+c->opaque = io_mem_opaque[io_index];
+for (i = 0; i < 3; i++) {
+c->read[i] = io_mem_read[io_index][i];
+c->write[i] = io_mem_write[io_index][i];
+
+io_mem_read[io_index][i] = swapendian_readfn[i];
+io_mem_write[io_index][i] = swapendian_writefn[i];
+}
+io_mem_opaque[io_index] = c;
+}
+
+static void swapendian_del(int io_index)
+{
+if (io_mem_read[io_index][0] == swapendian_readfn[0]) {
+qemu_free(io_mem_opaque[io_index]);
+}
+}
+
+#endif
+
 /* mem_read and mem_write are arrays of functions containing the
function to access byte (index 0), word (index 1) and dword (index
2). Functions can be omitted with a NULL function pointer.
@@ -3349,6 +3452,7 @@ static int cpu_register_io_memory_fixed(int io_index,
 void *opaque)
 {
 int i;
+int endian = DEVICE_NATIVE_ENDIAN;
 
 if (io_index <= 0) {
 io_index = get_free_io_mem_idx();
@@ -3370,6 +3474,22 @@ static int cpu_register_io_memory_fixed(int io_index,
 }
 io_mem_opaque[io_index] = opaque;
 
+switch (endian) {
+case DEVICE_BIG_ENDIAN:
+#ifndef TARGET_WORDS_BIGENDIAN
+swapendian_init(io_index);
+#endif
+break;

Re: [Qemu-devel] [PATCH 13/15] scsi: Implement alloc_req_iov callback

On 11/24/2010 05:52 PM, Christoph Hellwig wrote:
> On Wed, Nov 24, 2010 at 12:16:08PM +0100, Hannes Reinecke wrote:
>> Add callback to create a request with a predefined iovec.
>> This is required for drivers which can use the iovec
>> of a command directly.
> 
> What happend to my comment that the iov and non-iov case should share
> code?  Also what happened to the other comment about not naming the
> method implementation different from the method name.
> 
Looked into it.
Sure I could be doing it for scsi-disk; for scsi-generic it won't
work, though. And it's not much of a code-share to have from it;
you'll end up with something like:

static SCSIRequest *scsi_new_request(SCSIDevice *d, uint32_t tag,
uint32_t lun)
{
struct iovec *iov;
uint8_t *buf;
SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, d);
SCSIRequest *req;
SCSIDiskReq *r;

buf = qemu_blockalign(s->bs, SCSI_DMA_BUF_SIZE);
iov = qemu_mallocz(sizeof(struct iovec));
iov[0].iov_base = buf;
req = scsi_new_request_iovec(d, tag, lun, iov, 1);
r = DO_UPCAST(SCSIDiskReq, req, req);
r->iov_buf = buf;
return req;
}

which doesn't look better than the original:

static SCSIRequest *scsi_new_request(SCSIDevice *d, uint32_t tag,
uint32_t lun)
{
SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, d);
SCSIRequest *req;
SCSIDiskReq *r;

req = scsi_req_alloc(sizeof(SCSIDiskReq), d, tag, lun);
r = DO_UPCAST(SCSIDiskReq, req, req);
r->iov_buf = qemu_blockalign(s->bs, SCSI_DMA_BUF_SIZE);
r->iov = qemu_mallocz(sizeof(struct iovec));
r->iov[0].iov_base = r->iov_buf;
r->iov_num = 1;
return req;
}

But I'm open to suggestions.

And for the naming:
The SCSI stack is using 'req' for every function accepting
SCSIRequest as an argument:

hw/scsi.h:
SCSIRequest *scsi_req_alloc(size_t size, SCSIDevice *d,
  uint32_t tag, uint32_t lun);
void scsi_req_free(SCSIRequest *req);

int scsi_req_parse(SCSIRequest *req, uint8_t *buf);
void scsi_req_print(SCSIRequest *req);
void scsi_req_complete(SCSIRequest *req);

So using 'alloc_req' and 'free_req' is in line with this naming
scheme. Using 'alloc_request' and 'free_request' really looked odd
in the light of the general usage.

Hence I didn't do it.
But again, I'm open to suggestions here.

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] scsi-generic: bugfixes for 'SCSIRequest' conversion


On 11/25/10 09:46, Benjamin Herrenschmidt wrote:


So far tho, it appears that I can (at least with scsi-disk) rely on
always been eventually called with SCSI_REASON_DONE so my code (and
maybe the usb-msd code too, I haven't verified) relies on that to
complete requests... Is that incorrect ?


Yes.

cheers,
  Gerd

Re: [Qemu-devel] Re: [PATCH] scsi-generic: bugfixes for 'SCSIRequest' conversion

2010-11-25 Thread Benjamin Herrenschmidt

On Wed, 2010-11-24 at 11:46 +0100, Hannes Reinecke wrote:
> >> - when a read is aborted due to a mark/EOF/EOD/EOM, the len
> reported to
> >> controller can be 0. LSI controller emulation doesn't know how to
> manage
> >> this. A workaround found is to call the completion routine with
> >> SCSI_REASON_DONE just after calling it with SCSI_REASON_DATA with
> len=0.
> > 
> > Are you sure that it's not needed any more?
> > 
> Don't ask me. I didn't do the patch, and my knowledge of lsi HBA
> internals is scanty.
> Nic, can you comment here? 

Well, writing an HBA myself, it took me a while to figure out what I'm
supposed to expect from the layer :-)

So far tho, it appears that I can (at least with scsi-disk) rely on
always been eventually called with SCSI_REASON_DONE so my code (and
maybe the usb-msd code too, I haven't verified) relies on that to
complete requests... Is that incorrect ?

Cheers,
Ben.

[Qemu-devel] [PATCH 08/15] prep: Declare as little endian

This patch replaces explicit bswaps with endianness hints to the
mmio layer.

Signed-off-by: Alexander Graf 
---
 hw/ppc_prep.c |   38 +++---
 1 files changed, 3 insertions(+), 35 deletions(-)

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 80f5db6..1492266 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -145,20 +145,12 @@ static uint32_t PPC_intack_readb (void *opaque, 
target_phys_addr_t addr)
 
 static uint32_t PPC_intack_readw (void *opaque, target_phys_addr_t addr)
 {
-#ifdef TARGET_WORDS_BIGENDIAN
-return bswap16(_PPC_intack_read(addr));
-#else
 return _PPC_intack_read(addr);
-#endif
 }
 
 static uint32_t PPC_intack_readl (void *opaque, target_phys_addr_t addr)
 {
-#ifdef TARGET_WORDS_BIGENDIAN
-return bswap32(_PPC_intack_read(addr));
-#else
 return _PPC_intack_read(addr);
-#endif
 }
 
 static CPUWriteMemoryFunc * const PPC_intack_write[] = {
@@ -210,9 +202,6 @@ static void PPC_XCSR_writeb (void *opaque,
 static void PPC_XCSR_writew (void *opaque,
  target_phys_addr_t addr, uint32_t value)
 {
-#ifdef TARGET_WORDS_BIGENDIAN
-value = bswap16(value);
-#endif
 printf("%s: 0x" TARGET_FMT_plx " => 0x%08" PRIx32 "\n", __func__, addr,
value);
 }
@@ -220,9 +209,6 @@ static void PPC_XCSR_writew (void *opaque,
 static void PPC_XCSR_writel (void *opaque,
  target_phys_addr_t addr, uint32_t value)
 {
-#ifdef TARGET_WORDS_BIGENDIAN
-value = bswap32(value);
-#endif
 printf("%s: 0x" TARGET_FMT_plx " => 0x%08" PRIx32 "\n", __func__, addr,
value);
 }
@@ -243,9 +229,6 @@ static uint32_t PPC_XCSR_readw (void *opaque, 
target_phys_addr_t addr)
 
 printf("%s: 0x" TARGET_FMT_plx " <= %08" PRIx32 "\n", __func__, addr,
retval);
-#ifdef TARGET_WORDS_BIGENDIAN
-retval = bswap16(retval);
-#endif
 
 return retval;
 }
@@ -256,9 +239,6 @@ static uint32_t PPC_XCSR_readl (void *opaque, 
target_phys_addr_t addr)
 
 printf("%s: 0x" TARGET_FMT_plx " <= %08" PRIx32 "\n", __func__, addr,
retval);
-#ifdef TARGET_WORDS_BIGENDIAN
-retval = bswap32(retval);
-#endif
 
 return retval;
 }
@@ -484,9 +464,6 @@ static void PPC_prep_io_writew (void *opaque, 
target_phys_addr_t addr,
 sysctrl_t *sysctrl = opaque;
 
 addr = prep_IO_address(sysctrl, addr);
-#ifdef TARGET_WORDS_BIGENDIAN
-value = bswap16(value);
-#endif
 PPC_IO_DPRINTF("0x" TARGET_FMT_plx " => 0x%08" PRIx32 "\n", addr, value);
 cpu_outw(addr, value);
 }
@@ -498,9 +475,6 @@ static uint32_t PPC_prep_io_readw (void *opaque, 
target_phys_addr_t addr)
 
 addr = prep_IO_address(sysctrl, addr);
 ret = cpu_inw(addr);
-#ifdef TARGET_WORDS_BIGENDIAN
-ret = bswap16(ret);
-#endif
 PPC_IO_DPRINTF("0x" TARGET_FMT_plx " <= 0x%08" PRIx32 "\n", addr, ret);
 
 return ret;
@@ -512,9 +486,6 @@ static void PPC_prep_io_writel (void *opaque, 
target_phys_addr_t addr,
 sysctrl_t *sysctrl = opaque;
 
 addr = prep_IO_address(sysctrl, addr);
-#ifdef TARGET_WORDS_BIGENDIAN
-value = bswap32(value);
-#endif
 PPC_IO_DPRINTF("0x" TARGET_FMT_plx " => 0x%08" PRIx32 "\n", addr, value);
 cpu_outl(addr, value);
 }
@@ -526,9 +497,6 @@ static uint32_t PPC_prep_io_readl (void *opaque, 
target_phys_addr_t addr)
 
 addr = prep_IO_address(sysctrl, addr);
 ret = cpu_inl(addr);
-#ifdef TARGET_WORDS_BIGENDIAN
-ret = bswap32(ret);
-#endif
 PPC_IO_DPRINTF("0x" TARGET_FMT_plx " <= 0x%08" PRIx32 "\n", addr, ret);
 
 return ret;
@@ -691,7 +659,7 @@ static void ppc_prep_init (ram_addr_t ram_size,
 /* Register 8 MB of ISA IO space (needed for non-contiguous map) */
 PPC_io_memory = cpu_register_io_memory(PPC_prep_io_read,
PPC_prep_io_write, sysctrl,
-   DEVICE_NATIVE_ENDIAN);
+   DEVICE_LITTLE_ENDIAN);
 cpu_register_physical_memory(0x8000, 0x0080, PPC_io_memory);
 
 /* init basic PC hardware */
@@ -757,12 +725,12 @@ static void ppc_prep_init (ram_addr_t ram_size,
 /* PCI intack location */
 PPC_io_memory = cpu_register_io_memory(PPC_intack_read,
PPC_intack_write, NULL,
-   DEVICE_NATIVE_ENDIAN);
+   DEVICE_LITTLE_ENDIAN);
 cpu_register_physical_memory(0xBFF0, 0x4, PPC_io_memory);
 /* PowerPC control and status register group */
 #if 0
 PPC_io_memory = cpu_register_io_memory(PPC_XCSR_read, PPC_XCSR_write,
-   NULL, DEVICE_NATIVE_ENDIAN);
+   NULL, DEVICE_LITTLE_ENDIAN);
 cpu_register_physical_memory(0xFEFF, 0x1000, PPC_io_memory);
 #endif
 
-- 
1.6.0.2

[Qemu-devel] [PATCH 15/15] usb_ohci: Always use little endian

This patch replaces explicit bswaps with endianness hints to the
mmio layer.

Because we don't depend on the target endianness anymore, we can also
move the driver over to Makefile.objs.

Signed-off-by: Alexander Graf 
---
 Makefile.objs   |1 +
 Makefile.target |3 ---
 hw/usb-ohci.c   |9 +
 3 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index 5a679c6..f2c971c 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -179,6 +179,7 @@ hw-obj-$(CONFIG_I8254) += i8254.o
 hw-obj-$(CONFIG_PCSPK) += pcspk.o
 hw-obj-$(CONFIG_PCKBD) += pckbd.o
 hw-obj-$(CONFIG_USB_UHCI) += usb-uhci.o
+hw-obj-$(CONFIG_USB_OHCI) += usb-ohci.o
 hw-obj-$(CONFIG_FDC) += fdc.o
 hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
 hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
diff --git a/Makefile.target b/Makefile.target
index c96107c..74930ae 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -206,9 +206,6 @@ QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
 # xen backend driver support
 obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
 
-# USB layer
-obj-$(CONFIG_USB_OHCI) += usb-ohci.o
-
 # Inter-VM PCI shared memory
 obj-$(CONFIG_KVM) += ivshmem.o
 
diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
index 0c1bdeb..4716c27 100644
--- a/hw/usb-ohci.c
+++ b/hw/usb-ohci.c
@@ -1530,9 +1530,6 @@ static uint32_t ohci_mem_read(void *ptr, 
target_phys_addr_t addr)
 }
 }
 
-#ifdef TARGET_WORDS_BIGENDIAN
-retval = bswap32(retval);
-#endif
 return retval;
 }
 
@@ -1542,10 +1539,6 @@ static void ohci_mem_write(void *ptr, target_phys_addr_t 
addr, uint32_t val)
 
 addr &= 0xff;
 
-#ifdef TARGET_WORDS_BIGENDIAN
-val = bswap32(val);
-#endif
-
 /* Only aligned reads are allowed on OHCI */
 if (addr & 3) {
 fprintf(stderr, "usb-ohci: Mis-aligned write\n");
@@ -1698,7 +1691,7 @@ static void usb_ohci_init(OHCIState *ohci, DeviceState 
*dev,
 }
 
 ohci->mem = cpu_register_io_memory(ohci_readfn, ohci_writefn, ohci,
-   DEVICE_NATIVE_ENDIAN);
+   DEVICE_LITTLE_ENDIAN);
 ohci->localmem_base = localmem_base;
 
 ohci->name = dev->info->name;
-- 
1.6.0.2

[Qemu-devel] [PATCH 00/15] [RFC] MMIO endianness cleanup

The way mmio endianness is currently implemented is horrifying.

In the real world, CPUs have an endianness and write out data
to the memory bus. Instead of RAM, a receiving side here can be
a device. This device gets a byte stream again and needs to
make sense of it.

Since big endian systems write big endian numbers into memory
while little endian systems write little endian numbers there,
the device and software on the CPU need to be aware of this.

In practice, most devices these days (ISA, PCI) assume that
the data is little endian. So to communicate with such a device
from the CPU's side, the OS byte swaps all MMIO.

In qemu however, we simply pass the register value we find on
to the device. So any byte mangling the guest does to compensate
for the transfer screw us up by exposing byte swapped MMIO
on the device's side.

The way this has been fixed historically is by constructs like
this one:

#ifdef TARGET_WORDS_BIGENDIAN
val = bswap32(val);
#endif

With the move to get device code only compiled once, this has
become harder and harder to justify though, since we don't know
the target endianness during compile time.

It's especially bad since it doesn't make any sense at all to
clutter all the device code with endianness workarounds, aside
from the fact that about 80% of the device code currently does
the wrong thing :).

So my solution to the issue is to make every device define if
it's a little, big or native (target) endianness device. This
basically tells the layers below what endianness the device
expects mmio to occur in. Little endian devices on little endian
hosts don't swap. On big endian hosts they do. Same the other
way around.

The only reason I added "native" endianness is that we have some
PV devices like the fw_cfg that expect qemu's broken behavior.
These devices are the minority though. In the long run I'd expect
to see most code be committed with either of the two endianness
choices.

The patch set also includes a bunch of conversions for devices
that were already aware of endianness.

This is an RFC, so please comment as much as you can :).

Alexander Graf (15):
  exec: introduce endianness swapped mmio
  Add endianness as io mem parameter
  Make simple io mem handler endian aware
  dbdma: Make little endian
  pci-host: Delegate bswap to mmio layer
  uninorth: Get rid of bswap
  e1000: Make little endian
  prep: Declare as little endian
  versatile_pci: Declare as little endian
  ppc4xx_pci: Declare as little endian
  openpic: Replace explicit byte swap with endian hints
  rtl8139: Declare as little endian
  heathrow_pic: Declare as little endian
  isa_mmio: Always use little endian
  usb_ohci: Always use little endian

 Makefile.objs  |3 +
 Makefile.target|7 --
 cpu-common.h   |6 ++-
 exec.c |  145 +---
 hw/apb_pci.c   |9 ++-
 hw/apic.c  |3 +-
 hw/arm_gic.c   |3 +-
 hw/arm_sysctl.c|3 +-
 hw/arm_timer.c |5 +-
 hw/armv7m.c|2 +-
 hw/axis_dev88.c|6 +-
 hw/bonito.c|   19 --
 hw/cirrus_vga.c|   12 +++-
 hw/cs4231.c|3 +-
 hw/cuda.c  |3 +-
 hw/dec_pci.c   |6 +-
 hw/dp8393x.c   |3 +-
 hw/ds1225y.c   |6 +-
 hw/e1000.c |   11 +---
 hw/eccmemctl.c |6 +-
 hw/eepro100.c  |3 +-
 hw/empty_slot.c|3 +-
 hw/escc.c  |3 +-
 hw/esp.c   |3 +-
 hw/etraxfs_dma.c   |2 +-
 hw/etraxfs_eth.c   |3 +-
 hw/etraxfs_pic.c   |3 +-
 hw/etraxfs_ser.c   |3 +-
 hw/etraxfs_timer.c |3 +-
 hw/fdc.c   |6 +-
 hw/fw_cfg.c|6 +-
 hw/g364fb.c|3 +-
 hw/grackle_pci.c   |6 +-
 hw/gt64xxx.c   |9 +--
 hw/heathrow_pic.c  |5 +-
 hw/hpet.c  |3 +-
 hw/ide/macio.c |3 +-
 hw/ide/mmio.c  |6 +-
 hw/integratorcp.c  |9 ++-
 hw/intel-hda.c |3 +-
 hw/ioapic.c|3 +-
 hw/isa.h   |2 +-
 hw/isa_mmio.c  |  100 ++
 hw/ivshmem.c   |2 +-
 hw/jazz_led.c  |3 +-
 hw/lan9118.c   |3 +-
 hw/lance.c |3 +-
 hw/lsi53c895a.c|6 +-
 hw/m48t59.c|3 +-
 hw/mac_dbdma.c |6 +-
 hw/mac_nvram.c |3 +-
 hw/marvell_88w8618_audio.c |3 +-
 hw/mcf5206.c   |3 +-
 hw/mcf5208.c   |6 +-
 hw/mcf_fec.c   |3 +-
 hw/mcf_intc.c  |3 +-
 hw/mcf_uart.c  |3 +-
 hw/mips_jazz.c |   13 ++---
 hw/mips_malt

[Qemu-devel] [PATCH] ppc: kvm: fix signedness warning

I get a warning on a signed comparison with an unsigned variable, so
let's make the variable signed and be happy.

Signed-off-by: Alexander Graf 
---
 target-ppc/kvm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 5cacef7..5caa07c 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -132,7 +132,7 @@ int kvm_arch_get_registers(CPUState *env)
 {
 struct kvm_regs regs;
 struct kvm_sregs sregs;
-uint32_t i, ret;
+int i, ret;
 
 ret = kvm_vcpu_ioctl(env, KVM_GET_REGS, ®s);
 if (ret < 0)
-- 
1.6.0.2

[Qemu-devel] [PATCH 12/15] rtl8139: Declare as little endian

This patch replaces explicit bswaps with endianness hints to the
mmio layer.

Because we don't depend on the target endianness anymore, we can also
move the driver over to Makefile.objs.

Signed-off-by: Alexander Graf 
---
 Makefile.objs   |1 +
 Makefile.target |3 ---
 hw/rtl8139.c|   14 +-
 3 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index 37d4a10..5a679c6 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -216,6 +216,7 @@ hw-obj-y += ne2000.o
 hw-obj-y += eepro100.o
 hw-obj-y += pcnet.o
 hw-obj-y += e1000.o
+hw-obj-y += rtl8139.o
 
 hw-obj-$(CONFIG_SMC91C111) += smc91c111.o
 hw-obj-$(CONFIG_LAN9118) += lan9118.o
diff --git a/Makefile.target b/Makefile.target
index 02a7a66..c96107c 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -209,9 +209,6 @@ obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
 # USB layer
 obj-$(CONFIG_USB_OHCI) += usb-ohci.o
 
-# PCI network cards
-obj-y += rtl8139.o
-
 # Inter-VM PCI shared memory
 obj-$(CONFIG_KVM) += ivshmem.o
 
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 30a3960..4a73f6f 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -3125,17 +3125,11 @@ static void rtl8139_mmio_writeb(void *opaque, 
target_phys_addr_t addr, uint32_t
 
 static void rtl8139_mmio_writew(void *opaque, target_phys_addr_t addr, 
uint32_t val)
 {
-#ifdef TARGET_WORDS_BIGENDIAN
-val = bswap16(val);
-#endif
 rtl8139_io_writew(opaque, addr & 0xFF, val);
 }
 
 static void rtl8139_mmio_writel(void *opaque, target_phys_addr_t addr, 
uint32_t val)
 {
-#ifdef TARGET_WORDS_BIGENDIAN
-val = bswap32(val);
-#endif
 rtl8139_io_writel(opaque, addr & 0xFF, val);
 }
 
@@ -3147,18 +3141,12 @@ static uint32_t rtl8139_mmio_readb(void *opaque, 
target_phys_addr_t addr)
 static uint32_t rtl8139_mmio_readw(void *opaque, target_phys_addr_t addr)
 {
 uint32_t val = rtl8139_io_readw(opaque, addr & 0xFF);
-#ifdef TARGET_WORDS_BIGENDIAN
-val = bswap16(val);
-#endif
 return val;
 }
 
 static uint32_t rtl8139_mmio_readl(void *opaque, target_phys_addr_t addr)
 {
 uint32_t val = rtl8139_io_readl(opaque, addr & 0xFF);
-#ifdef TARGET_WORDS_BIGENDIAN
-val = bswap32(val);
-#endif
 return val;
 }
 
@@ -3367,7 +3355,7 @@ static int pci_rtl8139_init(PCIDevice *dev)
 /* I/O handler for memory-mapped I/O */
 s->rtl8139_mmio_io_addr =
 cpu_register_io_memory(rtl8139_mmio_read, rtl8139_mmio_write, s,
-   DEVICE_NATIVE_ENDIAN);
+   DEVICE_LITTLE_ENDIAN);
 
 pci_register_bar(&s->dev, 0, 0x100,
PCI_BASE_ADDRESS_SPACE_IO,  rtl8139_ioport_map);
-- 
1.6.0.2

[Qemu-devel] [PATCH 08/11] ahci: add ahci emulation

This patch adds an emulation layer for an ICH-7M AHCI controller. For now
this controller does not do IDE legacy emulation. It is a pure AHCI controller.

Signed-off-by: Alexander Graf 

---

v1 -> v2:

  - rename IDEExtender to IDEBusOps and make a pointer (kraxel)
  - make dma hooks explicit by putting them into ops struct (stefanha)
  - use qdev buses (kraxel)
  - minor cleanups
  - dprintf overhaul
  - add reset function

v2 -> v3:

  - add msi support (kraxel)
  - use MIN macro (kraxel)
  - add msi support (kraxel)
  - fix ncq with multiple ports
  - zap qdev properties (kraxel)
  - redesign legacy IF_SATA hooks (kraxel)
  - don't build ahci as part of target
  - move to ide/ (kwolf)

v3 -> v4:

  - prepare for endianness safety
  - add lspci dump (herbszt)
  - use ich7 instead of ich7m (herbszt)
  - fix lst+fis mapping (kraxel)
  - coding style (blue swirl)
  - explicit mmio setters/getters (blue swirl)

v4 -> v5:

  - s/H2dNcqFis/NCQFrame/g (blue swirl)
  - redo -drive magic (blue swirl)
  - bump BAR to 4k
  - rename to ICH7_AHCI_RAID (herbszt)
---
 Makefile.objs  |1 +
 default-configs/i386-softmmu.mak   |1 +
 default-configs/x86_64-softmmu.mak |1 +
 hw/ide/ahci.c  | 1380 
 4 files changed, 1383 insertions(+), 0 deletions(-)
 create mode 100644 hw/ide/ahci.c

diff --git a/Makefile.objs b/Makefile.objs
index 15569af..5241262 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -229,6 +229,7 @@ hw-obj-$(CONFIG_IDE_PIIX) += ide/piix.o
 hw-obj-$(CONFIG_IDE_CMD646) += ide/cmd646.o
 hw-obj-$(CONFIG_IDE_MACIO) += ide/macio.o
 hw-obj-$(CONFIG_IDE_VIA) += ide/via.o
+hw-obj-$(CONFIG_AHCI) += ide/ahci.o
 
 # SCSI layer
 hw-obj-y += lsi53c895a.o
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index ed00471..66b92af 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -19,6 +19,7 @@ CONFIG_IDE_QDEV=y
 CONFIG_IDE_PCI=y
 CONFIG_IDE_ISA=y
 CONFIG_IDE_PIIX=y
+CONFIG_AHCI=y
 CONFIG_NE2000_ISA=y
 CONFIG_PIIX_PCI=y
 CONFIG_SOUND=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 5183203..508e843 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -19,6 +19,7 @@ CONFIG_IDE_QDEV=y
 CONFIG_IDE_PCI=y
 CONFIG_IDE_ISA=y
 CONFIG_IDE_PIIX=y
+CONFIG_AHCI=y
 CONFIG_NE2000_ISA=y
 CONFIG_PIIX_PCI=y
 CONFIG_SOUND=y
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
new file mode 100644
index 000..5462fb9
--- /dev/null
+++ b/hw/ide/ahci.c
@@ -0,0 +1,1380 @@
+/*
+ * QEMU AHCI Emulation
+ *
+ * Copyright (c) 2010 qiaoch...@loongson.cn
+ * Copyright (c) 2010 Roland Elek 
+ * Copyright (c) 2010 Sebastian Herbszt 
+ * Copyright (c) 2010 Alexander Graf 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ *
+ * lspci dump of a real device:
+ *
+ * 00:1f.2 Class 0104: 8086:27c3 (rev 01)
+ * Subsystem: 1734:1085
+ * Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR- FastB2B-
+ * Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 
+#include 
+#include 
+#include 
+
+#include "monitor.h"
+#include "dma.h"
+#include "cpu-common.h"
+#include "blockdev.h"
+#include "internal.h"
+#include 
+
+/* #define DEBUG_AHCI */
+
+#ifdef DEBUG_AHCI
+#define DPRINTF(port, fmt, ...) \
+do { fprintf(stderr, "ahci: %s: [%d] ", __FUNCTION__, port); \
+ fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(port, fmt, ...) do {} while(0)
+#endif
+
+#define AHCI_PCI_BAR  5
+#define AHCI_MAX_PORTS32
+#define AHCI_MAX_SG   168 /* hardware max is 64K */
+#define AHCI_DMA_BOUNDARY 0x
+#define AHCI_USE_CLUSTERING   0
+#define AHCI_MAX_CMDS 32
+#define AHCI_CMD_SZ   32
+#define AHCI_CMD_SLOT_SZ  (AHCI_MAX_CMDS * AHCI_CMD_SZ)
+#define AHCI_RX_FIS_SZ256
+#define AHCI_CMD_TBL_CDB  0x40
+#define AHCI_CMD_TBL_HDR_SZ   0x80
+#define AHCI_CMD_TBL_SZ   (AHCI_CMD_TBL_HDR_SZ + (AHCI_MAX_SG * 16))
+#define AHCI_CMD_TBL_AR_SZ(AHCI_CMD_TBL_SZ * AHCI_MAX_CMDS)
+#define AHCI_PORT_PRIV_DMA_SZ (AHCI_CMD_SLOT_SZ + AHCI_CMD_TBL_AR_SZ + \
+   AHCI_RX_FIS_SZ)
+
+#define AHCI_IRQ_ON_SG(1 << 31

[Qemu-devel] [PATCH 06/15] uninorth: Get rid of bswap

There's no need to bswap once we correctly set the mmio to be little endian.

Signed-off-by: Alexander Graf 
---
 hw/unin_pci.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index f2e440e..5f15058 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -121,7 +121,6 @@ static void unin_data_write(ReadWriteHandler *handler,
 pcibus_t addr, uint32_t val, int len)
 {
 UNINState *s = container_of(handler, UNINState, data_handler);
-val = qemu_bswap_len(val, len);
 UNIN_DPRINTF("write addr %" FMT_PCIBUS " len %d val %x\n", addr, len, val);
 pci_data_write(s->host_state.bus,
unin_get_config_reg(s->host_state.config_reg, addr),
@@ -138,7 +137,6 @@ static uint32_t unin_data_read(ReadWriteHandler *handler,
 unin_get_config_reg(s->host_state.config_reg, addr),
 len);
 UNIN_DPRINTF("read addr %" FMT_PCIBUS " len %d val %x\n", addr, len, val);
-val = qemu_bswap_len(val, len);
 return val;
 }
 
@@ -156,7 +154,7 @@ static int pci_unin_main_init_device(SysBusDevice *dev)
 s->data_handler.read = unin_data_read;
 s->data_handler.write = unin_data_write;
 pci_mem_data = cpu_register_io_memory_simple(&s->data_handler,
- DEVICE_NATIVE_ENDIAN);
+ DEVICE_LITTLE_ENDIAN);
 sysbus_init_mmio(dev, 0x1000, pci_mem_config);
 sysbus_init_mmio(dev, 0x1000, pci_mem_data);
 
@@ -179,7 +177,7 @@ static int pci_u3_agp_init_device(SysBusDevice *dev)
 s->data_handler.read = unin_data_read;
 s->data_handler.write = unin_data_write;
 pci_mem_data = cpu_register_io_memory_simple(&s->data_handler,
- DEVICE_NATIVE_ENDIAN);
+ DEVICE_LITTLE_ENDIAN);
 sysbus_init_mmio(dev, 0x1000, pci_mem_config);
 sysbus_init_mmio(dev, 0x1000, pci_mem_data);
 
-- 
1.6.0.2

[Qemu-devel] [PATCH 14/15] isa_mmio: Always use little endian