diff mbox

[11/13] Move pci_parse_devaddr to qdev-properties

Message ID 8efa27ccfaf23cc561d2583aa34ca834fd60c2f3.1338799936.git.jan.kiszka@siemens.com
State New
Headers show

Commit Message

Jan Kiszka June 4, 2012, 8:52 a.m. UTC
We will some use this function also for property parsing, so move it
over unmodified and rename it.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 hw/pci-hotplug.c     |    2 +-
 hw/pci.c             |   67 +-------------------------------------------------
 hw/pci.h             |    5 ---
 hw/qdev-properties.c |   65 ++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h            |    5 +++
 5 files changed, 72 insertions(+), 72 deletions(-)

Comments

Andreas Färber June 7, 2012, 12:57 p.m. UTC | #1
Am 04.06.2012 10:52, schrieb Jan Kiszka:
> We will some use this function also for property parsing, so move it
> over unmodified and rename it.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

These last three patches collide with Paolo's QOM properties
refactoring: qdev properties are being generalized to Object and on my
GitHub "realize" branch are being moved to qom/object-properties.c
(object.c in the original series). Please defer this change.

Thanks,
Andreas
Jan Kiszka June 7, 2012, 3:11 p.m. UTC | #2
On 2012-06-07 14:57, Andreas Färber wrote:
> Am 04.06.2012 10:52, schrieb Jan Kiszka:
>> We will some use this function also for property parsing, so move it
>> over unmodified and rename it.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> 
> These last three patches collide with Paolo's QOM properties
> refactoring: qdev properties are being generalized to Object and on my
> GitHub "realize" branch are being moved to qom/object-properties.c
> (object.c in the original series). Please defer this change.

Depends on how long merging of those branches shall take. This is some
important piece for preparing device assignment for upstream, thus
finally closing the qemu-kvm fork. I need all this back-merged in
qemu-kvm soon to proceed.

Can you (both) comment on the merge schedule for your patches? Are we
talking about a week or so?

Jan
Andreas Färber June 7, 2012, 3:56 p.m. UTC | #3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 07.06.2012 17:11, schrieb Jan Kiszka:
> On 2012-06-07 14:57, Andreas Färber wrote:
>> These last three patches collide with Paolo's QOM properties 
>> refactoring: qdev properties are being generalized to Object and
>> on my GitHub "realize" branch are being moved to
>> qom/object-properties.c (object.c in the original series). Please
>> defer this change.
> 
> Depends on how long merging of those branches shall take. This is
> some important piece for preparing device assignment for upstream,
> thus finally closing the qemu-kvm fork. I need all this back-merged
> in qemu-kvm soon to proceed.
> 
> Can you (both) comment on the merge schedule for your patches? Are
> we talking about a week or so?

I'm working towards sending the updated patches from realize branch
today and the PULL by tomorrow. When it gets merged I cannot predict.

We could speed this up if Paolo takes a look at what I have so far,
starting at "qdev: Push state up to Object":
https://github.com/afaerber/qemu-cpu/commits/realize
- From there on I expect it's gonna be cherry-picking and rebasing again.

Maybe split your series in two? I can cc you on the PULL so that you
can rebase and immediately piggyback the property changes. ;)

Andreas

- -- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBAgAGBQJP0M8rAAoJEPou0S0+fgE/928P/jTqH25GYtdtqPYLVkjRcMjL
mRTl2ar8UOuqFdFFZMKOtoGXNK2lmcqAHkQ8++EkFdhzlrVvLOGVhG4/abRKr8Bx
dKv5j1xNSW1wG7arDIWQj6EuKOBuzlCtBrHrU83vq5hcx3usJZJUJeoLH1D1D9st
FCMRPy1g4NLIqPhoOfp1muqP9VLBVwmpKuFzXTe1Z3l4eIRY61jNKfnQF9zczUWy
eJj2ntvBFOOD9myyCfyEcw1bnLNA7UalyhSGQ4ien8novlyYXCqT5+1uLdYeUmdm
BTlPXlyRs5yrawFn2VlKEULxKQWyb+ddJzM+ppHGzdFRz4keqwkbGaCfKliuDJbN
AASeN4IWLJMCJxz68eZvKSvzMn5A2IzwtFx0N04l4rZbTlylQtoZ5/W4D//+mH2n
hOvZNptsI5Ht29G1hDL5z/VdseRV3XjR64S578bKOj1icpNLfmV4uyNA/gwMOp8Q
htzaswdSMejeeJvbxylEtuh1phyMJmnwUf2L+JuG1Ay1v3QngrsVX2gJqnC8ES3w
LqiIf1J08T9BhPLYrmm3pAsb5dorSLz+vZmhVB3iZlQAJXuEAjyaZoZJo/u02zY1
BRGfG0HCB4b94FVpcTTorFjf57oSB4MG/xN31rtovBX25oRXNFMWqemetF8A8IWc
kprIWBCzOSC2ZGE1SXzL
=DLcx
-----END PGP SIGNATURE-----
Jan Kiszka June 8, 2012, 10:57 a.m. UTC | #4
On 2012-06-07 17:56, Andreas Färber wrote:
> Am 07.06.2012 17:11, schrieb Jan Kiszka:
>> On 2012-06-07 14:57, Andreas Färber wrote:
>>> These last three patches collide with Paolo's QOM properties 
>>> refactoring: qdev properties are being generalized to Object and
>>> on my GitHub "realize" branch are being moved to
>>> qom/object-properties.c (object.c in the original series). Please
>>> defer this change.
> 
>> Depends on how long merging of those branches shall take. This is
>> some important piece for preparing device assignment for upstream,
>> thus finally closing the qemu-kvm fork. I need all this back-merged
>> in qemu-kvm soon to proceed.
> 
>> Can you (both) comment on the merge schedule for your patches? Are
>> we talking about a week or so?
> 
> I'm working towards sending the updated patches from realize branch
> today and the PULL by tomorrow. When it gets merged I cannot predict.

To my understanding, patch 2 of your series faces some discussions, and
the rest will require refactoring once that has settled. So I guess it's
better now to proceed with my patches and rebase your changes on top of
them, right?

Jan
Andreas Färber June 8, 2012, 12:03 p.m. UTC | #5
Am 08.06.2012 12:57, schrieb Jan Kiszka:
> On 2012-06-07 17:56, Andreas Färber wrote:
>> Am 07.06.2012 17:11, schrieb Jan Kiszka:
>>> On 2012-06-07 14:57, Andreas Färber wrote:
>>>> These last three patches collide with Paolo's QOM properties 
>>>> refactoring: qdev properties are being generalized to Object and
>>>> on my GitHub "realize" branch are being moved to
>>>> qom/object-properties.c (object.c in the original series). Please
>>>> defer this change.
>>
>>> Depends on how long merging of those branches shall take. This is
>>> some important piece for preparing device assignment for upstream,
>>> thus finally closing the qemu-kvm fork. I need all this back-merged
>>> in qemu-kvm soon to proceed.
>>
>>> Can you (both) comment on the merge schedule for your patches? Are
>>> we talking about a week or so?
>>
>> I'm working towards sending the updated patches from realize branch
>> today and the PULL by tomorrow. When it gets merged I cannot predict.
> 
> To my understanding, patch 2 of your series faces some discussions, and
> the rest will require refactoring once that has settled. So I guess it's
> better now to proceed with my patches and rebase your changes on top of
> them, right?

No, there's a patch queue of 28 before the patches under discussion,
some of which touch qdev-properties.c as well. Those under discussion
are not on qom-next yet.
What's open is that the Makefile series has not been pulled yet and
pretty much everyone will need to rebase on that if it gets applied.
Hoping for a statement from Anthony there.

Can't understand that you're trying to push your v1 so hard now when our
series have been on the list for much longer. ;)

Cheers,
Andreas
Jan Kiszka June 8, 2012, 12:14 p.m. UTC | #6
On 2012-06-08 14:03, Andreas Färber wrote:
> Am 08.06.2012 12:57, schrieb Jan Kiszka:
>> On 2012-06-07 17:56, Andreas Färber wrote:
>>> Am 07.06.2012 17:11, schrieb Jan Kiszka:
>>>> On 2012-06-07 14:57, Andreas Färber wrote:
>>>>> These last three patches collide with Paolo's QOM properties 
>>>>> refactoring: qdev properties are being generalized to Object and
>>>>> on my GitHub "realize" branch are being moved to
>>>>> qom/object-properties.c (object.c in the original series). Please
>>>>> defer this change.
>>>
>>>> Depends on how long merging of those branches shall take. This is
>>>> some important piece for preparing device assignment for upstream,
>>>> thus finally closing the qemu-kvm fork. I need all this back-merged
>>>> in qemu-kvm soon to proceed.
>>>
>>>> Can you (both) comment on the merge schedule for your patches? Are
>>>> we talking about a week or so?
>>>
>>> I'm working towards sending the updated patches from realize branch
>>> today and the PULL by tomorrow. When it gets merged I cannot predict.
>>
>> To my understanding, patch 2 of your series faces some discussions, and
>> the rest will require refactoring once that has settled. So I guess it's
>> better now to proceed with my patches and rebase your changes on top of
>> them, right?
> 
> No, there's a patch queue of 28 before the patches under discussion,
> some of which touch qdev-properties.c as well. Those under discussion
> are not on qom-next yet.
> What's open is that the Makefile series has not been pulled yet and
> pretty much everyone will need to rebase on that if it gets applied.
> Hoping for a statement from Anthony there.

As I was on CC in that second series, right after you told me you would
CC me to allow tracking progress. So I was assuming it was related to
this topic.

> 
> Can't understand that you're trying to push your v1 so hard now when our
> series have been on the list for much longer. ;)

I explained the reason, and I think my patches (minus the dropped one)
are ready based on the feedback.

I'm fine if important central refactorings close master for a short
period at the beginning of a merge window and require rebasing of other
patches afterward. But that should really be *short*.

Jan
Andreas Färber June 8, 2012, 12:18 p.m. UTC | #7
Am 08.06.2012 14:14, schrieb Jan Kiszka:
> On 2012-06-08 14:03, Andreas Färber wrote:
>> Can't understand that you're trying to push your v1 so hard now when our
>> series have been on the list for much longer. ;)
> 
> I explained the reason, and I think my patches (minus the dropped one)
> are ready based on the feedback.
> 
> I'm fine if important central refactorings close master for a short
> period at the beginning of a merge window and require rebasing of other
> patches afterward. But that should really be *short*.

We had a long Hard Freeze that closed master. Your patches are new, so I
oppose you sneaking by and having me rebase Paolo's patches on yours. If
someone else wants to rebase them on yours that's fine with me.

Andreas
Jan Kiszka June 8, 2012, 12:45 p.m. UTC | #8
On 2012-06-08 14:18, Andreas Färber wrote:
> Am 08.06.2012 14:14, schrieb Jan Kiszka:
>> On 2012-06-08 14:03, Andreas Färber wrote:
>>> Can't understand that you're trying to push your v1 so hard now when our
>>> series have been on the list for much longer. ;)
>>
>> I explained the reason, and I think my patches (minus the dropped one)
>> are ready based on the feedback.
>>
>> I'm fine if important central refactorings close master for a short
>> period at the beginning of a merge window and require rebasing of other
>> patches afterward. But that should really be *short*.
> 
> We had a long Hard Freeze that closed master. Your patches are new, so I
> oppose you sneaking by and having me rebase Paolo's patches on yours. If
> someone else wants to rebase them on yours that's fine with me.

If your patches get merged over the next week, I'm fine. If not, be
warned to see me grumbling again. ;)

Michael, unless there are other remarks, 1 and 3-10 could be picked up
by you and pushed already. I'll send an update for 6 to fix the commit log.

Jan
Anthony Liguori June 8, 2012, 1:55 p.m. UTC | #9
On 06/07/2012 08:57 PM, Andreas Färber wrote:
> Am 04.06.2012 10:52, schrieb Jan Kiszka:
>> We will some use this function also for property parsing, so move it
>> over unmodified and rename it.
>>
>> Signed-off-by: Jan Kiszka<jan.kiszka@siemens.com>
>
> These last three patches collide with Paolo's QOM properties
> refactoring: qdev properties are being generalized to Object and on my
> GitHub "realize" branch are being moved to qom/object-properties.c
> (object.c in the original series). Please defer this change.

Sorry, this doesn't scale.

Patches need to go in when they're ready.  If that means someone branch has a 
hard time rebasing, it probably means that branch should have attempted to merge 
sooner.

If you want to work out the issues earlier, then setup a next branch or 
something like that.

But don't expect someone else to hold up there work just because it conflicts 
with yours.  That kind of ordering won't scale in a community as large as ours.

Regards,

Anthony Liguori

>
> Thanks,
> Andreas
>
Michael S. Tsirkin June 8, 2012, 2:17 p.m. UTC | #10
On Fri, Jun 08, 2012 at 02:45:47PM +0200, Jan Kiszka wrote:
> On 2012-06-08 14:18, Andreas Färber wrote:
> > Am 08.06.2012 14:14, schrieb Jan Kiszka:
> >> On 2012-06-08 14:03, Andreas Färber wrote:
> >>> Can't understand that you're trying to push your v1 so hard now when our
> >>> series have been on the list for much longer. ;)
> >>
> >> I explained the reason, and I think my patches (minus the dropped one)
> >> are ready based on the feedback.
> >>
> >> I'm fine if important central refactorings close master for a short
> >> period at the beginning of a merge window and require rebasing of other
> >> patches afterward. But that should really be *short*.
> > 
> > We had a long Hard Freeze that closed master. Your patches are new, so I
> > oppose you sneaking by and having me rebase Paolo's patches on yours. If
> > someone else wants to rebase them on yours that's fine with me.
> 
> If your patches get merged over the next week, I'm fine. If not, be
> warned to see me grumbling again. ;)
> 
> Michael, unless there are other remarks, 1 and 3-10 could be picked up
> by you and pushed already. I'll send an update for 6 to fix the commit log.
> 
> Jan

They look ready to me too, so I can pick your patches up and put them on
the pci branch. Prefer doing it Sunday when I'm rested.
But FYI I just sent a pull request to Anthony Thursday and I
try not to flood him with more than one a week unless there's a huge
regression to fix.

If large changes land in master meanwhile we'll have to resolve the
conflict but that's par for the course.

> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
Anthony Liguori June 8, 2012, 2:20 p.m. UTC | #11
On 06/08/2012 10:17 PM, Michael S. Tsirkin wrote:
> On Fri, Jun 08, 2012 at 02:45:47PM +0200, Jan Kiszka wrote:
>> On 2012-06-08 14:18, Andreas Färber wrote:
>>> Am 08.06.2012 14:14, schrieb Jan Kiszka:
>>>> On 2012-06-08 14:03, Andreas Färber wrote:
>>>>> Can't understand that you're trying to push your v1 so hard now when our
>>>>> series have been on the list for much longer. ;)
>>>>
>>>> I explained the reason, and I think my patches (minus the dropped one)
>>>> are ready based on the feedback.
>>>>
>>>> I'm fine if important central refactorings close master for a short
>>>> period at the beginning of a merge window and require rebasing of other
>>>> patches afterward. But that should really be *short*.
>>>
>>> We had a long Hard Freeze that closed master. Your patches are new, so I
>>> oppose you sneaking by and having me rebase Paolo's patches on yours. If
>>> someone else wants to rebase them on yours that's fine with me.
>>
>> If your patches get merged over the next week, I'm fine. If not, be
>> warned to see me grumbling again. ;)
>>
>> Michael, unless there are other remarks, 1 and 3-10 could be picked up
>> by you and pushed already. I'll send an update for 6 to fix the commit log.
>>
>> Jan
>
> They look ready to me too, so I can pick your patches up and put them on
> the pci branch. Prefer doing it Sunday when I'm rested.
> But FYI I just sent a pull request to Anthony Thursday and I
> try not to flood him with more than one a week unless there's a huge
> regression to fix.

FYI, I don't plan on applying any more pulls until Monday most likely as I'm 
flying back to the US tomorrow morning.  If you want to update the PULL on 
Sunday, just send out a new request that includes the old and I'll ignore it.

Paolo's series may conflict, but I don't think resolving will be too hard.

Regards,

Anthony Liguori

>
> If large changes land in master meanwhile we'll have to resolve the
> conflict but that's par for the course.
>
>> --
>> Siemens AG, Corporate Technology, CT T DE IT 1
>> Corporate Competence Center Embedded Linux
Andreas Färber June 8, 2012, 7:21 p.m. UTC | #12
Am 08.06.2012 15:55, schrieb Anthony Liguori:
> On 06/07/2012 08:57 PM, Andreas Färber wrote:
>> Am 04.06.2012 10:52, schrieb Jan Kiszka:
>>> We will some use this function also for property parsing, so move it
>>> over unmodified and rename it.
>>>
>>> Signed-off-by: Jan Kiszka<jan.kiszka@siemens.com>
>>
>> These last three patches collide with Paolo's QOM properties
>> refactoring: qdev properties are being generalized to Object and on my
>> GitHub "realize" branch are being moved to qom/object-properties.c
>> (object.c in the original series). Please defer this change.
> 
> Sorry, this doesn't scale.

Jinx! :)

> Patches need to go in when they're ready.  If that means someone branch
> has a hard time rebasing, it probably means that branch should have
> attempted to merge sooner.
> 
> If you want to work out the issues earlier, then setup a next branch or
> something like that.

We *are* talking about qom-NEXT here! It serves exactly that purpose, to
have a known location for people to rebase on and to avoid conflicts.
Jan was ignoring that, I'm guessing because he doesn't read qemu-devel
unless cc'ed. And in turn I don't consider it the duty of the qom-next
maintainer to check everyone's submission for possible fumbling in
qdev/qom code and rebasing onto every random open PULL. (Note that I'm
not complaining about properties being added in some random file, I am
specifically annoyed about refactoring in hw/qdev-properties.c after
these series have been around for like two months and after I officially
announced the branch as requested by you.)

And let's not forget that a certain release manager promised to talk to
me/us about the post-1.1 merge plan after rc4 but then instead decided
to fold rc4 and final and opened up the master branch without discussing
any merge strategy, contributing to this chaos. The way you are handling
it, it is totally unclear for submaintainers in which order series are
going to go in. So either we need to coordinate PULLs among each other
as attempted here, or you as maintainer need to volunteer to merge such
conflicting PULLs yourself and not just bouncing them.

Anyway, some people need to take care of packaging the tarball after
it's released and your part in the release process is finished. That
takes time, and your change of schedule stirred my time planning for a
whole week. ;)

Plus a contributor to qom-next surpassing himself with another invasive
refactoring that you wanted to fast-track wasn't helpful either.

Not to mention that this is also connected to a nack of yours for which
we still don't have a solution, while the original author is on travels.

So yes, I could have started merging qom-next earlier (e.g., had I taken
the decision to split it earlier) and you could've supported that effort
better through early review, better planning and better communication.

> But don't expect someone else to hold up there work just because it
> conflicts with yours.  That kind of ordering won't scale in a community
> as large as ours.

I am only one and cannot rebase onto every open pull request, especially
not for a branch that was only meant to bridge the imposed Hard Freeze
and should thus go away quickly because no longer needed.

If it were a private branch/series of mine then that would be a
different matter of course.

Nevertheless conflicts do happen and need to be resolved by someone. If
you are volunteering, so that I don't have to speak up, that's fine with
me. But saying that ordering doesn't scale in a community is not solving
the problem.

Regards,
Andreas
diff mbox

Patch

diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index aff4d85..60c8989 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -41,7 +41,7 @@  static int read_pci_devaddr(Monitor *mon, const char *addrstr,
     if (!strncmp(addrstr, "pci_addr=", 9)) {
         addrstr += 9;
     }
-    if (pci_parse_devaddr(addrstr, addr, 0)) {
+    if (qemu_parse_pci_devaddr(addrstr, addr, 0)) {
         monitor_printf(mon, "Invalid pci address\n");
         return -1;
     }
diff --git a/hw/pci.c b/hw/pci.c
index 62ad61c..5056fc4 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -508,71 +508,6 @@  static void pci_set_default_subsystem_id(PCIDevice *pci_dev)
                  pci_default_sub_device_id);
 }
 
-/*
- * Parse [[<domain>:]<bus>:]<slot>, return -1 on error if !PCI_DEVADDR_WITH_FUNC
- *       [[<domain>:]<bus>:]<slot>.<func>, return -1 on error
- */
-int pci_parse_devaddr(const char *addrstr, PCIDeviceAddress *addr,
-                      unsigned int flags)
-{
-    const char *p;
-    char *e;
-    unsigned long val;
-    unsigned long dom = 0, bus = 0;
-    unsigned int slot;
-    unsigned int func = 0;
-
-    p = addrstr;
-    val = strtoul(p, &e, 16);
-    if (e == p) {
-        return -1;
-    }
-    if (*e == ':') {
-        bus = val;
-        p = e + 1;
-        val = strtoul(p, &e, 16);
-        if (e == p) {
-            return -1;
-        }
-        if (*e == ':') {
-            dom = bus;
-            bus = val;
-            p = e + 1;
-            val = strtoul(p, &e, 16);
-            if (e == p) {
-                return -1;
-            }
-        }
-    }
-
-    slot = val;
-
-    if (flags & PCI_DEVADDR_WITH_FUNC) {
-        if (*e != '.') {
-            return -1;
-        }
-        p = e + 1;
-        val = strtoul(p, &e, 16);
-        if (e == p) {
-            return -1;
-        }
-        func = val;
-    }
-
-    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7) {
-        return -1;
-    }
-    if (*e) {
-        return -1;
-    }
-
-    addr->domain = dom;
-    addr->bus = bus;
-    addr->slot = slot;
-    addr->function = func;
-    return 0;
-}
-
 PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr)
 {
     PCIDeviceAddress addr;
@@ -582,7 +517,7 @@  PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr)
         return pci_find_bus_nr(pci_find_root_bus(0), 0);
     }
 
-    if (pci_parse_devaddr(devaddr, &addr, 0) < 0) {
+    if (qemu_parse_pci_devaddr(devaddr, &addr, 0) < 0) {
         return NULL;
     }
 
diff --git a/hw/pci.h b/hw/pci.h
index 6c48ffa..a3e5ad9 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -340,11 +340,6 @@  PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
 int pci_qdev_find_device(const char *id, PCIDevice **pdev);
 PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr);
 
-#define PCI_DEVADDR_WITH_FUNC           2
-
-int pci_parse_devaddr(const char *addrstr, PCIDeviceAddress *addr,
-                      unsigned int flags);
-
 void pci_device_deassert_intx(PCIDevice *dev);
 
 static inline void
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index b7b5597..14ea394 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -817,6 +817,71 @@  PropertyInfo qdev_prop_losttickpolicy = {
 /* --- pci address --- */
 
 /*
+ * Parse [[<domain>:]<bus>:]<slot>, return -1 on error if !PCI_DEVADDR_WITH_FUNC
+ *       [[<domain>:]<bus>:]<slot>.<func>, return -1 on error
+ */
+int qemu_parse_pci_devaddr(const char *addrstr, PCIDeviceAddress *addr,
+                           unsigned int flags)
+{
+    const char *p;
+    char *e;
+    unsigned long val;
+    unsigned long dom = 0, bus = 0;
+    unsigned int slot;
+    unsigned int func = 0;
+
+    p = addrstr;
+    val = strtoul(p, &e, 16);
+    if (e == p) {
+        return -1;
+    }
+    if (*e == ':') {
+        bus = val;
+        p = e + 1;
+        val = strtoul(p, &e, 16);
+        if (e == p) {
+            return -1;
+        }
+        if (*e == ':') {
+            dom = bus;
+            bus = val;
+            p = e + 1;
+            val = strtoul(p, &e, 16);
+            if (e == p) {
+                return -1;
+            }
+        }
+    }
+
+    slot = val;
+
+    if (flags & PCI_DEVADDR_WITH_FUNC) {
+        if (*e != '.') {
+            return -1;
+        }
+        p = e + 1;
+        val = strtoul(p, &e, 16);
+        if (e == p) {
+            return -1;
+        }
+        func = val;
+    }
+
+    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7) {
+        return -1;
+    }
+    if (*e) {
+        return -1;
+    }
+
+    addr->domain = dom;
+    addr->bus = bus;
+    addr->slot = slot;
+    addr->function = func;
+    return 0;
+}
+
+/*
  * bus-local address, i.e. "$slot" or "$slot.$fn"
  */
 static void set_pci_devfn(Object *obj, Visitor *v, void *opaque,
diff --git a/hw/qdev.h b/hw/qdev.h
index 4e90119..102550b 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -360,4 +360,9 @@  void qdev_set_parent_bus(DeviceState *dev, BusState *bus);
 
 extern int qdev_hotplug;
 
+#define PCI_DEVADDR_WITH_FUNC           2
+
+int qemu_parse_pci_devaddr(const char *addrstr, PCIDeviceAddress *addr,
+                           unsigned int flags);
+
 #endif