Re: [Qemu-devel] [PATCH for-1.6 V2 0/2] pvpanic: Separate pvpanic from machine type
On Wed, 2013-08-14 at 10:02 +0300, Ronen Hod wrote: > How about adding a flag that tells QEMU whether to pause or reboot the guest > after the panic? > We cannot assume that we always have a management layer that takes care > of this. > One example is Microsoft's WHQL that deliberately generates a BSOD, and then > examines the dump files. After this patch the pvpanic is not part of the global devices anymore so just don't enable it if you want to reboot on BSOD. In my opinion "reboot after panic" equals "run without pvpanic device" Marcel > > Ronen. > > On 08/11/2013 06:10 PM, Marcel Apfelbaum wrote: > > Creating the pvpanic device as part of the machine type has the > > potential to trigger guest OS, guest firmware and driver bugs. > > The potential of such was originally viewed as minimal. > > However, since releasing 1.5 with pvpanic as part > > of the builtin machine type, several issues were observed > > in the field: > > - Some Windows versions triggered 'New Hardware Wizard' and > > an unidentified device appeared in Device Manager. > > - Issue reported off list: on Linux >= 3.10 > > the pvpanic driver breaks the reset on crash option: > > VM stops instead of being reset. > > > > pvpanic device also changes monitor command behaviour in some cases, > > such silent incompatible changes aren't expected by management tools: > > - Monitor command requires 'cont' before 'system_reset' > > in order to restart the VM after kernel panic/BSOD > > > > Note that libvirt is the main user and libvirt people indicated their > > preference to creating device with -device pvpanic rather than a > > built-in one that can't be removed. > > > > These issues were raised at last KVM call. The agreement reached > > there was that we were a bit too rash to make the device > > a builtin, and that for 1.6 we should drop the pvpanic device from the > > default machine type, instead teach management tools to add it by > > default using -device pvpanic. > > It's not clear whether changing 1.5 behaviour at this point > > is a sane thing, so this patchset doesn't touch 1.5 machine type. > > > > This patch series reworks the patchset from Hu Tao > > (don't create pvpanic device by default) > > addressing comments and modifying behaviour according > > to what was discussed on the call. > > Please review and consider for 1.6. > > > > A related discussion can be followed at > > http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00036.html. > > > > This is a continuation of patches sent by Hu Tao: > > http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00124.html > > http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00125.html > > > > Changes from v1 (by Hu Tao): > > - Keep pvpanic device enabled by default for 1.5 > > for backport compatibility > > - Addressed Andreas Färber review (removed bus type) > > - Small changes to be posible to enable pvpanic > > both from command line and from machine_init > > - Added pvpanic to MISC category > > > > Marcel Apfelbaum (2): > >hw/misc: don't create pvpanic device by default > >hw/misc: make pvpanic known to user > > > > hw/i386/pc_piix.c | 9 - > > hw/i386/pc_q35.c | 7 --- > > hw/misc/pvpanic.c | 25 ++--- > > 3 files changed, 18 insertions(+), 23 deletions(-) > > >
Re: [Qemu-devel] [PATCH v4 0/3] qemu-help: improve -device command line help
On Tue, 2013-08-13 at 11:57 +0200, Markus Armbruster wrote: > This isn't patch review, just a couple of observations and questions. > > Current use of categories, please correct misunderstandings: > > * A device can have multiple categories. Most (all?) devices currently > have exactly one. All device have only one category for now. This is a preparation for multifunction devices. > > * -device help shows categories, like this: > > name "NAME", bus "BUS", categories "CAT1" "CAT2"... > > * -device help is sorted by category > > * -device help shows the device once per category. If the device has no > categories, it's not shown at all. > > Should we require devices to have at least one category? The whole idea of the patch was to help user navigating the command line help. A device category will give a user at least a hint. > > Eric, does libvirt still parse -device help? If yes, can it cope with > the addition of "categories ..."? Also the "old" parsing mechanism would still work, it splits the raw by "," and looks for the key like "name". > > A possibly better way to group help by category: instead of adding > categories to each line, add category headlines, like this: > > Controller/Bridge/Hub devices: > name "NAME", bus "BUS"... > ... > USB devices: > name "NAME", bus "BUS"... > ... > Storage devices: > ... > > This way, showing devices with multiple categories once per category > actually makes sense. You are right. This is a very good "next step". > > DEVICE_CATEGORY_STORAGE comprises both storage controller devices > (providing storage buses such as IDE, SCSI) and storage devices > (plugging into such buses). Some of our devices (*-fdc, virtio-blk) > integrate both in one device model[*]. Yes, it does comprises both. It still helps the user that can now grep by this storage category and select from it rather than going on all the help. > > DEVICE_CATEGORY_USB comprises *only* host controller devices (providing > USB bus(es)), *not* USB devices (plugging into USB bus). These are > categorized by function instead: The "USB" is used here as a code-name rather than the BUS. It was never my intention to clone the bus type. It is already part of the description. > > * DEVICE_CATEGORY_BRIDGE: usb-host, usb-hub > > * DEVICE_CATEGORY_STORAGE: usb-bot, usb-uas, usb-storage > > * DEVICE_CATEGORY_NETWORK: usb-bt-dongle, usb-net > > * DEVICE_CATEGORY_INPUT: usb-kbd, usb-ccid, usb-wacom-tablet, > usb-braille, usb-mouse, usb-serial > > * DEVICE_CATEGORY_SOUND: usb-audio > > * DEVICE_CATEGORY_MISC: usb-tablet, usb-redir > > Should they additionally be DEVICE_CATEGORY_USB? As mentioned earlier, better if not (in my opinion.) > > Why do we have DEVICE_CATEGORY_USB, but no categories for other buses, > like PCI or ISA? Devices providing such buses are > DEVICE_CATEGORY_BRIDGE. Why is USB different? Again, we already have the bus information, I was looking for functional info. "USB" was not used here as a BUS, but like a standalone "function". > > Why is usb-host DEVICE_CATEGORY_BRIDGE? The category is named "Controller/Bridge/Hub" at command line I didn't want the name to be too long in the code. > Why is usb-tablet DEVICE_CATEGORY_MISC, but usb-wacom-tablet > DEVICE_CATEGORY_INPUT? This is a bug. Thanks for catching it! > > DEVICE_CATEGORY_INPUT is weird. Some devices in that category are truly > about input (usb-mouse, usb-kbd), others are at least as often used for > output (serial devices, PIOs)... It makes sense to rename it to "Input/Output". > > The difference between DEVICE_CATEGORY_INPUT and DEVICE_CATEGORY_MISC > seems unclear (see usb-tablet vs. usb-wacom-tablet above). Putting the bug aside, MISC is the category for devices that does not match a specific category. Thanks for the review Markus! The bottom line is that I wanted to help users in their adventure to form the command line by creating "Categories" that would split the 145 help rows in batches of ~20. In this way the user can first select the desired category and then choose the device. > > > > [*] I hate that.
Re: [Qemu-devel] [PATCH v4 0/3] qemu-help: improve -device command line help
On Wed, 2013-08-21 at 11:23 +0200, Markus Armbruster wrote: > Marcel Apfelbaum writes: > > > On Tue, 2013-08-13 at 11:57 +0200, Markus Armbruster wrote: > >> This isn't patch review, just a couple of observations and questions. > >> > >> Current use of categories, please correct misunderstandings: > >> > >> * A device can have multiple categories. Most (all?) devices currently > >> have exactly one. > > All device have only one category for now. > > This is a preparation for multifunction devices. > > > >> > >> * -device help shows categories, like this: > >> > >> name "NAME", bus "BUS", categories "CAT1" "CAT2"... > >> > >> * -device help is sorted by category > >> > >> * -device help shows the device once per category. If the device has no > >> categories, it's not shown at all. > >> > >> Should we require devices to have at least one category? > > The whole idea of the patch was to help user navigating the command line > > help. > > A device category will give a user at least a hint. > > Understand. > > Devices without category are omitted from help. That's not good. > Should we require devices to have at least one category? Or should we > change help to show devices without a category? I prefer to require each device to have a category. The interesting part is how to enforce it. > > >> Eric, does libvirt still parse -device help? If yes, can it cope with > >> the addition of "categories ..."? > > Also the "old" parsing mechanism would still work, it splits the raw > > by "," and looks for the key like "name". > > > >> > >> A possibly better way to group help by category: instead of adding > >> categories to each line, add category headlines, like this: > >> > >> Controller/Bridge/Hub devices: > >> name "NAME", bus "BUS"... > >> ... > >> USB devices: > >> name "NAME", bus "BUS"... > >> ... > >> Storage devices: > >> ... > >> > >> This way, showing devices with multiple categories once per category > >> actually makes sense. > > You are right. This is a very good "next step". > > I'd love to see a patch from you :) On my to-do list ... > > >> DEVICE_CATEGORY_STORAGE comprises both storage controller devices > >> (providing storage buses such as IDE, SCSI) and storage devices > >> (plugging into such buses). Some of our devices (*-fdc, virtio-blk) > >> integrate both in one device model[*]. > > Yes, it does comprises both. It still helps the user that can now > > grep by this storage category and select from it rather than > > going on all the help. > > > >> > >> DEVICE_CATEGORY_USB comprises *only* host controller devices (providing > >> USB bus(es)), *not* USB devices (plugging into USB bus). These are > >> categorized by function instead: > > The "USB" is used here as a code-name rather than the BUS. > > It was never my intention to clone the bus type. It is already > > part of the description. > > > >> > >> * DEVICE_CATEGORY_BRIDGE: usb-host, usb-hub > >> > >> * DEVICE_CATEGORY_STORAGE: usb-bot, usb-uas, usb-storage > >> > >> * DEVICE_CATEGORY_NETWORK: usb-bt-dongle, usb-net > >> > >> * DEVICE_CATEGORY_INPUT: usb-kbd, usb-ccid, usb-wacom-tablet, > >> usb-braille, usb-mouse, usb-serial > >> > >> * DEVICE_CATEGORY_SOUND: usb-audio > >> > >> * DEVICE_CATEGORY_MISC: usb-tablet, usb-redir > >> > >> Should they additionally be DEVICE_CATEGORY_USB? > > As mentioned earlier, better if not (in my opinion.) > > > >> > >> Why do we have DEVICE_CATEGORY_USB, but no categories for other buses, > >> like PCI or ISA? Devices providing such buses are > >> DEVICE_CATEGORY_BRIDGE. Why is USB different? > > Again, we already have the bus information, I was looking for > > functional info. "USB" was not used here as a BUS, but like a > > standalone "function". > > Let me rephrase. Why do we have a category for devices bridging to a > USB bus (USB host controllers), but don't have categories for devices > bridging to other buses? > > Perhaps a possible answer is "because we have so many USB host > controllers, b
[Qemu-devel] [PATCH ] hw: Modified usb-tablet category from Misc to Input
Thanks to Markus Armbruster
for finding this bug.
Signed-off-by: Marcel Apfelbaum
---
hw/usb/dev-hid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/usb/dev-hid.c b/hw/usb/dev-hid.c
index 66c6331..5956720 100644
--- a/hw/usb/dev-hid.c
+++ b/hw/usb/dev-hid.c
@@ -658,7 +658,7 @@ static void usb_tablet_class_initfn(ObjectClass *klass,
void *data)
uc->product_desc = "QEMU USB Tablet";
dc->vmsd = &vmstate_usb_ptr;
dc->props = usb_tablet_properties;
-set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
}
static const TypeInfo usb_tablet_info = {
--
1.8.3.1
[Qemu-devel] [PATCH ] qemu-help: add category headlines
This patch follows Markus Armbruster suggestion:
A possibly better way to group help by category: instead of adding
categories to each line, add category headlines, like this:
Controller/Bridge/Hub devices:
name "NAME", bus "BUS"...
...
USB devices:
name "NAME", bus "BUS"...
...
Storage devices:
...
This way, showing devices with multiple categories once per category
actually makes sense.
Note that the "categories to each line" is kept for 2 reasons:
1. Preparation for multifunction devices
2. Ability to grep by category
Signed-off-by: Marcel Apfelbaum
---
qdev-monitor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/qdev-monitor.c b/qdev-monitor.c
index 410cdcb..a7329b0 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -156,6 +156,8 @@ static void qdev_print_category_devices(DeviceCategory
category)
DeviceClass *dc;
GSList *list, *curr;
+error_printf("%s devices:\n", qdev_category_get_name(category));
+
list = object_class_get_list(TYPE_DEVICE, false);
for (curr = list; curr; curr = g_slist_next(curr)) {
dc = (DeviceClass *)object_class_dynamic_cast(curr->data, TYPE_DEVICE);
--
1.8.3.1
[Qemu-devel] [PATCH v2] usb/dev-hid: Modified usb-tablet category from Misc to Input
usb-tablet device was wrongy assgined to Misc category
Reported-by: Markus Armbruster
Signed-off-by: Marcel Apfelbaum
Reviewed-by: Andreas Färber
---
Changes from v2:
- Add cc to qemu-stable and Gerd Hoffmann
- Changed subject prefix from hw to usb/dev-hid
hw/usb/dev-hid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/usb/dev-hid.c b/hw/usb/dev-hid.c
index 66c6331..5956720 100644
--- a/hw/usb/dev-hid.c
+++ b/hw/usb/dev-hid.c
@@ -658,7 +658,7 @@ static void usb_tablet_class_initfn(ObjectClass *klass,
void *data)
uc->product_desc = "QEMU USB Tablet";
dc->vmsd = &vmstate_usb_ptr;
dc->props = usb_tablet_properties;
-set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
}
static const TypeInfo usb_tablet_info = {
--
1.8.3.1
[Qemu-devel] [PATCH v3] usb/dev-hid: Modified usb-tablet category from Misc to Input
usb-tablet device was wrongly assigned to Misc category
Reported-by: Markus Armbruster
Signed-off-by: Marcel Apfelbaum
Reviewed-by: Andreas Färber
---
Changes from v2:
- Corrected spelling
Changes from v1:
- Add cc to qemu-stable and Gerd Hoffmann
- Changed subject prefix from hw to usb/dev-hid
hw/usb/dev-hid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/usb/dev-hid.c b/hw/usb/dev-hid.c
index 66c6331..5956720 100644
--- a/hw/usb/dev-hid.c
+++ b/hw/usb/dev-hid.c
@@ -658,7 +658,7 @@ static void usb_tablet_class_initfn(ObjectClass *klass,
void *data)
uc->product_desc = "QEMU USB Tablet";
dc->vmsd = &vmstate_usb_ptr;
dc->props = usb_tablet_properties;
-set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
}
static const TypeInfo usb_tablet_info = {
--
1.8.3.1
[Qemu-devel] [PATCH v4] usb/dev-hid: Modified usb-tablet category from Misc to Input
usb-tablet device was wrongly assigned to Misc category
Reported-by: Markus Armbruster
Cc: qemu-sta...@nongnu.org
Signed-off-by: Marcel Apfelbaum
Reviewed-by: Andreas Färber
---
Changes from v3:
- Added "Cc: qemu-sta...@nongnu.org" this time in the sign-off area ...
Changes from v2:
- Corrected spelling
Changes from v1:
- Add cc to qemu-stable and Gerd Hoffmann
- Changed subject prefix from hw to usb/dev-hid
hw/usb/dev-hid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/usb/dev-hid.c b/hw/usb/dev-hid.c
index 66c6331..5956720 100644
--- a/hw/usb/dev-hid.c
+++ b/hw/usb/dev-hid.c
@@ -658,7 +658,7 @@ static void usb_tablet_class_initfn(ObjectClass *klass,
void *data)
uc->product_desc = "QEMU USB Tablet";
dc->vmsd = &vmstate_usb_ptr;
dc->props = usb_tablet_properties;
-set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
}
static const TypeInfo usb_tablet_info = {
--
1.8.3.1
Re: [Qemu-devel] [PATCH ] qemu-help: add category headlines
On Thu, 2013-08-22 at 09:34 -0600, Eric Blake wrote:
> On 08/22/2013 08:13 AM, Markus Armbruster wrote:
>
> >>> +++ b/qdev-monitor.c
> >>> @@ -156,6 +156,8 @@ static void
> >>> qdev_print_category_devices(DeviceCategory category)
> >>> DeviceClass *dc;
> >>> GSList *list, *curr;
> >>>
> >>> +error_printf("%s devices:\n", qdev_category_get_name(category));
> >>
> >> Why is that an error? Shouldn't it go to stdout?
> >
> > Output of -device help has always gone to stderr, and that has always
> > annoyed me. Just not enough to fix it.
>
> Back when libvirt scraped -help output, changing it to use stdout would
> be an incompatible change. But now that libvirt uses QMP, I would also
> welcome a change to use stdout (but also fall in the category of "not
> enough of a bother for ME to fix it).
It really bothers me. I need to use the help (being new to qemu ...)
and I am always forgetting "2>&1".
Anyone can think of a reason for not sending the help to stdout?
Marcel
>
Re: [Qemu-devel] [PATCH ] qemu-help: add category headlines
On Thu, 2013-08-22 at 15:48 +0300, Marcel Apfelbaum wrote:
> This patch follows Markus Armbruster suggestion:
>
> A possibly better way to group help by category: instead of adding
> categories to each line, add category headlines, like this:
>
> Controller/Bridge/Hub devices:
> name "NAME", bus "BUS"...
> ...
> USB devices:
> name "NAME", bus "BUS"...
> ...
> Storage devices:
> ...
>
> This way, showing devices with multiple categories once per category
> actually makes sense.
>
> Note that the "categories to each line" is kept for 2 reasons:
> 1. Preparation for multifunction devices
> 2. Ability to grep by category
ping
Marcel
>
> Signed-off-by: Marcel Apfelbaum
> ---
> qdev-monitor.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/qdev-monitor.c b/qdev-monitor.c
> index 410cdcb..a7329b0 100644
> --- a/qdev-monitor.c
> +++ b/qdev-monitor.c
> @@ -156,6 +156,8 @@ static void qdev_print_category_devices(DeviceCategory
> category)
> DeviceClass *dc;
> GSList *list, *curr;
>
> +error_printf("%s devices:\n", qdev_category_get_name(category));
> +
> list = object_class_get_list(TYPE_DEVICE, false);
> for (curr = list; curr; curr = g_slist_next(curr)) {
> dc = (DeviceClass *)object_class_dynamic_cast(curr->data,
> TYPE_DEVICE);
Re: [Qemu-devel] [PATCH v4] usb/dev-hid: Modified usb-tablet category from Misc to Input
On Sun, 2013-08-25 at 13:23 +0300, Michael S. Tsirkin wrote:
> On Thu, Aug 22, 2013 at 08:11:36PM +0300, Marcel Apfelbaum wrote:
> > usb-tablet device was wrongly assigned to Misc category
> >
> > Reported-by: Markus Armbruster
> > Cc: qemu-sta...@nongnu.org
> > Signed-off-by: Marcel Apfelbaum
> > Reviewed-by: Andreas Färber
>
> Reviewed-by: Michael S. Tsirkin
pull? :)
Marcel
>
> > ---
> > Changes from v3:
> > - Added "Cc: qemu-sta...@nongnu.org" this time in the sign-off area ...
> > Changes from v2:
> > - Corrected spelling
> > Changes from v1:
> > - Add cc to qemu-stable and Gerd Hoffmann
> > - Changed subject prefix from hw to usb/dev-hid
> >
> > hw/usb/dev-hid.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hw/usb/dev-hid.c b/hw/usb/dev-hid.c
> > index 66c6331..5956720 100644
> > --- a/hw/usb/dev-hid.c
> > +++ b/hw/usb/dev-hid.c
> > @@ -658,7 +658,7 @@ static void usb_tablet_class_initfn(ObjectClass *klass,
> > void *data)
> > uc->product_desc = "QEMU USB Tablet";
> > dc->vmsd = &vmstate_usb_ptr;
> > dc->props = usb_tablet_properties;
> > -set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> > +set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > }
> >
> > static const TypeInfo usb_tablet_info = {
> > --
> > 1.8.3.1
[Qemu-devel] [PATCH RFC 1/3] memory: allow MemoryRegion's priority field to accept negative values
Priority is used to make visible some subregions by obscuring
the parent MemoryRegion addresses overlapping with the subregion.
By allowing the priority to be negative the opposite can be done:
Allow a subregion to be visible on all the addresses not covered
by the parent MemoryRegion or other subregions.
Signed-off-by: Marcel Apfelbaum
---
include/exec/memory.h | 6 +++---
memory.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index ebe0d24..6995087 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -153,7 +153,7 @@ struct MemoryRegion {
bool flush_coalesced_mmio;
MemoryRegion *alias;
hwaddr alias_offset;
-unsigned priority;
+int priority;
bool may_overlap;
QTAILQ_HEAD(subregions, MemoryRegion) subregions;
QTAILQ_ENTRY(MemoryRegion) subregions_link;
@@ -193,7 +193,7 @@ struct MemoryListener {
void (*coalesced_mmio_del)(MemoryListener *listener, MemoryRegionSection
*section,
hwaddr addr, hwaddr len);
/* Lower = earlier (during add), later (during del) */
-unsigned priority;
+int priority;
AddressSpace *address_space_filter;
QTAILQ_ENTRY(MemoryListener) link;
};
@@ -779,7 +779,7 @@ void memory_region_add_subregion(MemoryRegion *mr,
void memory_region_add_subregion_overlap(MemoryRegion *mr,
hwaddr offset,
MemoryRegion *subregion,
- unsigned priority);
+ int priority);
/**
* memory_region_get_ram_addr: Get the ram address associated with a memory
diff --git a/memory.c b/memory.c
index 886f838..dfb3ae6 100644
--- a/memory.c
+++ b/memory.c
@@ -1473,7 +1473,7 @@ void memory_region_add_subregion(MemoryRegion *mr,
void memory_region_add_subregion_overlap(MemoryRegion *mr,
hwaddr offset,
MemoryRegion *subregion,
- unsigned priority)
+ int priority)
{
subregion->may_overlap = true;
subregion->priority = priority;
--
1.8.3.1
[Qemu-devel] [PATCH RFC 3/3] hw/pci-host: catch acesses to unassigned pci addresses
Added a memory region that has negative priority and
extends over all the pci adddress space. This region will
"catch" all the accesses to the unassigned pci
addresses and it will be possible to emulate the
master abort scenario (When no device on the bus claims
the transaction).
Signed-off-by: Marcel Apfelbaum
---
hw/pci-host/piix.c| 8
hw/pci-host/q35.c | 19 ---
include/hw/pci-host/q35.h | 1 +
3 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index dc1718f..27b04a6 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -104,6 +104,7 @@ struct PCII440FXState {
MemoryRegion *ram_memory;
MemoryRegion pci_hole;
MemoryRegion pci_hole_64bit;
+MemoryRegion pci_unassigned_memory;
PAMMemoryRegion pam_regions[13];
MemoryRegion smram_region;
uint8_t smm_enabled;
@@ -347,6 +348,13 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
i440fx->pci_info.w32.begin = 0xe000;
}
+memory_region_init_io(&f->pci_unassigned_memory, OBJECT(d),
+ &pci_unassigned_mem_ops, d,
+ "pci-hole-unassigned", pci_hole_size);
+memory_region_add_subregion_overlap(f->pci_address_space, pci_hole_start,
+&f->pci_unassigned_memory,
+PCI_UNASSIGNED_MEM_PRIORITY);
+
memory_region_init_alias(&f->pci_hole, OBJECT(d), "pci-hole",
f->pci_address_space,
pci_hole_start, pci_hole_size);
memory_region_add_subregion(f->system_memory, pci_hole_start,
&f->pci_hole);
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 12314d8..ee4a4f9 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -320,13 +320,26 @@ static int mch_init(PCIDevice *d)
{
int i;
MCHPCIState *mch = MCH_PCI_DEVICE(d);
+hwaddr pci_hole_start;
+uint64_t pci_hole_size;
+
+pci_hole_start = mch->below_4g_mem_size;
+pci_hole_size = 0x1ULL - pci_hole_start;
+
+memory_region_init_io(&mch->pci_unassigned_memory, OBJECT(d),
+ &pci_unassigned_mem_ops, d,
+ "pci-hole-unassigned", pci_hole_size);
+memory_region_add_subregion_overlap(mch->pci_address_space, pci_hole_start,
+&mch->pci_unassigned_memory,
+PCI_UNASSIGNED_MEM_PRIORITY);
+
/* setup pci memory regions */
memory_region_init_alias(&mch->pci_hole, OBJECT(mch), "pci-hole",
mch->pci_address_space,
- mch->below_4g_mem_size,
- 0x1ULL - mch->below_4g_mem_size);
-memory_region_add_subregion(mch->system_memory, mch->below_4g_mem_size,
+ pci_hole_start,
+ pci_hole_size);
+memory_region_add_subregion(mch->system_memory, pci_hole_start,
&mch->pci_hole);
pc_init_pci64_hole(&mch->pci_info, 0x1ULL + mch->above_4g_mem_size,
diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index 6eb7ab6..c42fba3 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -55,6 +55,7 @@ typedef struct MCHPCIState {
MemoryRegion smram_region;
MemoryRegion pci_hole;
MemoryRegion pci_hole_64bit;
+MemoryRegion pci_unassigned_memory;
PcPciInfo pci_info;
uint8_t smm_enabled;
ram_addr_t below_4g_mem_size;
--
1.8.3.1
[Qemu-devel] [PATCH RFC 2/3] hw/pci: add MemoryRegion ops for unassigned pci addresses
The MemoryRegions assigned with this ops shall "intercept"
the accesses to unassigned pci address space and the
associated callback will set MASTER ABORT bit in the
STATUS register of the device that initiated the
transaction as defined in PCI spec.
Note: This implementation assumes that all the reads/writes to
the pci address space are done by the cpu.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pci.c | 18 ++
include/hw/pci/pci.h | 3 +++
2 files changed, 21 insertions(+)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 4c004f5..f0289fc 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2229,6 +2229,24 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
return dev->bus->address_space_io;
}
+static bool pci_unassigned_mem_accepts(void *opaque, hwaddr addr,
+ unsigned size, bool is_write)
+{
+PCIDevice *d = opaque;
+
+/* FIXME assumption: the cpu initiated the pci transaction
+ * and not another pci device */
+pci_word_test_and_set_mask(d->config + PCI_STATUS,
+ PCI_STATUS_REC_MASTER_ABORT);
+
+return false;
+}
+
+const MemoryRegionOps pci_unassigned_mem_ops = {
+.valid.accepts = pci_unassigned_mem_accepts,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
static void pci_device_class_init(ObjectClass *klass, void *data)
{
DeviceClass *k = DEVICE_CLASS(klass);
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index ccec2ba..854681c 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -329,6 +329,9 @@ int pci_device_load(PCIDevice *s, QEMUFile *f);
MemoryRegion *pci_address_space(PCIDevice *dev);
MemoryRegion *pci_address_space_io(PCIDevice *dev);
+#define PCI_UNASSIGNED_MEM_PRIORITY -1
+extern const MemoryRegionOps pci_unassigned_mem_ops;
+
typedef void (*pci_set_irq_fn)(void *opaque, int irq_num, int level);
typedef int (*pci_map_irq_fn)(PCIDevice *pci_dev, int irq_num);
typedef PCIINTxRoute (*pci_route_irq_fn)(void *opaque, int pin);
--
1.8.3.1
[Qemu-devel] [PATCH RFC 0/3] pci: complete master abort protocol
Note: The series is incomplete, for review only PCI spec requires that a transaction that has not been claimed by any PCI bus devices will be terminated by the initiator with "master abort". For read transactions -1() is returned and writes are silently dropped. (already implemented in quemu) The series deals with the other aspect of the master abort scenario: Upon completion the master has to raise MASTER ABORT BIT in i initiator's STATUS register. Implementation: Allowed the MemoryRegion priority to be negative so a subregion will be visible on all the addresses not covered by the parent MemoryRegion or other subregions. Added a memory region with negative priority that extends over all the pci address space. This region catches all the accesses to the unassigned pci addresses. The MeomoryRegion's ops callbacks emulate the master abort scenario. Note: For the moment the code assumes that all the reads/writes on pci address space are done by the cpu. Marcel Apfelbaum (3): memory: allow MemoryRegion's priority field to accept negative values hw/pci: add MemoryRegion ops for unassigned pci addresses hw/pci-host: catch acesses to unassigned pci addresses hw/pci-host/piix.c| 8 hw/pci-host/q35.c | 19 --- hw/pci/pci.c | 18 ++ include/exec/memory.h | 6 +++--- include/hw/pci-host/q35.h | 1 + include/hw/pci/pci.h | 3 +++ memory.c | 2 +- 7 files changed, 50 insertions(+), 7 deletions(-) -- 1.8.3.1
Re: [Qemu-devel] [PATCH RFC 0/3] pci: complete master abort protocol
On Mon, 2013-09-02 at 15:30 +0100, Peter Maydell wrote: > On 2 September 2013 15:13, Marcel Apfelbaum wrote: > > Note: The series is incomplete, for review only > > > > PCI spec requires that a transaction that has not been claimed > > by any PCI bus devices will be terminated by the initiator > > with "master abort". For read transactions -1() is returned and > > writes are silently dropped. (already implemented in quemu) > > ...but only erroneously and by breaking a pile of other boards. :( Let's find a way to fix it... Please suggest > > > Note: > > For the moment the code assumes that all the reads/writes on > > pci address space are done by the cpu. > > This is a bogus assumption in the presence of bus mastering > PCI devices, which aren't exactly uncommon. As I said, the series is work in progress. Tracking down the real initiator of a read/write to the pci address space seems to be difficult. I am looking into it and opened to suggestions. Marcel > > -- PMM >
Re: [Qemu-devel] [PATCH RFC 1/3] memory: allow MemoryRegion's priority field to accept negative values
On Mon, 2013-09-02 at 15:38 +0100, Peter Maydell wrote:
> On 2 September 2013 15:13, Marcel Apfelbaum wrote:
> > Priority is used to make visible some subregions by obscuring
> > the parent MemoryRegion addresses overlapping with the subregion.
> >
> > By allowing the priority to be negative the opposite can be done:
> > Allow a subregion to be visible on all the addresses not covered
> > by the parent MemoryRegion or other subregions.
>
> This comment is not exactly accurate. Allowing priority to
> be signed is just a convenience: you can achieve exactly
> the same effect by specifying some positive priority for
> everything you map into the region and having the background
> region be priority zero. (If you care at all about priorities
> then everything being mapped into the region should be
> happening under the control of your code anyway.)
It seems (to me) that having the default priority 0 and
expanding on both directions depending on what you want to achieve
is an elegant solution. That being said, what you proposed would work too.
>
> > Signed-off-by: Marcel Apfelbaum
> > ---
> > include/exec/memory.h | 6 +++---
> > memory.c | 2 +-
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/exec/memory.h b/include/exec/memory.h
> > index ebe0d24..6995087 100644
> > --- a/include/exec/memory.h
> > +++ b/include/exec/memory.h
> > @@ -153,7 +153,7 @@ struct MemoryRegion {
> > bool flush_coalesced_mmio;
> > MemoryRegion *alias;
> > hwaddr alias_offset;
> > -unsigned priority;
> > +int priority;
> > bool may_overlap;
> > QTAILQ_HEAD(subregions, MemoryRegion) subregions;
> > QTAILQ_ENTRY(MemoryRegion) subregions_link;
> > @@ -193,7 +193,7 @@ struct MemoryListener {
> > void (*coalesced_mmio_del)(MemoryListener *listener,
> > MemoryRegionSection *section,
> > hwaddr addr, hwaddr len);
> > /* Lower = earlier (during add), later (during del) */
> > -unsigned priority;
> > +int priority;
>
> This is unrelated to MemoryRegion priorities -- it controls the
> order in which listener callbacks are called. Don't try to change
> both at once (and you only need the MR priorities anyway.)
I found that one :). I didn't updated the patches, thanks anyway
Marcel
>
> > AddressSpace *address_space_filter;
> > QTAILQ_ENTRY(MemoryListener) link;
> > };
> > @@ -779,7 +779,7 @@ void memory_region_add_subregion(MemoryRegion *mr,
> > void memory_region_add_subregion_overlap(MemoryRegion *mr,
> > hwaddr offset,
> > MemoryRegion *subregion,
> > - unsigned priority);
> > + int priority);
> >
> > /**
> > * memory_region_get_ram_addr: Get the ram address associated with a memory
> > diff --git a/memory.c b/memory.c
> > index 886f838..dfb3ae6 100644
> > --- a/memory.c
> > +++ b/memory.c
> > @@ -1473,7 +1473,7 @@ void memory_region_add_subregion(MemoryRegion *mr,
> > void memory_region_add_subregion_overlap(MemoryRegion *mr,
> > hwaddr offset,
> > MemoryRegion *subregion,
> > - unsigned priority)
> > + int priority)
> > {
> > subregion->may_overlap = true;
> > subregion->priority = priority;
>
> This isn't a complete set of changes. For instance
> memory_region_set_address() has a local variable 'priority'
> which should be signed now.
>
> sysbus_mmio_map_common() and sysbus_mmio_map_overlap()
> have priority arguments which need to change to match.
>
> thanks
> -- PMM
>
Re: [Qemu-devel] [PATCH RFC 2/3] hw/pci: add MemoryRegion ops for unassigned pci addresses
On Mon, 2013-09-02 at 17:48 +0300, Michael S. Tsirkin wrote:
> On Mon, Sep 02, 2013 at 05:13:08PM +0300, Marcel Apfelbaum wrote:
> > The MemoryRegions assigned with this ops shall "intercept"
> > the accesses to unassigned pci address space and the
> > associated callback will set MASTER ABORT bit in the
> > STATUS register of the device that initiated the
> > transaction as defined in PCI spec.
> >
> > Note: This implementation assumes that all the reads/writes to
> > the pci address space are done by the cpu.
> >
> > Signed-off-by: Marcel Apfelbaum
> > ---
> > hw/pci/pci.c | 18 ++
> > include/hw/pci/pci.h | 3 +++
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index 4c004f5..f0289fc 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -2229,6 +2229,24 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
> > return dev->bus->address_space_io;
> > }
> >
> > +static bool pci_unassigned_mem_accepts(void *opaque, hwaddr addr,
> > + unsigned size, bool is_write)
> > +{
> > +PCIDevice *d = opaque;
> > +
> > +/* FIXME assumption: the cpu initiated the pci transaction
> > + * and not another pci device */
>
> /*
> * Multiline
> * comments
> */
Got it. Thanks!
Marcel
>
>
> > +pci_word_test_and_set_mask(d->config + PCI_STATUS,
> > + PCI_STATUS_REC_MASTER_ABORT);
> > +
> > +return false;
> > +}
> > +
> > +const MemoryRegionOps pci_unassigned_mem_ops = {
> > +.valid.accepts = pci_unassigned_mem_accepts,
> > +.endianness = DEVICE_NATIVE_ENDIAN,
> > +};
> > +
> > static void pci_device_class_init(ObjectClass *klass, void *data)
> > {
> > DeviceClass *k = DEVICE_CLASS(klass);
> > diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> > index ccec2ba..854681c 100644
> > --- a/include/hw/pci/pci.h
> > +++ b/include/hw/pci/pci.h
> > @@ -329,6 +329,9 @@ int pci_device_load(PCIDevice *s, QEMUFile *f);
> > MemoryRegion *pci_address_space(PCIDevice *dev);
> > MemoryRegion *pci_address_space_io(PCIDevice *dev);
> >
> > +#define PCI_UNASSIGNED_MEM_PRIORITY -1
> > +extern const MemoryRegionOps pci_unassigned_mem_ops;
> > +
> > typedef void (*pci_set_irq_fn)(void *opaque, int irq_num, int level);
> > typedef int (*pci_map_irq_fn)(PCIDevice *pci_dev, int irq_num);
> > typedef PCIINTxRoute (*pci_route_irq_fn)(void *opaque, int pin);
> > --
> > 1.8.3.1
>
Re: [Qemu-devel] [PATCH RFC 3/3] hw/pci-host: catch acesses to unassigned pci addresses
On Mon, 2013-09-02 at 15:39 +0100, Peter Maydell wrote: > On 2 September 2013 15:13, Marcel Apfelbaum wrote: > > Added a memory region that has negative priority and > > extends over all the pci adddress space. This region will > > "catch" all the accesses to the unassigned pci > > addresses and it will be possible to emulate the > > master abort scenario (When no device on the bus claims > > the transaction). > > > > Signed-off-by: Marcel Apfelbaum > > --- > > hw/pci-host/piix.c| 8 > > hw/pci-host/q35.c | 19 --- > > include/hw/pci-host/q35.h | 1 + > > This is happening at the wrong layer -- you want this memory > region to be created and managed in the PCI core code so that > we get correct PCI-spec behaviour for all our PCI controllers, > not just the two x86 ones you've changed here.pci_address_space I saw that the memory regions are part of the Host state and duplicated for each host type(like pci_address_space). Question, why are not pci_address_space and pci_hole present in a core layer? I followed the existing code; from what you are saying I understand that also the existing memory regions like the one mentioned above should be moved in the core layer, right? Marcel > > -- PMM >
Re: [Qemu-devel] [PATCH RFC 2/3] hw/pci: add MemoryRegion ops for unassigned pci addresses
On Mon, 2013-09-02 at 15:42 +0100, Peter Maydell wrote:
> On 2 September 2013 15:13, Marcel Apfelbaum wrote:
> > +const MemoryRegionOps pci_unassigned_mem_ops = {
> > +.valid.accepts = pci_unassigned_mem_accepts,
> > +.endianness = DEVICE_NATIVE_ENDIAN,
> > +};
>
> This is wrong -- you want reads and writes to result in
> your PCI-spec-defined behaviour, but if you provide
> an accepts callback and it returns false then you get
> "machine dependent behaviour such as a machine check
> exception". What you want is to provide .read and .write
> callbacks which behave as the PCI spec mandates.
That makes sense. It was already a bug.Thanks!
>
> Also this should probably be static, not global, and you
If it will be implemented in the "pci core layer", sure
Marcel
> should put it in the same patch as the one which actually
> creates the memory region.
>
> -- PMM
>
Re: [Qemu-devel] [PATCH RFC 0/3] pci: complete master abort protocol
On Mon, 2013-09-02 at 15:43 +0100, Peter Maydell wrote: > On 2 September 2013 15:39, Marcel Apfelbaum wrote: > > On Mon, 2013-09-02 at 15:30 +0100, Peter Maydell wrote: > >> On 2 September 2013 15:13, Marcel Apfelbaum wrote: > >> > Note: The series is incomplete, for review only > >> > > >> > PCI spec requires that a transaction that has not been claimed > >> > by any PCI bus devices will be terminated by the initiator > >> > with "master abort". For read transactions -1() is returned and > >> > writes are silently dropped. (already implemented in quemu) > >> > >> ...but only erroneously and by breaking a pile of other boards. > > :( > > Let's find a way to fix it... Please suggest > > We need to apply Jan's two patches which revert the breakage > and give us back 1.5 behaviour for unassigned memory. > Then you can work on this patchset and we can commit it > when it works OK. I am going to have a look on those patches, thanks Marcel > > -- PMM >
Re: [Qemu-devel] [PATCH RFC 3/3] hw/pci-host: catch acesses to unassigned pci addresses
On Mon, 2013-09-02 at 16:53 +0100, Peter Maydell wrote: > On 2 September 2013 16:42, Marcel Apfelbaum wrote: > > On Mon, 2013-09-02 at 15:39 +0100, Peter Maydell wrote: > >> This is happening at the wrong layer -- you want this memory > >> region to be created and managed in the PCI core code so that > >> we get correct PCI-spec behaviour for all our PCI controllers, > >> not just the two x86 ones you've changed here.pci_address_space > > I saw that the memory regions are part of the Host state and > > duplicated for each host type(like pci_address_space). > > Question, why are not pci_address_space and pci_hole present > > in a core layer? > > > > I followed the existing code; from what you are saying > > I understand that also the existing memory regions > > like the one mentioned above should be moved in > > the core layer, right? > > Ideally, yes, I think so. However that's not particularly > a requirement for the changes you're trying to make here: > at the moment what happens is that the pci controller > creates the PCI memory and io memory regions (or cheats > by reusing the system memory space[*]), passes them to > the PCI core code (via pci_bus_new) and then they're > the PCI code's responsibility to manage. So in the PCI > code you can ignore where they came from when you're > deciding how to manage these containers (and in this case > what you do is just create your default region and map > it in to the container at a suitable priority). Thanks, I am going to follow this path Marcel > [*] I'm pretty sure this is a bug in all platforms that do it. > > -- PMM >
Re: [Qemu-devel] [RFC v2 2/3] Add units-per-idebus property
On Fri, 2014-09-19 at 11:39 +0200, Markus Armbruster wrote:
> John Snow writes:
>
> > Signed-off-by: John Snow
> > ---
> > blockdev.c| 10 --
> > device-hotplug.c | 2 +-
> > hw/i386/pc_q35.c | 3 ++-
> > include/hw/boards.h | 3 ++-
> > include/sysemu/blockdev.h | 2 +-
> > vl.c | 19 +++
> > 6 files changed, 25 insertions(+), 14 deletions(-)
> >
> > diff --git a/blockdev.c b/blockdev.c
> > index 5e7c93a..6c524b7 100644
> > --- a/blockdev.c
> > +++ b/blockdev.c
> > @@ -45,6 +45,7 @@
> > #include "qmp-commands.h"
> > #include "trace.h"
> > #include "sysemu/arch_init.h"
> > +#include "hw/boards.h"
> >
> > static QTAILQ_HEAD(drivelist, DriveInfo) drives =
> > QTAILQ_HEAD_INITIALIZER(drives);
> >
> > @@ -643,7 +644,7 @@ QemuOptsList qemu_legacy_drive_opts = {
> > },
> > };
> >
> > -DriveInfo *drive_new(QemuOpts *all_opts, BlockInterfaceType
> > block_default_type)
> > +DriveInfo *drive_new(QemuOpts *all_opts, MachineClass *mc)
> > {
> > const char *value;
> > DriveInfo *dinfo = NULL;
> > @@ -651,6 +652,7 @@ DriveInfo *drive_new(QemuOpts *all_opts,
> > BlockInterfaceType block_default_type)
> > QemuOpts *legacy_opts;
> > DriveMediaType media = MEDIA_DISK;
> > BlockInterfaceType type;
> > +BlockInterfaceType block_default_type = mc->block_default_type;
> > int cyls, heads, secs, translation;
> > int max_devs, bus_id, unit_id, index;
> > const char *devaddr;
> > @@ -828,7 +830,11 @@ DriveInfo *drive_new(QemuOpts *all_opts,
> > BlockInterfaceType block_default_type)
> > unit_id = qemu_opt_get_number(legacy_opts, "unit", -1);
> > index = qemu_opt_get_number(legacy_opts, "index", -1);
> >
> > -max_devs = if_max_devs[type];
> > +if (type == IF_IDE && mc->units_per_idebus) {
> > +max_devs = mc->units_per_idebus;
> > +} else {
> > +max_devs = if_max_devs[type];
> > +}
>
> This overrides if_max_devs[IF_IDE] in one out of three places.
>
> if_max_devs[type] governs the mapping between index and (bus, unit).
>
> If it's zero, then (bus, unit) = (0, index).
>
> Else, (bus, unit) = (index / max_devs, index % max_devs).
>
> Overriding it just here affects these things:
>
> * Picking a default when the user specifies neither index nor unit
>
> * Range checking unit
>
> * Default ID, but let's ignore that for now
>
> It does *not* affect drive_index_to_bus_id(), drive_index_to_unit_id(),
> i.e. the actual mapping between index and (bus, unit)! index=1 is still
> mapped to (bus, unit) = (0, 1). No good.
>
> Testing (needs an incremental fix, see below) confirms:
>
> qemu: -drive if=ide,media=cdrom,index=1: unit 1 too big (max is 0)
>
> You have to override if_max_devs[] consistently.
>
> You provide for overriding if_max_devs[IF_IDE] only. It'll do for now.
>
> >
> > if (index != -1) {
> > if (bus_id != 0 || unit_id != -1) {
> > diff --git a/device-hotplug.c b/device-hotplug.c
> > index e6a1ffb..857ac53 100644
> > --- a/device-hotplug.c
> > +++ b/device-hotplug.c
> > @@ -40,7 +40,7 @@ DriveInfo *add_init_drive(const char *optstr)
> > return NULL;
> >
> > mc = MACHINE_GET_CLASS(current_machine);
> > -dinfo = drive_new(opts, mc->block_default_type);
> > +dinfo = drive_new(opts, mc);
> > if (!dinfo) {
> > qemu_opts_del(opts);
> > return NULL;
> > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> > index d4a907c..fd26fe1 100644
> > --- a/hw/i386/pc_q35.c
> > +++ b/hw/i386/pc_q35.c
> > @@ -348,7 +348,8 @@ static void pc_q35_init_1_4(MachineState *machine)
> >
> > #define PC_Q35_2_2_MACHINE_OPTIONS \
> > PC_Q35_MACHINE_OPTIONS, \
> > -.default_machine_opts = "firmware=bios-256k.bin"
> > +.default_machine_opts = "firmware=bios-256k.bin", \
> > +.units_per_idebus = 1
> >
>
> I figrue this keeps -drive if=ide for older Q35 machines compatibly
> broken. If that's what we want to do...
>
> > static QEMUMachine pc_q35_machine_v2_2 = {
> > PC_Q35_2_2_MACHINE_OPTIONS,
> > diff --git a/include/hw/boards.h b/include/hw/boards.h
> > index dfb6718..73e656f 100644
> > --- a/include/hw/boards.h
> > +++ b/include/hw/boards.h
> > @@ -37,6 +37,7 @@ struct QEMUMachine {
> > no_cdrom:1,
> > no_sdcard:1;
> > int is_default;
> > +unsigned short units_per_idebus;
> > const char *default_machine_opts;
> > const char *default_boot_order;
> > GlobalProperty *compat_props;
>
> if_max_devs[] and the max_devs variables are all int. I'd rather not
> mix signed and unsigned without need
>
> > @@ -95,11 +96,11 @@ struct MachineClass {
> > no_cdrom:1,
> > no_sdcard:1;
> > int is_default;
> > +unsigned short units_per_idebus;
> > const char *default_machine_opts;
> > const char *default_boot_order;
> > GlobalPropert
Re: [Qemu-devel] [PATCH 2/2] machine_parse(): list supported machine types in their registration order
On Mon, 2014-09-22 at 15:36 +0300, Michael S. Tsirkin wrote: > On Mon, Sep 22, 2014 at 02:29:08PM +0200, Laszlo Ersek wrote: > > On 09/22/14 14:04, Andreas Färber wrote: > > > Am 22.09.2014 um 13:26 schrieb Laszlo Ersek: > > >> Based on the registration order captured in the previous patch, we > > >> sort the ad-hoc list printed for > > >> > > >> qemu-system- -M \? > > > > > > Agree that the order is worth sanitizing. I would however argue that > > > registration order is not entirely stable either if you think of > > > non-PC cases where there's dozens of source files registering one > > > machine each. I would therefore propose alphabetical order as we do > > > for QOM'ified CPUs. > > > > I did mention alphabetical order in the message of patch #1 -- in fact > > that was what I implemented first: > > > > > The first idea to restore ordering is to sort the ad-hoc list in > > > machine_parse() by "MachineClass.name". Such a name-based ordering > > > would have to be reverse, so that more recent versioned machine types > > > appear higher on the list than older versioned machine types (eg. with > > > qemu-system-x86_64). However, such a reverse sort wreaks havoc between > > > non-versioned machine types (such as those of qemu-system-aarch64). > > > > Simply put, it looks very ugly. Namely, if you sort it in alphabetically > > *ascending* order, then for the x86_64 target, you get: > > > > > isapcISA-only PC > > > none empty machine > > > pc Standard PC (i440FX + PIIX, 1996) (alias of > > > pc-i440fx-2.2) > > > pc-0.10 Standard PC (i440FX + PIIX, 1996) > > > pc-0.11 Standard PC (i440FX + PIIX, 1996) > > > pc-0.12 Standard PC (i440FX + PIIX, 1996) > > > pc-0.13 Standard PC (i440FX + PIIX, 1996) > > > pc-0.14 Standard PC (i440FX + PIIX, 1996) > > > pc-0.15 Standard PC (i440FX + PIIX, 1996) > > > pc-1.0 Standard PC (i440FX + PIIX, 1996) > > > pc-1.1 Standard PC (i440FX + PIIX, 1996) > > > pc-1.2 Standard PC (i440FX + PIIX, 1996) > > > pc-1.3 Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-1.4Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-1.5Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-1.6Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-1.7Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-2.0Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-2.1Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-2.2Standard PC (i440FX + PIIX, 1996) (default) > > > pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-1.5 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-1.6 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-1.7 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-2.0 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-2.1 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-2.2 Standard PC (Q35 + ICH9, 2009) > > > q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.2) > > > > which is very bad / unusual. Okay, so let's sort it in alphabetically > > descending order: > > > > > q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.2) > > > pc-q35-2.2 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-2.1 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-2.0 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-1.7 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-1.6 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-1.5 Standard PC (Q35 + ICH9, 2009) > > > pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) > > > pc-i440fx-2.2Standard PC (i440FX + PIIX, 1996) (default) > > > pc-i440fx-2.1Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-2.0Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-1.7Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-1.6Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-1.5Standard PC (i440FX + PIIX, 1996) > > > pc-i440fx-1.4Standard PC (i440FX + PIIX, 1996) > > > pc-1.3 Standard PC (i440FX + PIIX, 1996) > > > pc-1.2 Standard PC (i440FX + PIIX, 1996) > > > pc-1.1 Standard PC (i440FX + PIIX, 1996) > > > pc-1.0 Standard PC (i440FX + PIIX, 1996) > > > pc-0.15 Standard PC (i440FX + PIIX, 1996) > > > pc-0.14 Standard PC (i440FX + PIIX, 1996) > > > pc-0.13 Standard PC (i440FX + PIIX, 1996) > > > pc-0.12 Standard PC (i440FX + PIIX, 1996) > > > pc-0.11 Standard PC (i440FX + PIIX, 1996) > > > pc-0.10 Standard PC (i440FX + PIIX, 1996) > > > pc Standard PC (i440FX + PIIX, 1996) (alias of > > > pc-i440fx-2.2) > > > none empty machine > > > isapcISA-only PC > > > > Okay, this is certainly bearable. However, let's see wh
Re: [Qemu-devel] [PATCH 2/2] machine_parse(): list supported machine types in their registration order
On Mon, 2014-09-22 at 15:43 +0200, Laszlo Ersek wrote: > On 09/22/14 14:50, Marcel Apfelbaum wrote: > > On Mon, 2014-09-22 at 15:36 +0300, Michael S. Tsirkin wrote: > >> On Mon, Sep 22, 2014 at 02:29:08PM +0200, Laszlo Ersek wrote: > >>> On 09/22/14 14:04, Andreas Färber wrote: > >>>> Am 22.09.2014 um 13:26 schrieb Laszlo Ersek: > >>>>> Based on the registration order captured in the previous patch, we > >>>>> sort the ad-hoc list printed for > >>>>> > >>>>> qemu-system- -M \? > >>>> > >>>> Agree that the order is worth sanitizing. I would however argue that > >>>> registration order is not entirely stable either if you think of > >>>> non-PC cases where there's dozens of source files registering one > >>>> machine each. I would therefore propose alphabetical order as we do > >>>> for QOM'ified CPUs. > >>> > >>> I did mention alphabetical order in the message of patch #1 -- in fact > >>> that was what I implemented first: > >>> > >>>> The first idea to restore ordering is to sort the ad-hoc list in > >>>> machine_parse() by "MachineClass.name". Such a name-based ordering > >>>> would have to be reverse, so that more recent versioned machine types > >>>> appear higher on the list than older versioned machine types (eg. with > >>>> qemu-system-x86_64). However, such a reverse sort wreaks havoc between > >>>> non-versioned machine types (such as those of qemu-system-aarch64). > >>> > >>> Simply put, it looks very ugly. Namely, if you sort it in alphabetically > >>> *ascending* order, then for the x86_64 target, you get: > >>> > >>>> isapcISA-only PC > >>>> none empty machine > >>>> pc Standard PC (i440FX + PIIX, 1996) (alias of > >>>> pc-i440fx-2.2) > >>>> pc-0.10 Standard PC (i440FX + PIIX, 1996) > >>>> pc-0.11 Standard PC (i440FX + PIIX, 1996) > >>>> pc-0.12 Standard PC (i440FX + PIIX, 1996) > >>>> pc-0.13 Standard PC (i440FX + PIIX, 1996) > >>>> pc-0.14 Standard PC (i440FX + PIIX, 1996) > >>>> pc-0.15 Standard PC (i440FX + PIIX, 1996) > >>>> pc-1.0 Standard PC (i440FX + PIIX, 1996) > >>>> pc-1.1 Standard PC (i440FX + PIIX, 1996) > >>>> pc-1.2 Standard PC (i440FX + PIIX, 1996) > >>>> pc-1.3 Standard PC (i440FX + PIIX, 1996) > >>>> pc-i440fx-1.4Standard PC (i440FX + PIIX, 1996) > >>>> pc-i440fx-1.5Standard PC (i440FX + PIIX, 1996) > >>>> pc-i440fx-1.6Standard PC (i440FX + PIIX, 1996) > >>>> pc-i440fx-1.7Standard PC (i440FX + PIIX, 1996) > >>>> pc-i440fx-2.0Standard PC (i440FX + PIIX, 1996) > >>>> pc-i440fx-2.1Standard PC (i440FX + PIIX, 1996) > >>>> pc-i440fx-2.2Standard PC (i440FX + PIIX, 1996) (default) > >>>> pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-1.5 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-1.6 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-1.7 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-2.0 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-2.1 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-2.2 Standard PC (Q35 + ICH9, 2009) > >>>> q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.2) > >>> > >>> which is very bad / unusual. Okay, so let's sort it in alphabetically > >>> descending order: > >>> > >>>> q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.2) > >>>> pc-q35-2.2 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-2.1 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-2.0 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-1.7 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-1.6 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-1.5 Standard PC (Q35 + ICH9, 2009) > >>>> pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) > >>>> pc-i440fx-2.2Standard PC (i440FX + PIIX, 1996) (d
Re: [Qemu-devel] [PATCH v2 0/2] list supported machine types in well-defined order
On Mon, 2014-09-22 at 22:38 +0200, Laszlo Ersek wrote: > The first patch introduces a generic comparator. This comparator should > cover all machine types at once that don't belong to machine type > "families". Hence, for example, the output it produces for > > qemu-system-aarch64 -M \? > > is meant to be final. (See examples in the patches.) > > The second patch files piix and q35 machine types into their respective > families. > > Paolo said we needed to care about "pseries, pc, q35", but I got no clue > about "pseries", so I didn't touch that. It shouldn't be hard for > someone who knows "pseries" to post a followup patch that covers it. > Until then, "pseries" machine types are listed in alphabetical order (no > families). > > Laszlo Ersek (2): > well-defined listing order for machine types > i386/pc: add piix and q35 machtypes to sorting families for -M \? > > include/hw/boards.h | 2 ++ > hw/i386/pc.c| 1 + > hw/i386/pc_piix.c | 1 + > hw/i386/pc_q35.c| 1 + > vl.c | 38 +- > 5 files changed, 42 insertions(+), 1 deletion(-) > Looks good to me. Reviewed-by: Marcel Apfelbaum Discussion only: 1. Adding the family field to machine options mechanism does leverage the machines hierarchy, but in another way and not through QOM. 2. The compare function looks exactly as I thought it would, my only difference was to take it a little further by let the family itself to sort its machines, but *is completely unnecessary* for this purpose. Your solution has a small footprint and I like it. Thanks, Marcel
Re: [Qemu-devel] [PATCH v4 2/3] pcie: add check for ari capability of pcie devices
On Wed, 2014-10-01 at 07:26 +0200, Knut Omang wrote:
> On Tue, 2014-09-30 at 21:38 +0800, Gonglei wrote:
> > > Subject: Re: [Qemu-devel] [PATCH v4 2/3] pcie: add check for ari
> > > capability of
> > > pcie devices
> > >
> > > On Tue, Sep 30, 2014 at 06:11:25PM +0800, arei.gong...@huawei.com wrote:
> > > > From: Gonglei
> > > >
> > > > In QEMU, ARI Forwarding is enabled default at emulation of PCIe
> > > > ports. ARI Forwarding enable setting at firmware/OS Control handoff.
> > > > If the bit is Set when a non-ARI Device is present, the non-ARI
> > > > Device can respond to Configuration Space accesses under what it
> > > > interprets as being different Device Numbers, and its Functions can
> > > > be aliased under multiple Device Numbers, generally leading to
> > > > undesired behavior.
> > >
> > > So what is the undesired behaviour?
> > > Did you observe such?
> >
> > I just observe the PCI device don't work, and the dmesg show me:
> >
> > [ 159.035250] pciehp :05:00.0:pcie24: Button pressed on Slot (0 - 4)
> > [ 159.035274] pciehp :05:00.0:pcie24: Card present on Slot (0 - 4)
> > [ 159.036517] pciehp :05:00.0:pcie24: PCI slot #0 - 4 - powering on due
> > to button press.
> > [ 159.188049] pciehp :05:00.0:pcie24: Failed to check link status
> > [ 159.201968] pciehp :05:00.0:pcie24: Card not present on Slot (0 - 4)
> > [ 159.202529] pciehp :05:00.0:pcie24: Already disabled on Slot (0 - 4)
>
> This seems very much like the symptoms I see when I use hotplug after
> the latest changes to the hotplug code - do you have something that
> confirms this has something to do with wrong interpretation of device
> IDs? My suspicion is that something has gone wrong or is missing in the
> hotplug logic but I havent had time to dig deeper into it yet.
Can you please describe me the steps to reproduce the issue?
It should work correctly by now, maybe a "surprise removal/addition"
warning and nothing more.
Thank you,
Marcel
>
> I am just concerned that this might alleviate the symptoms you see but
> not fix the problem itself,
>
> Knut
>
> > > Please make this explicit in the commit log.
> > >
> > Sorry, I copied the description from PCIe spec. :(
> >
> > IMPLEMENTATION NOTE at Page 19:
> >
> > https://www.pcisig.com/specifications/pciexpress/specifications/ECN-alt-rid-interpretation-070604.pdf
> >
> >
> > >
> > > >
> > > > So, for PCI devices attached in PCIe root ports or downstream pots,
> > > > we should assure that its slot is not non-zero. For PCIe devices, which
> > > > ARP capability is not enabled, we also should assure that its slot
> > > > is not non-zero.
> > >
> > > not non zero => zero
> > >
> > OK.
> >
> > > >
> > > > Signed-off-by: Gonglei
> > > > ---
> > > > hw/pci/pci.c | 4
> > > > hw/pci/pcie.c | 51
> > > +++
> > > > include/hw/pci/pcie.h | 1 +
> > > > 3 files changed, 56 insertions(+)
> > > >
> > > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > > index 6ce75aa..22b7ca0 100644
> > > > --- a/hw/pci/pci.c
> > > > +++ b/hw/pci/pci.c
> > > > @@ -1770,6 +1770,10 @@ static int pci_qdev_init(DeviceState *qdev)
> > > > }
> > > > }
> > > >
> > > > +if (pcie_cap_slot_check(bus, pci_dev)) {
> > > > +return -1;
> > > > +}
> > > > +
> > > > /* rom loading */
> > > > is_default_rom = false;
> > > > if (pci_dev->romfile == NULL && pc->romfile != NULL) {
> > > > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > > > index 1babddf..b82211a 100644
> > > > --- a/hw/pci/pcie.c
> > > > +++ b/hw/pci/pcie.c
> > > > @@ -633,3 +633,54 @@ void pcie_ari_init(PCIDevice *dev, uint16_t offset,
> > > uint16_t nextfn)
> > > > offset, PCI_ARI_SIZEOF);
> > > > pci_set_long(dev->config + offset + PCI_ARI_CAP, (nextfn & 0xff)
> > > > << 8);
> > > > }
> > > > +
> > > > +int pcie_cap_slot_check(PCIBus *bus, PCIDevice *dev)
> > > > +{
> > > > +Object *obj = OBJECT(bus);
> > > > +
> > > > +if (pci_bus_is_root(bus)) {
> > > > +return 0;
> > > > +}
> > > > +
> > > > +if (object_dynamic_cast(obj, TYPE_PCIE_BUS)) {
> > > > +DeviceState *parent = qbus_get_parent(BUS(obj));
> > > > +PCIDevice *pci_dev = PCI_DEVICE(parent);
> > > > +uint8_t port_type;
> > > > +/*
> > > > + * Root ports and downstream ports of switches are the hot
> > > > + * pluggable ports in a PCI Express hierarchy.
> > > > + * PCI Express supports chip-to-chip interconnect, a PCIe link
> > > > can
> > > > + * only connect one PCI device/Switch/EndPoint or PCI-bridge.
> > > > + *
> > > > + * 7.3. Configuration Transaction Rules (PCI Express
> > > > specification
> > > 3.0)
> > > > + * 7.3.1. Device Number
> > > > + *
> > > > + * Downstream Ports that do not have ARI Forwarding enabled
> > > must
> > > > + * associate only Device 0 with the device atta
Re: [Qemu-devel] [PATCH v5 2/3] pc & q35: Add new machine opt max-ram-below-4g
Hi,
On Mon, 2014-06-09 at 17:38 +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 09, 2014 at 10:20:57AM -0400, Don Slutz wrote:
> > On 06/08/14 11:40, Michael S. Tsirkin wrote:
> > >On Fri, Jun 06, 2014 at 01:52:05PM -0400, Don Slutz wrote:
> > >>This is a pc & q35 only machine opt. One use is to allow for more
> > >>ram in a 32bit guest for example:
> > >>
> > >>-machine pc,max-ram-below-4g=3.75G
> > >>
> > >>If you add enough PCI devices then all mmio for them will not fit
> > >>below 4G which may not be the layout the user wanted. This allows
> > >>you to increase the below 4G address space that PCI devices can use
> > >>(aka decrease ram below 4G) and therefore in more cases not have any
> > >>mmio that is above 4G.
> > >>
> > >>For example using "-machine pc,max-ram-below-4g=2G" on the command
> > >>line will limit the amount of ram that is below 4G to 2G.
> > >>
> > >>Signed-off-by: Don Slutz
> > >>---
> > >>v5:
> > >> Re-work based on:
> > >>
> > >> https://github.com/imammedo/qemu/commits/memory-hotplug-v11
> > >>
> > >>
> > >> hw/i386/pc.c | 38 ++
> > >> hw/i386/pc_piix.c| 15 ---
> > >> hw/i386/pc_q35.c | 15 ---
> > >> include/hw/i386/pc.h | 3 +++
> > >> vl.c | 4
> > >> 5 files changed, 69 insertions(+), 6 deletions(-)
> > >>
> > >>diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > >>index 7cdba10..bccb746 100644
> > >>--- a/hw/i386/pc.c
> > >>+++ b/hw/i386/pc.c
> > >>@@ -1644,11 +1644,49 @@ pc_machine_get_hotplug_memory_region_size(Object
> > >>*obj, Visitor *v, void *opaque,
> > >> visit_type_int(v, &value, name, errp);
> > >> }
> > >>+static void pc_machine_get_max_ram_below_4g(Object *obj, Visitor *v,
> > >>+ void *opaque, const char *name,
> > >>+ Error **errp)
> > >>+{
> > >>+PCMachineState *pcms = PC_MACHINE(obj);
> > >>+uint64_t value = pcms->max_ram_below_4g;
> > >>+
> > >>+visit_type_size(v, &value, name, errp);
> > >>+}
> > >>+
> > >>+static void pc_machine_set_max_ram_below_4g(Object *obj, Visitor *v,
> > >>+ void *opaque, const char *name,
> > >>+ Error **errp)
> > >>+{
> > >>+PCMachineState *pcms = PC_MACHINE(obj);
> > >>+Error *error = NULL;
> > >>+uint64_t value;
> > >>+
> > >>+visit_type_size(v, &value, name, &error);
> > >>+if (error) {
> > >>+error_propagate(errp, error);
> > >>+return;
> > >>+}
> > >>+if (value > (1ULL << 32)) {
> > >>+error_set(&error, ERROR_CLASS_GENERIC_ERROR,
> > >>+ "Machine option 'max-ram-below-4g=%"PRIu64
> > >>+ "' expects size less then or equal to 4G", value);
> > >less than
> >
> > But the test is greater then. So "not greater then" is "less then or
> > equal".
> > Or did you want the test changed?
>
> No, just correcting English: less than, not less then :)
>
> > >>+error_propagate(errp, error);
> > >>+return;
> > >>+}
> > >>+
> > >>+pcms->max_ram_below_4g = value;
> > >>+}
> > >>+
> > >> static void pc_machine_initfn(Object *obj)
> > >> {
> > >> object_property_add(obj, PC_MACHINE_MEMHP_REGION_SIZE, "int",
> > >> pc_machine_get_hotplug_memory_region_size,
> > >> NULL, NULL, NULL, NULL);
> > >>+object_property_add(obj, PC_MACHINE_MAX_RAM_BELOW_4G, "size",
> > >>+pc_machine_get_max_ram_below_4g,
> > >>+pc_machine_set_max_ram_below_4g,
> > >>+NULL, NULL, NULL);
Maybe you can add here a sane default and avoid comparison with 0
any time you use it.
If you think you need value per machine type, you can add it to
compat props. I don't see how is related, so you may not want to do so.
> > >> }
> > >> static void pc_machine_class_init(ObjectClass *oc, void *data)
> > >>diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > >>index 40f6eaf..25f4727 100644
> > >>--- a/hw/i386/pc_piix.c
> > >>+++ b/hw/i386/pc_piix.c
> > >>@@ -98,6 +98,13 @@ static void pc_init1(MachineState *machine,
> > >> DeviceState *icc_bridge;
> > >> FWCfgState *fw_cfg = NULL;
> > >> PcGuestInfo *guest_info;
> > >>+Object *mo = qdev_get_machine();
> > >>+PCMachineState *pcms = PC_MACHINE(mo);
> > >>+ram_addr_t lowmem = 0xe000;
> > >>+
> > >>+if (pcms && pcms->max_ram_below_4g) {
>From my QOM understanding, max_ram_below_4g is a private field,
so it not should be used directly.
You can use QOMs object_property_get or add a pc_machine wrapper
for getting/setting the field.
> > >Is pcms ever NULL? If yes why?
> >
> > Not that I know of. I would be happy to convert this to an assert(pcms).
>
> In fact, PC_MACHINE already includes an assert doesn't it?
> So no need to check it everywhere.
+1. No need for assert here. Is already
Re: [Qemu-devel] [PATCH v5 2/3] pc & q35: Add new machine opt max-ram-below-4g
On Mon, 2014-06-09 at 17:37 +0200, Igor Mammedov wrote:
> On Mon, 09 Jun 2014 18:10:27 +0300
> Marcel Apfelbaum wrote:
>
> > Hi,
> >
> > On Mon, 2014-06-09 at 17:38 +0300, Michael S. Tsirkin wrote:
> > > On Mon, Jun 09, 2014 at 10:20:57AM -0400, Don Slutz wrote:
> > > > On 06/08/14 11:40, Michael S. Tsirkin wrote:
> > > > >On Fri, Jun 06, 2014 at 01:52:05PM -0400, Don Slutz wrote:
> > > > >>This is a pc & q35 only machine opt. One use is to allow for more
> > > > >>ram in a 32bit guest for example:
> > > > >>
> > > > >>-machine pc,max-ram-below-4g=3.75G
> > > > >>
> > > > >>If you add enough PCI devices then all mmio for them will not fit
> > > > >>below 4G which may not be the layout the user wanted. This allows
> > > > >>you to increase the below 4G address space that PCI devices can use
> > > > >>(aka decrease ram below 4G) and therefore in more cases not have any
> > > > >>mmio that is above 4G.
> > > > >>
> > > > >>For example using "-machine pc,max-ram-below-4g=2G" on the command
> > > > >>line will limit the amount of ram that is below 4G to 2G.
> > > > >>
> > > > >>Signed-off-by: Don Slutz
> > > > >>---
> > > > >>v5:
> > > > >> Re-work based on:
> > > > >>
> > > > >> https://github.com/imammedo/qemu/commits/memory-hotplug-v11
> > > > >>
> > > > >>
> > > > >> hw/i386/pc.c | 38 ++
> > > > >> hw/i386/pc_piix.c| 15 ---
> > > > >> hw/i386/pc_q35.c | 15 ---
> > > > >> include/hw/i386/pc.h | 3 +++
> > > > >> vl.c | 4
> > > > >> 5 files changed, 69 insertions(+), 6 deletions(-)
> > > > >>
> > > > >>diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > > > >>index 7cdba10..bccb746 100644
> > > > >>--- a/hw/i386/pc.c
> > > > >>+++ b/hw/i386/pc.c
> > > > >>@@ -1644,11 +1644,49 @@
> > > > >>pc_machine_get_hotplug_memory_region_size(Object *obj, Visitor *v,
> > > > >>void *opaque,
> > > > >> visit_type_int(v, &value, name, errp);
> > > > >> }
> > > > >>+static void pc_machine_get_max_ram_below_4g(Object *obj, Visitor *v,
> > > > >>+ void *opaque, const char
> > > > >>*name,
> > > > >>+ Error **errp)
> > > > >>+{
> > > > >>+PCMachineState *pcms = PC_MACHINE(obj);
> > > > >>+uint64_t value = pcms->max_ram_below_4g;
> > > > >>+
> > > > >>+visit_type_size(v, &value, name, errp);
> > > > >>+}
> > > > >>+
> > > > >>+static void pc_machine_set_max_ram_below_4g(Object *obj, Visitor *v,
> > > > >>+ void *opaque, const char
> > > > >>*name,
> > > > >>+ Error **errp)
> > > > >>+{
> > > > >>+PCMachineState *pcms = PC_MACHINE(obj);
> > > > >>+Error *error = NULL;
> > > > >>+uint64_t value;
> > > > >>+
> > > > >>+visit_type_size(v, &value, name, &error);
> > > > >>+if (error) {
> > > > >>+error_propagate(errp, error);
> > > > >>+return;
> > > > >>+}
> > > > >>+if (value > (1ULL << 32)) {
> > > > >>+error_set(&error, ERROR_CLASS_GENERIC_ERROR,
> > > > >>+ "Machine option 'max-ram-below-4g=%"PRIu64
> > > > >>+ "' expects size less then or equal to 4G", value);
> > > > >less than
> > > >
> > > > But the test is greater then. So "not greater then" is "less then or
> > > > equal".
> > > > Or did you want the test changed?
> > >
> > > No, just correcting English: less than, not less then :)
> > >
> > > > >
Re: [Qemu-devel] [RFC] pc: Register machine classes directly instead of using QEMUMachine
On Thu, 2014-06-12 at 10:02 +0200, Igor Mammedov wrote:
> On Thu, 12 Jun 2014 03:22:24 -0300
> Eduardo Habkost wrote:
>
> > This is a (mostly) blind and mechanical conversion of the PC QEMUMachine
> > definitions to corresponding class registration code.
> >
> > Having the PC code converted to pure QOM registration code will help us
> > move PC-specific machine state that is currently held in static
> > variables inside PC machine objects, and reduce duplication between
> > pc_piix.c and pc_q35.c.
>
> Getting rid of *_machine_options() functions and doing nested
> inheritance with necessary overrides in respective *_class_init()
> functions, would make code more readable/understandable.
While I agree with you that this is the right direction, Eduardo's
patch is a good step forward getting rid of QEMUMachine and those
defines. I say we implement the hierarchy on top of this patch.
>
> >
> > Signed-off-by: Eduardo Habkost
> > ---
> > hw/i386/pc.c | 13 ++
> > hw/i386/pc_piix.c| 473
> > +++
> > hw/i386/pc_q35.c | 171 +--
> > include/hw/i386/pc.h | 20 ++-
> > 4 files changed, 465 insertions(+), 212 deletions(-)
> >
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 32d1632..56720cd 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -1456,3 +1456,16 @@ void ioapic_init_gsi(GSIState *gsi_state, const char
> > *parent_name)
> > gsi_state->ioapic_irq[i] = qdev_get_gpio_in(dev, i);
> > }
> > }
> > +
> > +static TypeInfo pc_machine_type_info = {
> > +.name = TYPE_PC_MACHINE,
> > +.parent = TYPE_MACHINE,
> > +.abstract = true,
> > +};
Igor's series already introduces TYPE_PC_MACHINE, you may want to rebase on it:
http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg00133.html
Thanks,
Marcel
Re: [Qemu-devel] [PATCH] pc: acpi-build: make linker & RSDP tables dynamic
On Tue, 2014-06-17 at 23:19 +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 17, 2014 at 10:14:01PM +0200, Igor Mammedov wrote:
> > linker and RSDP tables are build only once, so if later
> > during rebuild sizes of ACPI tables change pointers will
> > be patched incorrectly due to wrong offsets.
> >
> > To fix it rebuild linker and RSDP tables along with
> > the rest of ACPI tables so that they would have correct
> > offsets.
> >
> > Signed-off-by: Igor Mammedov
>
> If you are adding a new blob you are breaking cross-version migration.
> Need to handle that depending on pc version as appropriate.
Besides the above comment,
Tested-by: Marcel Apfelbaum
Reviewed-by: Marcel Apfelbaum
Thanks,
Marcel
>
> > ---
> > hw/i386/acpi-build.c | 21 ++---
> > 1 file changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > index fab25ad..8301bb4 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -1862,6 +1862,10 @@ struct AcpiBuildState {
> > /* Copy of table in RAM (for patching). */
> > uint8_t *table_ram;
> > uint32_t table_size;
> > +uint8_t *linker_ram;
> > +uint32_t linker_size;
> > +uint8_t *rsdp_ram;
> > +uint32_t rsdp_size;
> > /* Is table patched? */
> > uint8_t patched;
> > PcGuestInfo *guest_info;
> > @@ -1998,6 +2002,10 @@ static void acpi_build_update(void *build_opaque,
> > uint32_t offset)
> > assert(acpi_data_len(tables.table_data) == build_state->table_size);
> > memcpy(build_state->table_ram, tables.table_data->data,
> > build_state->table_size);
> > +memcpy(build_state->linker_ram, tables.linker->data,
> > + build_state->linker_size);
> > +memcpy(build_state->rsdp_ram, tables.rsdp->data,
> > + build_state->rsdp_size);
> >
> > acpi_build_tables_cleanup(&tables, true);
> > }
> > @@ -2060,14 +2068,13 @@ void acpi_setup(PcGuestInfo *guest_info)
> > ACPI_BUILD_TABLE_FILE);
> > build_state->table_size = acpi_data_len(tables.table_data);
> >
> > -acpi_add_rom_blob(NULL, tables.linker, "etc/table-loader");
> > +build_state->linker_ram = acpi_add_rom_blob(build_state, tables.linker,
> > +"etc/table-loader");
> > +build_state->linker_size = acpi_data_len(tables.linker);
> >
> > -/*
> > - * RSDP is small so it's easy to keep it immutable, no need to
> > - * bother with ROM blobs.
> > - */
> > -fw_cfg_add_file(guest_info->fw_cfg, ACPI_BUILD_RSDP_FILE,
> > -tables.rsdp->data, acpi_data_len(tables.rsdp));
> > +build_state->rsdp_ram = acpi_add_rom_blob(build_state, tables.rsdp,
> > + ACPI_BUILD_RSDP_FILE);
> > +build_state->rsdp_size = acpi_data_len(tables.rsdp);
> >
> > qemu_register_reset(acpi_build_reset, build_state);
> > acpi_build_reset(build_state);
> > --
> > 1.9.3
[Qemu-devel] [PATCH] hw/pci: reserve IO and mem for pci express downstream ports with no devices attached
commit c6e298e1f12e0f4ca02b6da5e42919ae055f6830
hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached
introduced support for hot-plugging devices behind pci-2-pci bridges.
Extend hotplug support also for pci express downstream ports.
Signed-off-by: Marcel Apfelbaum
---
src/fw/pciinit.c | 23 +--
src/hw/pci_regs.h | 2 ++
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 0ad548f..edb3fe9 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -636,6 +636,25 @@ pci_region_create_entry(struct pci_bus *bus, struct
pci_device *dev,
return entry;
}
+static int pci_bus_hotplug_support(struct pci_bus *bus)
+{
+u8 shpc_cap = pci_find_capability(bus->bus_dev, PCI_CAP_ID_SHPC);
+u8 pcie_cap = pci_find_capability(bus->bus_dev, PCI_CAP_ID_EXP);
+int downstream_port = 0;
+int slot_implemented = 0;
+
+if (pcie_cap) {
+u16 pcie_flags = pci_config_readw(bus->bus_dev->bdf,
+ pcie_cap + PCI_EXP_FLAGS);
+u16 port_type = ((pcie_flags & PCI_EXP_FLAGS_TYPE) >>
+PCI_EXP_FLAGS_TYPE_SHIFT) & 0xf;
+downstream_port = (port_type == PCI_EXP_TYPE_DOWNSTREAM) ||
+ (port_type == PCI_EXP_TYPE_ROOT_PORT);
+slot_implemented = !!(pcie_flags & PCI_EXP_FLAGS_SLOT);
+}
+return shpc_cap || (downstream_port && slot_implemented);
+}
+
static int pci_bios_check_devices(struct pci_bus *busses)
{
dprintf(1, "PCI: check devices\n");
@@ -678,7 +697,7 @@ static int pci_bios_check_devices(struct pci_bus *busses)
continue;
struct pci_bus *parent = &busses[pci_bdf_to_bus(s->bus_dev->bdf)];
int type;
-u8 shpc_cap = pci_find_capability(s->bus_dev, PCI_CAP_ID_SHPC);
+int hotplug_support = pci_bus_hotplug_support(s);
for (type = 0; type < PCI_REGION_TYPE_COUNT; type++) {
u64 align = (type == PCI_REGION_TYPE_IO) ?
PCI_BRIDGE_IO_MIN : PCI_BRIDGE_MEM_MIN;
@@ -687,7 +706,7 @@ static int pci_bios_check_devices(struct pci_bus *busses)
if (pci_region_align(&s->r[type]) > align)
align = pci_region_align(&s->r[type]);
u64 sum = pci_region_sum(&s->r[type]);
-if (!sum && shpc_cap)
+if (!sum && hotplug_support)
sum = align; /* reserve min size for hot-plug */
u64 size = ALIGN(sum, align);
int is64 = pci_bios_bridge_region_is64(&s->r[type],
diff --git a/src/hw/pci_regs.h b/src/hw/pci_regs.h
index e5effd4..6a71569 100644
--- a/src/hw/pci_regs.h
+++ b/src/hw/pci_regs.h
@@ -426,6 +426,8 @@
#define PCI_EXP_DEVCTL240 /* Device Control 2 */
#define PCI_EXP_DEVCTL2_ARI 0x20/* Alternative Routing-ID */
+#define PCI_EXP_FLAGS_TYPE_SHIFT 4
+
/* Extended Capabilities (PCI-X 2.0 and Express) */
#define PCI_EXT_CAP_ID(header) (header & 0x)
#define PCI_EXT_CAP_VER(header)((header >> 16) & 0xf)
--
1.8.3.1
[Qemu-devel] [PATCH 1/3] hw/pcie: corrected a debug message
Trivial issue, discovered while debugging.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 02cde6f..ae92f00 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -224,7 +224,7 @@ static void pcie_cap_slot_hotplug_common(PCIDevice
*hotplug_dev,
*exp_cap = hotplug_dev->config + hotplug_dev->exp.exp_cap;
uint16_t sltsta = pci_get_word(*exp_cap + PCI_EXP_SLTSTA);
-PCIE_DEV_PRINTF(PCI_DEVICE(dev), "hotplug state: %d\n", state);
+PCIE_DEV_PRINTF(PCI_DEVICE(dev), "hotplug state: 0x%x\n", sltsta);
if (sltsta & PCI_EXP_SLTSTA_EIS) {
/* the slot is electromechanically locked.
* This error is propagated up to qdev and then to HMP/QMP.
--
1.8.3.1
[Qemu-devel] [PATCH 3/3] hw/pcie: better hotplug/hotunplug support
Hotplug triggers both 'present detect change' and
'attention button pressed'.
Hotunplug starts by triggering 'attention button pressed',
then waits for the OS to power off the device and only
then detaches it.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pcie.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index f8bf515..9cfd93d 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -258,7 +258,8 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev,
pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
PCI_EXP_SLTSTA_PDS);
-pcie_cap_slot_event(PCI_DEVICE(hotplug_dev), PCI_EXP_HP_EV_PDC);
+pcie_cap_slot_event(PCI_DEVICE(hotplug_dev),
+PCI_EXP_HP_EV_PDC | PCI_EXP_HP_EV_ABP);
}
void pcie_cap_slot_hot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
@@ -268,10 +269,7 @@ void pcie_cap_slot_hot_unplug_cb(HotplugHandler
*hotplug_dev, DeviceState *dev,
pcie_cap_slot_hotplug_common(PCI_DEVICE(hotplug_dev), dev, &exp_cap, errp);
-object_unparent(OBJECT(dev));
-pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
- PCI_EXP_SLTSTA_PDS);
-pcie_cap_slot_event(PCI_DEVICE(hotplug_dev), PCI_EXP_HP_EV_PDC);
+pcie_cap_slot_push_attention_button(PCI_DEVICE(hotplug_dev));
}
/* pci express slot for pci express root/downstream port
@@ -389,6 +387,18 @@ void pcie_cap_slot_write_config(PCIDevice *dev,
sltsta);
}
+if ((sltsta & PCI_EXP_SLTSTA_PDS) && (val & PCI_EXP_SLTCTL_PCC) &&
+((val & PCI_EXP_SLTCTL_PIC_OFF) == PCI_EXP_SLTCTL_PIC_OFF)) {
+PCIDevice *slot_dev =
pci_bridge_get_sec_bus(PCI_BRIDGE(dev))->devices[0];
+if (slot_dev) {
+object_unparent(OBJECT(slot_dev));
+pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
+ PCI_EXP_SLTSTA_PDS);
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
+ PCI_EXP_SLTSTA_PDC);
+}
+}
+
hotplug_event_notify(dev);
/*
--
1.8.3.1
[Qemu-devel] [PATCH 0/3] hw/pcie: better hotplug/hotunplug support
Hotplug triggers both 'present detect change' and 'attention button pressed'. Hotunplug starts by triggering 'attention button pressed', then waits for the OS to power off the device and only then detaches it. patch 1/3: trivial debug message fix patch 2/3: enable 'power controller' to receive power events from guests patch 3/3: the actual hotplug/hotunplug implementation. Tested with Linux and Windows guests and with an e1000 with "PCIe" capability. Notes: Windows requires devices to be pci express in order to enable hotplug functionality, so we need to think about converting virtio devices to pci express. Linux outputs a "Surprise Removal/Addition" info message because we trigger 2 events in the same time, however this warning can be disregarded or a kernel patch submitted for our scenario. Marcel Apfelbaum (3): hw/pcie: corrected a debug message hw/pcie: implement power controller functionality hw/pcie: better hotplug/hotunplug support hw/pci/pcie.c | 37 ++--- include/hw/pci/pcie_regs.h | 2 ++ 2 files changed, 32 insertions(+), 7 deletions(-) -- 1.8.3.1
[Qemu-devel] [PATCH 2/3] hw/pcie: implement power controller functionality
It is needed by hot-unplug in order to get an indication
from the OS when the device can be physically detached.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pcie.c | 15 ++-
include/hw/pci/pcie_regs.h | 2 ++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index ae92f00..f8bf515 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -292,16 +292,19 @@ void pcie_cap_slot_init(PCIDevice *dev, uint16_t slot)
PCI_EXP_SLTCAP_HPC |
PCI_EXP_SLTCAP_PIP |
PCI_EXP_SLTCAP_AIP |
+ PCI_EXP_SLTCAP_PCP |
PCI_EXP_SLTCAP_ABP);
pci_word_test_and_clear_mask(dev->config + pos + PCI_EXP_SLTCTL,
PCI_EXP_SLTCTL_PIC |
+ PCI_EXP_SLTCTL_PCC |
PCI_EXP_SLTCTL_AIC);
pci_word_test_and_set_mask(dev->config + pos + PCI_EXP_SLTCTL,
PCI_EXP_SLTCTL_PIC_OFF |
PCI_EXP_SLTCTL_AIC_OFF);
pci_word_test_and_set_mask(dev->wmask + pos + PCI_EXP_SLTCTL,
PCI_EXP_SLTCTL_PIC |
+ PCI_EXP_SLTCTL_PCC |
PCI_EXP_SLTCTL_AIC |
PCI_EXP_SLTCTL_HPIE |
PCI_EXP_SLTCTL_CCIE |
@@ -327,21 +330,31 @@ void pcie_cap_slot_init(PCIDevice *dev, uint16_t slot)
void pcie_cap_slot_reset(PCIDevice *dev)
{
uint8_t *exp_cap = dev->config + dev->exp.exp_cap;
+PCIDevice *slot_dev = pci_bridge_get_sec_bus(PCI_BRIDGE(dev))->devices[0];
+int pic;
+
+pic = slot_dev ? PCI_EXP_SLTCTL_PIC_ON : PCI_EXP_SLTCTL_PIC_OFF;
PCIE_DEV_PRINTF(dev, "reset\n");
pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTCTL,
PCI_EXP_SLTCTL_EIC |
PCI_EXP_SLTCTL_PIC |
+ PCI_EXP_SLTCTL_PCC |
PCI_EXP_SLTCTL_AIC |
PCI_EXP_SLTCTL_HPIE |
PCI_EXP_SLTCTL_CCIE |
PCI_EXP_SLTCTL_PDCE |
PCI_EXP_SLTCTL_ABPE);
pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTCTL,
- PCI_EXP_SLTCTL_PIC_OFF |
+ pic |
PCI_EXP_SLTCTL_AIC_OFF);
+if (!slot_dev) {
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTCTL,
+ PCI_EXP_SLTCTL_PCC);
+}
+
pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
PCI_EXP_SLTSTA_EIS |/* on reset,
the lock is released */
diff --git a/include/hw/pci/pcie_regs.h b/include/hw/pci/pcie_regs.h
index 4d123d9..652d9fc 100644
--- a/include/hw/pci/pcie_regs.h
+++ b/include/hw/pci/pcie_regs.h
@@ -57,6 +57,8 @@
#define PCI_EXP_SLTCTL_PIC_SHIFT(ffs(PCI_EXP_SLTCTL_PIC) - 1)
#define PCI_EXP_SLTCTL_PIC_OFF \
(PCI_EXP_SLTCTL_IND_OFF << PCI_EXP_SLTCTL_PIC_SHIFT)
+#define PCI_EXP_SLTCTL_PIC_ON \
+(PCI_EXP_SLTCTL_IND_ON << PCI_EXP_SLTCTL_PIC_SHIFT)
#define PCI_EXP_SLTCTL_SUPPORTED\
(PCI_EXP_SLTCTL_ABPE | \
--
1.8.3.1
Re: [Qemu-devel] [PATCH] hw/pci: reserve IO and mem for pci express downstream ports with no devices attached
On Thu, 2014-06-19 at 17:21 +0300, Michael S. Tsirkin wrote:
> On Thu, Jun 19, 2014 at 04:52:17PM +0300, Marcel Apfelbaum wrote:
> > commit c6e298e1f12e0f4ca02b6da5e42919ae055f6830
> > hw/pci: reserve IO and mem for pci-2-pci bridges with no devices
> > attached
> >
> > introduced support for hot-plugging devices behind pci-2-pci bridges.
> > Extend hotplug support also for pci express downstream ports.
> >
> > Signed-off-by: Marcel Apfelbaum
> > ---
> > src/fw/pciinit.c | 23 +--
> > src/hw/pci_regs.h | 2 ++
> > 2 files changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> > index 0ad548f..edb3fe9 100644
> > --- a/src/fw/pciinit.c
> > +++ b/src/fw/pciinit.c
> > @@ -636,6 +636,25 @@ pci_region_create_entry(struct pci_bus *bus, struct
> > pci_device *dev,
> > return entry;
> > }
> >
> > +static int pci_bus_hotplug_support(struct pci_bus *bus)
> > +{
> > +u8 shpc_cap = pci_find_capability(bus->bus_dev, PCI_CAP_ID_SHPC);
> > +u8 pcie_cap = pci_find_capability(bus->bus_dev, PCI_CAP_ID_EXP);
> > +int downstream_port = 0;
> > +int slot_implemented = 0;
> > +
> > +if (pcie_cap) {
> > +u16 pcie_flags = pci_config_readw(bus->bus_dev->bdf,
> > + pcie_cap + PCI_EXP_FLAGS);
> > +u16 port_type = ((pcie_flags & PCI_EXP_FLAGS_TYPE) >>
> > +PCI_EXP_FLAGS_TYPE_SHIFT) & 0xf;
>
> 0xf is not needed here: PCI_EXP_FLAGS_TYPE is enough.
> Also should be u8.
OK, thanks
>
> > +downstream_port = (port_type == PCI_EXP_TYPE_DOWNSTREAM) ||
> > + (port_type == PCI_EXP_TYPE_ROOT_PORT);
>
> This is correct, the spec says:
> Configuration Space, and other capabilities.
> 8 Slot Implemented – When Set, this bit indicates that the Link
> HwInit associated with this Port is connected to a slot (as compared to
> being connected to a system-integrated device or being
> disabled).
> This bit is valid for Downstream Ports. This bit is undefined for
> Upstream Ports.
>
> Maybe add a comment in case people will wonder.
Sure
>
> > +slot_implemented = !!(pcie_flags & PCI_EXP_FLAGS_SLOT);
>
> I would do
> return downstream_port && slot_implemented;
> here, avoid testing shpc for express devices.
>
> Also allows moving downstream_port && slot_implemented here.
Makes sense
>
> > +}
> > +return shpc_cap || (downstream_port && slot_implemented);
> > +}
> > +
> > static int pci_bios_check_devices(struct pci_bus *busses)
> > {
> > dprintf(1, "PCI: check devices\n");
> > @@ -678,7 +697,7 @@ static int pci_bios_check_devices(struct pci_bus
> > *busses)
> > continue;
> > struct pci_bus *parent = &busses[pci_bdf_to_bus(s->bus_dev->bdf)];
> > int type;
> > -u8 shpc_cap = pci_find_capability(s->bus_dev, PCI_CAP_ID_SHPC);
> > +int hotplug_support = pci_bus_hotplug_support(s);
> > for (type = 0; type < PCI_REGION_TYPE_COUNT; type++) {
> > u64 align = (type == PCI_REGION_TYPE_IO) ?
> > PCI_BRIDGE_IO_MIN : PCI_BRIDGE_MEM_MIN;
> > @@ -687,7 +706,7 @@ static int pci_bios_check_devices(struct pci_bus
> > *busses)
> > if (pci_region_align(&s->r[type]) > align)
> > align = pci_region_align(&s->r[type]);
> > u64 sum = pci_region_sum(&s->r[type]);
> > -if (!sum && shpc_cap)
> > +if (!sum && hotplug_support)
> > sum = align; /* reserve min size for hot-plug */
> > u64 size = ALIGN(sum, align);
> > int is64 = pci_bios_bridge_region_is64(&s->r[type],
> > diff --git a/src/hw/pci_regs.h b/src/hw/pci_regs.h
> > index e5effd4..6a71569 100644
> > --- a/src/hw/pci_regs.h
> > +++ b/src/hw/pci_regs.h
> > @@ -426,6 +426,8 @@
> > #define PCI_EXP_DEVCTL240 /* Device Control 2 */
> > #define PCI_EXP_DEVCTL2_ARI 0x20/* Alternative Routing-ID */
> >
> > +#define PCI_EXP_FLAGS_TYPE_SHIFT 4
> > +
>
> It's generally not a good idea to randomly add macros
> in random places.
> In this case this is not needed. Just call __ffs on
> PCI_EXP_FLAGS_TYPE.
I didn't see any usage of __ffs method on seabios code, so
I wondered if adding an include to string.h would be ok.
Would it?
Thanks,
Marcel
>
> > /* Extended Capabilities (PCI-X 2.0 and Express) */
> > #define PCI_EXT_CAP_ID(header) (header & 0x)
> > #define PCI_EXT_CAP_VER(header)((header >> 16) & 0xf)
> > --
> > 1.8.3.1
Re: [Qemu-devel] [PATCH 2/3] hw/pcie: implement power controller functionality
On Thu, 2014-06-19 at 17:39 +0300, Michael S. Tsirkin wrote:
> On Thu, Jun 19, 2014 at 04:52:20PM +0300, Marcel Apfelbaum wrote:
> > It is needed by hot-unplug in order to get an indication
> > from the OS when the device can be physically detached.
> >
> > Signed-off-by: Marcel Apfelbaum
> > ---
> > hw/pci/pcie.c | 15 ++-
> > include/hw/pci/pcie_regs.h | 2 ++
> > 2 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > index ae92f00..f8bf515 100644
> > --- a/hw/pci/pcie.c
> > +++ b/hw/pci/pcie.c
> > @@ -292,16 +292,19 @@ void pcie_cap_slot_init(PCIDevice *dev, uint16_t slot)
> > PCI_EXP_SLTCAP_HPC |
> > PCI_EXP_SLTCAP_PIP |
> > PCI_EXP_SLTCAP_AIP |
> > + PCI_EXP_SLTCAP_PCP |
> > PCI_EXP_SLTCAP_ABP);
> >
> > pci_word_test_and_clear_mask(dev->config + pos + PCI_EXP_SLTCTL,
> > PCI_EXP_SLTCTL_PIC |
> > + PCI_EXP_SLTCTL_PCC |
> > PCI_EXP_SLTCTL_AIC);
> > pci_word_test_and_set_mask(dev->config + pos + PCI_EXP_SLTCTL,
> > PCI_EXP_SLTCTL_PIC_OFF |
> > PCI_EXP_SLTCTL_AIC_OFF);
> > pci_word_test_and_set_mask(dev->wmask + pos + PCI_EXP_SLTCTL,
> > PCI_EXP_SLTCTL_PIC |
> > + PCI_EXP_SLTCTL_PCC |
> > PCI_EXP_SLTCTL_AIC |
> > PCI_EXP_SLTCTL_HPIE |
> > PCI_EXP_SLTCTL_CCIE |
>
> Need to disable for compat types?
Does Paolo's explanation answer your question?
>
>
> > @@ -327,21 +330,31 @@ void pcie_cap_slot_init(PCIDevice *dev, uint16_t slot)
> > void pcie_cap_slot_reset(PCIDevice *dev)
> > {
> > uint8_t *exp_cap = dev->config + dev->exp.exp_cap;
> > +PCIDevice *slot_dev =
> > pci_bridge_get_sec_bus(PCI_BRIDGE(dev))->devices[0];
>
> What does this mean?
> Downstream port?
Yes
> A switch can have multiple downstream ports at any slot #.
It doesn't matter how many devices are under this slot, we need only
one to power up the slot. The question here was "Do we have at least
one device attahc to slot? If yes, power up the slot."
>
> > +int pic;
>
> uint16_t please.
Sure,
>
> > +
> > +pic = slot_dev ? PCI_EXP_SLTCTL_PIC_ON : PCI_EXP_SLTCTL_PIC_OFF;
> >
> > PCIE_DEV_PRINTF(dev, "reset\n");
> >
> > pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTCTL,
> > PCI_EXP_SLTCTL_EIC |
> > PCI_EXP_SLTCTL_PIC |
> > + PCI_EXP_SLTCTL_PCC |
> > PCI_EXP_SLTCTL_AIC |
> > PCI_EXP_SLTCTL_HPIE |
> > PCI_EXP_SLTCTL_CCIE |
> > PCI_EXP_SLTCTL_PDCE |
> > PCI_EXP_SLTCTL_ABPE);
> > pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTCTL,
> > - PCI_EXP_SLTCTL_PIC_OFF |
> > + pic |
> > PCI_EXP_SLTCTL_AIC_OFF);
> >
> > +if (!slot_dev) {
> > +pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTCTL,
> > + PCI_EXP_SLTCTL_PCC);
>
> I dislike it when we clear bits then set them back.
> Please just add else here.
Sure,
>
> > +}
> > +
>
> Need to disable for compat types?
As above,
Thanks for the review,
Marcel
>
> > pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
> > PCI_EXP_SLTSTA_EIS |/* on reset,
> > the lock is
> > released */
> > diff --git a/include/hw/pci/pcie_regs.h b/include/hw/pci/pcie_regs.h
> > index 4d123d9..652d9fc 100644
> > --- a/include/hw/pci/pcie_regs.h
> > +++ b/include/hw/pci/pcie_regs.h
> > @@ -57,6 +57,8 @@
> > #define PCI_EXP_SLTCTL_PIC_SHIFT(ffs(PCI_EXP_SLTCTL_PIC) - 1)
> > #define PCI_EXP_SLTCTL_PIC_OFF \
> > (PCI_EXP_SLTCTL_IND_OFF << PCI_EXP_SLTCTL_PIC_SHIFT)
> > +#define PCI_EXP_SLTCTL_PIC_ON \
> > +(PCI_EXP_SLTCTL_IND_ON << PCI_EXP_SLTCTL_PIC_SHIFT)
> >
> > #define PCI_EXP_SLTCTL_SUPPORTED\
> > (PCI_EXP_SLTCTL_ABPE | \
> > --
> > 1.8.3.1
Re: [Qemu-devel] [PATCH 3/3] hw/pcie: better hotplug/hotunplug support
On Thu, 2014-06-19 at 17:43 +0300, Michael S. Tsirkin wrote:
> On Thu, Jun 19, 2014 at 04:52:21PM +0300, Marcel Apfelbaum wrote:
> > Hotplug triggers both 'present detect change' and
> > 'attention button pressed'.
> >
> > Hotunplug starts by triggering 'attention button pressed',
> > then waits for the OS to power off the device and only
> > then detaches it.
> >
>
> Pls not here that current code is broken: it does surprise removal which
> crashes guests.
I'll add a note, sure.
>
> > Signed-off-by: Marcel Apfelbaum
> > ---
> > hw/pci/pcie.c | 20 +++-
> > 1 file changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > index f8bf515..9cfd93d 100644
> > --- a/hw/pci/pcie.c
> > +++ b/hw/pci/pcie.c
> > @@ -258,7 +258,8 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler
> > *hotplug_dev, DeviceState *dev,
> >
> > pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
> > PCI_EXP_SLTSTA_PDS);
> > -pcie_cap_slot_event(PCI_DEVICE(hotplug_dev), PCI_EXP_HP_EV_PDC);
> > +pcie_cap_slot_event(PCI_DEVICE(hotplug_dev),
> > +PCI_EXP_HP_EV_PDC | PCI_EXP_HP_EV_ABP);
> > }
> >
> > void pcie_cap_slot_hot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState
> > *dev,
> > @@ -268,10 +269,7 @@ void pcie_cap_slot_hot_unplug_cb(HotplugHandler
> > *hotplug_dev, DeviceState *dev,
> >
> > pcie_cap_slot_hotplug_common(PCI_DEVICE(hotplug_dev), dev, &exp_cap,
> > errp);
> >
> > -object_unparent(OBJECT(dev));
> > -pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
> > - PCI_EXP_SLTSTA_PDS);
> > -pcie_cap_slot_event(PCI_DEVICE(hotplug_dev), PCI_EXP_HP_EV_PDC);
> > +pcie_cap_slot_push_attention_button(PCI_DEVICE(hotplug_dev));
> > }
> >
> > /* pci express slot for pci express root/downstream port
> > @@ -389,6 +387,18 @@ void pcie_cap_slot_write_config(PCIDevice *dev,
> > sltsta);
> > }
> >
>
> pls add code comments explaining the logic here.
I thought is clear :(
Basically: If the device is present, power indicator off and power
controller off, it is safe to detach the device.
>
> > +if ((sltsta & PCI_EXP_SLTSTA_PDS) && (val & PCI_EXP_SLTCTL_PCC) &&
> > +((val & PCI_EXP_SLTCTL_PIC_OFF) == PCI_EXP_SLTCTL_PIC_OFF)) {
> > +PCIDevice *slot_dev =
> > pci_bridge_get_sec_bus(PCI_BRIDGE(dev))->devices[0];
> > +if (slot_dev) {
>
> Here you want to remove all devices behind the bridge?
Yes, but since it is PCIe we only have one device,
but we may have a multi-function device...
> You need to do this for all functions, not just function 0.
So bus devices are actually functions... OK, I'll run a loop here.
>
> > +object_unparent(OBJECT(slot_dev));
> > +pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
> > + PCI_EXP_SLTSTA_PDS);
> > +pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
> > + PCI_EXP_SLTSTA_PDC);
>
> These bits need to be cleared in any case?
No, "PDS on" means the devices is present, so we clear it only after the
OS powers it off.
>
> > +}
> > +}
> > +
> > hotplug_event_notify(dev);
> >
> > /*
> > --
> > 1.8.3.1
Re: [Qemu-devel] [PATCH 3/3] hw/pcie: better hotplug/hotunplug support
On Sun, 2014-06-22 at 14:03 +0300, Michael S. Tsirkin wrote:
> On Sun, Jun 22, 2014 at 01:54:06PM +0300, Marcel Apfelbaum wrote:
> > On Thu, 2014-06-19 at 17:43 +0300, Michael S. Tsirkin wrote:
> > > On Thu, Jun 19, 2014 at 04:52:21PM +0300, Marcel Apfelbaum wrote:
> > > > Hotplug triggers both 'present detect change' and
> > > > 'attention button pressed'.
> > > >
> > > > Hotunplug starts by triggering 'attention button pressed',
> > > > then waits for the OS to power off the device and only
> > > > then detaches it.
> > > >
> > >
> > > Pls not here that current code is broken: it does surprise removal which
> > > crashes guests.
> > I'll add a note, sure.
> >
> > >
> > > > Signed-off-by: Marcel Apfelbaum
> > > > ---
> > > > hw/pci/pcie.c | 20 +++-
> > > > 1 file changed, 15 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > > > index f8bf515..9cfd93d 100644
> > > > --- a/hw/pci/pcie.c
> > > > +++ b/hw/pci/pcie.c
> > > > @@ -258,7 +258,8 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler
> > > > *hotplug_dev, DeviceState *dev,
> > > >
> > > > pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
> > > > PCI_EXP_SLTSTA_PDS);
> > > > -pcie_cap_slot_event(PCI_DEVICE(hotplug_dev), PCI_EXP_HP_EV_PDC);
> > > > +pcie_cap_slot_event(PCI_DEVICE(hotplug_dev),
> > > > +PCI_EXP_HP_EV_PDC | PCI_EXP_HP_EV_ABP);
> > > > }
> > > >
> > > > void pcie_cap_slot_hot_unplug_cb(HotplugHandler *hotplug_dev,
> > > > DeviceState *dev,
> > > > @@ -268,10 +269,7 @@ void pcie_cap_slot_hot_unplug_cb(HotplugHandler
> > > > *hotplug_dev, DeviceState *dev,
> > > >
> > > > pcie_cap_slot_hotplug_common(PCI_DEVICE(hotplug_dev), dev,
> > > > &exp_cap, errp);
> > > >
> > > > -object_unparent(OBJECT(dev));
> > > > -pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
> > > > - PCI_EXP_SLTSTA_PDS);
> > > > -pcie_cap_slot_event(PCI_DEVICE(hotplug_dev), PCI_EXP_HP_EV_PDC);
> > > > +pcie_cap_slot_push_attention_button(PCI_DEVICE(hotplug_dev));
> > > > }
> > > >
> > > > /* pci express slot for pci express root/downstream port
> > > > @@ -389,6 +387,18 @@ void pcie_cap_slot_write_config(PCIDevice *dev,
> > > > sltsta);
> > > > }
> > > >
> > >
> > > pls add code comments explaining the logic here.
> > I thought is clear :(
> > Basically: If the device is present, power indicator off and power
> > controller off, it is safe to detach the device.
>
> Sure, put this in the comment.
>
> > >
> > > > +if ((sltsta & PCI_EXP_SLTSTA_PDS) && (val & PCI_EXP_SLTCTL_PCC) &&
> > > > +((val & PCI_EXP_SLTCTL_PIC_OFF) == PCI_EXP_SLTCTL_PIC_OFF)) {
> > > > +PCIDevice *slot_dev =
> > > > pci_bridge_get_sec_bus(PCI_BRIDGE(dev))->devices[0];
> > > > +if (slot_dev) {
> > >
> > > Here you want to remove all devices behind the bridge?
> > Yes, but since it is PCIe we only have one device,
> > but we may have a multi-function device...
>
> Exactly. Up to 256 functions.
>
> > > You need to do this for all functions, not just function 0.
> > So bus devices are actually functions... OK, I'll run a loop here.
> >
> > >
> > > > +object_unparent(OBJECT(slot_dev));
> > > > +pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
> > > > + PCI_EXP_SLTSTA_PDS);
> > > > +pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
> > > > + PCI_EXP_SLTSTA_PDC);
> > >
> > > These bits need to be cleared in any case?
> > No, "PDS on" means the devices is present, so we clear it only after the
> > OS powers it off.
>
> So why not clear PDS unconditionally?
Because we are 'allowed' to remove the device only when the OS tells us
the power is off. Before that, it can result in data loss,
since the device driver is not yet unloaded.
> > >
> > > > +}
> > > > +}
> > > > +
> > > > hotplug_event_notify(dev);
> > > >
> > > > /*
> > > > --
> > > > 1.8.3.1
> >
> >
Re: [Qemu-devel] [PATCH 2/3] hw/pcie: implement power controller functionality
On Sun, 2014-06-22 at 14:11 +0300, Michael S. Tsirkin wrote:
> On Sun, Jun 22, 2014 at 01:52:46PM +0300, Michael S. Tsirkin wrote:
> > On Sun, Jun 22, 2014 at 01:47:24PM +0300, Marcel Apfelbaum wrote:
> > > On Thu, 2014-06-19 at 17:39 +0300, Michael S. Tsirkin wrote:
> > > > On Thu, Jun 19, 2014 at 04:52:20PM +0300, Marcel Apfelbaum wrote:
> > > > > It is needed by hot-unplug in order to get an indication
> > > > > from the OS when the device can be physically detached.
> > > > >
> > > > > Signed-off-by: Marcel Apfelbaum
> > > > > ---
> > > > > hw/pci/pcie.c | 15 ++-
> > > > > include/hw/pci/pcie_regs.h | 2 ++
> > > > > 2 files changed, 16 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > > > > index ae92f00..f8bf515 100644
> > > > > --- a/hw/pci/pcie.c
> > > > > +++ b/hw/pci/pcie.c
> > > > > @@ -292,16 +292,19 @@ void pcie_cap_slot_init(PCIDevice *dev,
> > > > > uint16_t slot)
> > > > > PCI_EXP_SLTCAP_HPC |
> > > > > PCI_EXP_SLTCAP_PIP |
> > > > > PCI_EXP_SLTCAP_AIP |
> > > > > + PCI_EXP_SLTCAP_PCP |
> > > > > PCI_EXP_SLTCAP_ABP);
> > > > >
> > > > > pci_word_test_and_clear_mask(dev->config + pos + PCI_EXP_SLTCTL,
> > > > > PCI_EXP_SLTCTL_PIC |
> > > > > + PCI_EXP_SLTCTL_PCC |
> > > > > PCI_EXP_SLTCTL_AIC);
> > > > > pci_word_test_and_set_mask(dev->config + pos + PCI_EXP_SLTCTL,
> > > > > PCI_EXP_SLTCTL_PIC_OFF |
> > > > > PCI_EXP_SLTCTL_AIC_OFF);
> > > > > pci_word_test_and_set_mask(dev->wmask + pos + PCI_EXP_SLTCTL,
> > > > > PCI_EXP_SLTCTL_PIC |
> > > > > + PCI_EXP_SLTCTL_PCC |
> > > > > PCI_EXP_SLTCTL_AIC |
> > > > > PCI_EXP_SLTCTL_HPIE |
> > > > > PCI_EXP_SLTCTL_CCIE |
> > > >
> > > > Need to disable for compat types?
> > > Does Paolo's explanation answer your question?
> >
> > Kind of hacky - we do have compat work for
> > q35. So I'd prefer consistency.
> >
> > > >
> > > >
> > > > > @@ -327,21 +330,31 @@ void pcie_cap_slot_init(PCIDevice *dev,
> > > > > uint16_t slot)
> > > > > void pcie_cap_slot_reset(PCIDevice *dev)
> > > > > {
> > > > > uint8_t *exp_cap = dev->config + dev->exp.exp_cap;
> > > > > +PCIDevice *slot_dev =
> > > > > pci_bridge_get_sec_bus(PCI_BRIDGE(dev))->devices[0];
> > > >
> > > > What does this mean?
> > > > Downstream port?
> > > Yes
> >
> > well it's not really clear, needs a comment.
> >
> > > > A switch can have multiple downstream ports at any slot #.
> > > It doesn't matter how many devices are under this slot, we need only
> > > one to power up the slot. The question here was "Do we have at least
> > > one device attahc to slot? If yes, power up the slot."
> >
> > You need a loop for that I think. There's no guarantee the
> > device is at devfn=0.
>
> Unless something guarantees this is a downstream port,
> if yes maybe add an assert?
> slot_dev is also not a very good variable name.
> How about
> bool populated = pci_bridge_get_sec_bus(PCI_BRIDGE(dev))->devices[0];
> ?
> This is all you care about ...
> And maybe add a comment
> /* Downstream ports enforce device number 0. */
I'll use that, thanks!
Marcel
>
> > > >
> > > > > +int pic;
> > > >
> > > > uint16_t please.
> > > Sure,
> > >
> > > >
> > > > > +
> > > > > +pic = slot_dev ? PCI_EXP_SLTCTL_PIC_ON : PCI_EXP_SLTCTL_PIC_OFF;
> > > > >
> > > > > PCIE_DEV_PRINTF(dev, "reset\n");
> > > > >
> > > > >
Re: [Qemu-devel] [PATCH 3/3] hw/pcie: better hotplug/hotunplug support
On Sun, 2014-06-22 at 14:12 +0300, Michael S. Tsirkin wrote:
> On Sun, Jun 22, 2014 at 02:11:05PM +0300, Marcel Apfelbaum wrote:
> > On Sun, 2014-06-22 at 14:03 +0300, Michael S. Tsirkin wrote:
> > > On Sun, Jun 22, 2014 at 01:54:06PM +0300, Marcel Apfelbaum wrote:
> > > > On Thu, 2014-06-19 at 17:43 +0300, Michael S. Tsirkin wrote:
> > > > > On Thu, Jun 19, 2014 at 04:52:21PM +0300, Marcel Apfelbaum wrote:
> > > > > > Hotplug triggers both 'present detect change' and
> > > > > > 'attention button pressed'.
> > > > > >
> > > > > > Hotunplug starts by triggering 'attention button pressed',
> > > > > > then waits for the OS to power off the device and only
> > > > > > then detaches it.
> > > > > >
> > > > >
> > > > > Pls not here that current code is broken: it does surprise removal
> > > > > which
> > > > > crashes guests.
> > > > I'll add a note, sure.
> > > >
> > > > >
> > > > > > Signed-off-by: Marcel Apfelbaum
> > > > > > ---
> > > > > > hw/pci/pcie.c | 20 +++-
> > > > > > 1 file changed, 15 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > > > > > index f8bf515..9cfd93d 100644
> > > > > > --- a/hw/pci/pcie.c
> > > > > > +++ b/hw/pci/pcie.c
> > > > > > @@ -258,7 +258,8 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler
> > > > > > *hotplug_dev, DeviceState *dev,
> > > > > >
> > > > > > pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
> > > > > > PCI_EXP_SLTSTA_PDS);
> > > > > > -pcie_cap_slot_event(PCI_DEVICE(hotplug_dev),
> > > > > > PCI_EXP_HP_EV_PDC);
> > > > > > +pcie_cap_slot_event(PCI_DEVICE(hotplug_dev),
> > > > > > +PCI_EXP_HP_EV_PDC | PCI_EXP_HP_EV_ABP);
> > > > > > }
> > > > > >
> > > > > > void pcie_cap_slot_hot_unplug_cb(HotplugHandler *hotplug_dev,
> > > > > > DeviceState *dev,
> > > > > > @@ -268,10 +269,7 @@ void
> > > > > > pcie_cap_slot_hot_unplug_cb(HotplugHandler *hotplug_dev,
> > > > > > DeviceState *dev,
> > > > > >
> > > > > > pcie_cap_slot_hotplug_common(PCI_DEVICE(hotplug_dev), dev,
> > > > > > &exp_cap, errp);
> > > > > >
> > > > > > -object_unparent(OBJECT(dev));
> > > > > > -pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
> > > > > > - PCI_EXP_SLTSTA_PDS);
> > > > > > -pcie_cap_slot_event(PCI_DEVICE(hotplug_dev),
> > > > > > PCI_EXP_HP_EV_PDC);
> > > > > > +pcie_cap_slot_push_attention_button(PCI_DEVICE(hotplug_dev));
> > > > > > }
> > > > > >
> > > > > > /* pci express slot for pci express root/downstream port
> > > > > > @@ -389,6 +387,18 @@ void pcie_cap_slot_write_config(PCIDevice *dev,
> > > > > > sltsta);
> > > > > > }
> > > > > >
> > > > >
> > > > > pls add code comments explaining the logic here.
> > > > I thought is clear :(
> > > > Basically: If the device is present, power indicator off and power
> > > > controller off, it is safe to detach the device.
> > >
> > > Sure, put this in the comment.
> > >
> > > > >
> > > > > > +if ((sltsta & PCI_EXP_SLTSTA_PDS) && (val &
> > > > > > PCI_EXP_SLTCTL_PCC) &&
> > > > > > +((val & PCI_EXP_SLTCTL_PIC_OFF) ==
> > > > > > PCI_EXP_SLTCTL_PIC_OFF)) {
> > > > > > +PCIDevice *slot_dev =
> > > > > > pci_bridge_get_sec_bus(PCI_BRIDGE(dev))->devices[0];
> > > > > > +if (slot_dev) {
> > > > >
> > > > > Here you want to remove all devices behind the bridge?
> > > > Yes, but since it is PCIe we only have one device,
> > > > but we may have a multi-function device...
> > &
[Qemu-devel] [PATCH v2 3/3] hw/pcie: better hotplug/hotunplug support
The current code is broken: it does surprise removal which crashes guests.
Reimplemented the steps:
- Hotplug triggers both 'present detect change' and
'attention button pressed'.
- Hotunplug starts by triggering 'attention button pressed',
then waits for the OS to power off the device and only
then detaches it.
Fixes CVE-2014-3471.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pcie.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index d6d9eb8..da32589 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -258,7 +258,8 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev,
pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
PCI_EXP_SLTSTA_PDS);
-pcie_cap_slot_event(PCI_DEVICE(hotplug_dev), PCI_EXP_HP_EV_PDC);
+pcie_cap_slot_event(PCI_DEVICE(hotplug_dev),
+PCI_EXP_HP_EV_PDC | PCI_EXP_HP_EV_ABP);
}
void pcie_cap_slot_hot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
@@ -268,10 +269,7 @@ void pcie_cap_slot_hot_unplug_cb(HotplugHandler
*hotplug_dev, DeviceState *dev,
pcie_cap_slot_hotplug_common(PCI_DEVICE(hotplug_dev), dev, &exp_cap, errp);
-object_unparent(OBJECT(dev));
-pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
- PCI_EXP_SLTSTA_PDS);
-pcie_cap_slot_event(PCI_DEVICE(hotplug_dev), PCI_EXP_HP_EV_PDC);
+pcie_cap_slot_push_attention_button(PCI_DEVICE(hotplug_dev));
}
/* pci express slot for pci express root/downstream port
@@ -383,6 +381,11 @@ void pcie_cap_slot_reset(PCIDevice *dev)
hotplug_event_update_event_status(dev);
}
+static void pcie_unplug_device(PCIBus *bus, PCIDevice *dev, void *opaque)
+{
+object_unparent(OBJECT(dev));
+}
+
void pcie_cap_slot_write_config(PCIDevice *dev,
uint32_t addr, uint32_t val, int len)
{
@@ -407,6 +410,22 @@ void pcie_cap_slot_write_config(PCIDevice *dev,
sltsta);
}
+/*
+ * If the slot is polulated, power indicator is off and power
+ * controller is off, it is safe to detach the devices.
+ */
+if ((sltsta & PCI_EXP_SLTSTA_PDS) && (val & PCI_EXP_SLTCTL_PCC) &&
+((val & PCI_EXP_SLTCTL_PIC_OFF) == PCI_EXP_SLTCTL_PIC_OFF)) {
+PCIBus *sec_bus = pci_bridge_get_sec_bus(PCI_BRIDGE(dev));
+pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
+pcie_unplug_device, NULL);
+
+pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
+ PCI_EXP_SLTSTA_PDS);
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
+ PCI_EXP_SLTSTA_PDC);
+}
+
hotplug_event_notify(dev);
/*
--
1.8.3.1
[Qemu-devel] [PATCH v2 0/3] hw/pcie: better hotplug/hotunplug support
v1 -> v2: - Addressed Michael S. Tsirkin's comments: - patch 2/3: - Added "power controller present" to compat_props. - patch 3/3: - Unplug all bus functions on hot-unplug, not only function 0. - Minor code refactoring The current code is broken: it does surprise removal which crashes guests. Reimplemented the steps: - Hotplug triggers both 'present detect change' and 'attention button pressed'. - Hotunplug starts by triggering 'attention button pressed', then waits for the OS to power off the device and only then detaches it. Fixes CVE-2014-3471. patch 1/3: trivial debug message fix patch 2/3: enable 'power controller' to receive power events from guests patch 3/3: the actual hotplug/hotunplug implementation. Tested with Linux and Windows guests and with an e1000 with "PCIe" capability. Notes: Windows requires devices to be pci express in order to enable hotplug functionality, so we need to think about converting virtio devices to pci express. Linux outputs a "Surprise Removal/Addition" info message because we trigger 2 events in the same time, however this warning can be disregarded or a kernel patch submitted for our scenario. Marcel Apfelbaum (3): hw/pcie: corrected a debug message hw/pcie: implement power controller functionality hw/pcie: better hotplug/hotunplug support hw/pci-bridge/ioh3420.c| 7 + hw/pci-bridge/xio3130_downstream.c | 7 + hw/pci/pcie.c | 64 +- include/hw/i386/pc.h | 11 ++- include/hw/pci/pci.h | 3 ++ include/hw/pci/pcie.h | 2 ++ include/hw/pci/pcie_regs.h | 2 ++ 7 files changed, 88 insertions(+), 8 deletions(-) -- 1.8.3.1
[Qemu-devel] [PATCH v2 1/3] hw/pcie: corrected a debug message
Trivial issue, discovered while debugging.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 02cde6f..ae92f00 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -224,7 +224,7 @@ static void pcie_cap_slot_hotplug_common(PCIDevice
*hotplug_dev,
*exp_cap = hotplug_dev->config + hotplug_dev->exp.exp_cap;
uint16_t sltsta = pci_get_word(*exp_cap + PCI_EXP_SLTSTA);
-PCIE_DEV_PRINTF(PCI_DEVICE(dev), "hotplug state: %d\n", state);
+PCIE_DEV_PRINTF(PCI_DEVICE(dev), "hotplug state: 0x%x\n", sltsta);
if (sltsta & PCI_EXP_SLTSTA_EIS) {
/* the slot is electromechanically locked.
* This error is propagated up to qdev and then to HMP/QMP.
--
1.8.3.1
[Qemu-devel] [PATCH v2 2/3] hw/pcie: implement power controller functionality
It is needed by hot-unplug in order to get an indication
from the OS when the device can be physically detached.
Signed-off-by: Marcel Apfelbaum
---
hw/pci-bridge/ioh3420.c| 7 +++
hw/pci-bridge/xio3130_downstream.c | 7 +++
hw/pci/pcie.c | 33 -
include/hw/i386/pc.h | 11 ++-
include/hw/pci/pci.h | 3 +++
include/hw/pci/pcie.h | 2 ++
include/hw/pci/pcie_regs.h | 2 ++
7 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
index f4e17ac..7cd87fc 100644
--- a/hw/pci-bridge/ioh3420.c
+++ b/hw/pci-bridge/ioh3420.c
@@ -180,6 +180,12 @@ PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool
multifunction,
return PCIE_SLOT(d);
}
+static Property ioh3420_props[] = {
+DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,
+QEMU_PCIE_SLTCAP_PCP_BITNR, true),
+DEFINE_PROP_END_OF_LIST()
+};
+
static const VMStateDescription vmstate_ioh3420 = {
.name = "ioh-3240-express-root-port",
.version_id = 1,
@@ -210,6 +216,7 @@ static void ioh3420_class_init(ObjectClass *klass, void
*data)
dc->desc = "Intel IOH device id 3420 PCIE Root Port";
dc->reset = ioh3420_reset;
dc->vmsd = &vmstate_ioh3420;
+dc->props = ioh3420_props;
}
static const TypeInfo ioh3420_info = {
diff --git a/hw/pci-bridge/xio3130_downstream.c
b/hw/pci-bridge/xio3130_downstream.c
index 8f22f93..51f20d7 100644
--- a/hw/pci-bridge/xio3130_downstream.c
+++ b/hw/pci-bridge/xio3130_downstream.c
@@ -147,6 +147,12 @@ PCIESlot *xio3130_downstream_init(PCIBus *bus, int devfn,
bool multifunction,
return PCIE_SLOT(d);
}
+static Property xio3130_downstream_props[] = {
+DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,
+QEMU_PCIE_SLTCAP_PCP_BITNR, true),
+DEFINE_PROP_END_OF_LIST()
+};
+
static const VMStateDescription vmstate_xio3130_downstream = {
.name = "xio3130-express-downstream-port",
.version_id = 1,
@@ -177,6 +183,7 @@ static void xio3130_downstream_class_init(ObjectClass
*klass, void *data)
dc->desc = "TI X3130 Downstream Port of PCI Express Switch";
dc->reset = xio3130_downstream_reset;
dc->vmsd = &vmstate_xio3130_downstream;
+dc->props = xio3130_downstream_props;
}
static const TypeInfo xio3130_downstream_info = {
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index ae92f00..d6d9eb8 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -294,6 +294,15 @@ void pcie_cap_slot_init(PCIDevice *dev, uint16_t slot)
PCI_EXP_SLTCAP_AIP |
PCI_EXP_SLTCAP_ABP);
+if (dev->cap_present & QEMU_PCIE_SLTCAP_PCP) {
+pci_long_test_and_set_mask(dev->config + pos + PCI_EXP_SLTCAP,
+ PCI_EXP_SLTCAP_PCP);
+pci_word_test_and_clear_mask(dev->config + pos + PCI_EXP_SLTCTL,
+ PCI_EXP_SLTCTL_PCC);
+pci_word_test_and_set_mask(dev->wmask + pos + PCI_EXP_SLTCTL,
+ PCI_EXP_SLTCTL_PCC);
+}
+
pci_word_test_and_clear_mask(dev->config + pos + PCI_EXP_SLTCTL,
PCI_EXP_SLTCTL_PIC |
PCI_EXP_SLTCTL_AIC);
@@ -327,6 +336,10 @@ void pcie_cap_slot_init(PCIDevice *dev, uint16_t slot)
void pcie_cap_slot_reset(PCIDevice *dev)
{
uint8_t *exp_cap = dev->config + dev->exp.exp_cap;
+uint8_t port_type = pcie_cap_get_type(dev);
+
+assert(port_type == PCI_EXP_TYPE_DOWNSTREAM ||
+ port_type == PCI_EXP_TYPE_ROOT_PORT);
PCIE_DEV_PRINTF(dev, "reset\n");
@@ -339,9 +352,27 @@ void pcie_cap_slot_reset(PCIDevice *dev)
PCI_EXP_SLTCTL_PDCE |
PCI_EXP_SLTCTL_ABPE);
pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTCTL,
- PCI_EXP_SLTCTL_PIC_OFF |
PCI_EXP_SLTCTL_AIC_OFF);
+if (dev->cap_present & QEMU_PCIE_SLTCAP_PCP) {
+bool populated;
+uint16_t pic;
+
+/* Downstream ports enforce device number 0. */
+populated = (pci_bridge_get_sec_bus(PCI_BRIDGE(dev))->devices[0] !=
NULL);
+
+if (populated) {
+pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTCTL,
+ PCI_EXP_SLTCTL_PCC);
+} else {
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTCTL,
+ PCI_EXP_SLTCTL_PCC);
+}
+
+pic = populated ? PCI_EXP_SLTCTL_PIC_ON : PCI_EXP_SLTCTL_PIC_OFF;
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTCTL, pic);
+ }
+
pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
Re: [Qemu-devel] [PATCH v2 1/3] hw/pcie: corrected a debug message
On Mon, 2014-06-23 at 14:41 +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 23, 2014 at 02:15:24PM +0300, Marcel Apfelbaum wrote:
> > Trivial issue, discovered while debugging.
> >
> > Signed-off-by: Marcel Apfelbaum
>
> Can you rebase on pci branch pls?
Sure,
Marcel
>
> > ---
> > hw/pci/pcie.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > index 02cde6f..ae92f00 100644
> > --- a/hw/pci/pcie.c
> > +++ b/hw/pci/pcie.c
> > @@ -224,7 +224,7 @@ static void pcie_cap_slot_hotplug_common(PCIDevice
> > *hotplug_dev,
> > *exp_cap = hotplug_dev->config + hotplug_dev->exp.exp_cap;
> > uint16_t sltsta = pci_get_word(*exp_cap + PCI_EXP_SLTSTA);
> >
> > -PCIE_DEV_PRINTF(PCI_DEVICE(dev), "hotplug state: %d\n", state);
> > +PCIE_DEV_PRINTF(PCI_DEVICE(dev), "hotplug state: 0x%x\n", sltsta);
> > if (sltsta & PCI_EXP_SLTSTA_EIS) {
> > /* the slot is electromechanically locked.
> > * This error is propagated up to qdev and then to HMP/QMP.
> > --
> > 1.8.3.1
>
> On Mon, Jun 23, 2014 at 02:15:25PM +0300, Marcel Apfelbaum wrote:
> > It is needed by hot-unplug in order to get an indication
> > from the OS when the device can be physically detached.
> >
> > Signed-off-by: Marcel Apfelbaum
> > ---
> > hw/pci-bridge/ioh3420.c| 7 +++
> > hw/pci-bridge/xio3130_downstream.c | 7 +++
> > hw/pci/pcie.c | 33 -
> > include/hw/i386/pc.h | 11 ++-
> > include/hw/pci/pci.h | 3 +++
> > include/hw/pci/pcie.h | 2 ++
> > include/hw/pci/pcie_regs.h | 2 ++
> > 7 files changed, 63 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
> > index f4e17ac..7cd87fc 100644
> > --- a/hw/pci-bridge/ioh3420.c
> > +++ b/hw/pci-bridge/ioh3420.c
> > @@ -180,6 +180,12 @@ PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool
> > multifunction,
> > return PCIE_SLOT(d);
> > }
> >
> > +static Property ioh3420_props[] = {
> > +DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,
> > +QEMU_PCIE_SLTCAP_PCP_BITNR, true),
> > +DEFINE_PROP_END_OF_LIST()
> > +};
> > +
> > static const VMStateDescription vmstate_ioh3420 = {
> > .name = "ioh-3240-express-root-port",
> > .version_id = 1,
> > @@ -210,6 +216,7 @@ static void ioh3420_class_init(ObjectClass *klass, void
> > *data)
> > dc->desc = "Intel IOH device id 3420 PCIE Root Port";
> > dc->reset = ioh3420_reset;
> > dc->vmsd = &vmstate_ioh3420;
> > +dc->props = ioh3420_props;
> > }
> >
> > static const TypeInfo ioh3420_info = {
> > diff --git a/hw/pci-bridge/xio3130_downstream.c
> > b/hw/pci-bridge/xio3130_downstream.c
> > index 8f22f93..51f20d7 100644
> > --- a/hw/pci-bridge/xio3130_downstream.c
> > +++ b/hw/pci-bridge/xio3130_downstream.c
> > @@ -147,6 +147,12 @@ PCIESlot *xio3130_downstream_init(PCIBus *bus, int
> > devfn, bool multifunction,
> > return PCIE_SLOT(d);
> > }
> >
> > +static Property xio3130_downstream_props[] = {
> > +DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,
> > +QEMU_PCIE_SLTCAP_PCP_BITNR, true),
> > +DEFINE_PROP_END_OF_LIST()
> > +};
> > +
> > static const VMStateDescription vmstate_xio3130_downstream = {
> > .name = "xio3130-express-downstream-port",
> > .version_id = 1,
> > @@ -177,6 +183,7 @@ static void xio3130_downstream_class_init(ObjectClass
> > *klass, void *data)
> > dc->desc = "TI X3130 Downstream Port of PCI Express Switch";
> > dc->reset = xio3130_downstream_reset;
> > dc->vmsd = &vmstate_xio3130_downstream;
> > +dc->props = xio3130_downstream_props;
> > }
> >
> > static const TypeInfo xio3130_downstream_info = {
> > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > index ae92f00..d6d9eb8 100644
> > --- a/hw/pci/pcie.c
> > +++ b/hw/pci/pcie.c
> > @@ -294,6 +294,15 @@ void pcie_cap_slot_init(PCIDevice *dev, uint16_t slot)
> > PCI_EXP_SLTCAP_AIP |
> > PCI_EXP_SLTCAP_ABP);
> >
> > +if (dev->cap_present & QEMU_PCIE_SLTCAP_PCP) {
> > +
[Qemu-devel] [PATCH v3 3/3] hw/pcie: better hotplug/hotunplug support
The current code is broken: it does surprise removal which crashes guests.
Reimplemented the steps:
- Hotplug triggers both 'present detect change' and
'attention button pressed'.
- Hotunplug starts by triggering 'attention button pressed',
then waits for the OS to power off the device and only
then detaches it.
Fixes CVE-2014-3471.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pcie.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index d6d9eb8..da32589 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -258,7 +258,8 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev,
pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
PCI_EXP_SLTSTA_PDS);
-pcie_cap_slot_event(PCI_DEVICE(hotplug_dev), PCI_EXP_HP_EV_PDC);
+pcie_cap_slot_event(PCI_DEVICE(hotplug_dev),
+PCI_EXP_HP_EV_PDC | PCI_EXP_HP_EV_ABP);
}
void pcie_cap_slot_hot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
@@ -268,10 +269,7 @@ void pcie_cap_slot_hot_unplug_cb(HotplugHandler
*hotplug_dev, DeviceState *dev,
pcie_cap_slot_hotplug_common(PCI_DEVICE(hotplug_dev), dev, &exp_cap, errp);
-object_unparent(OBJECT(dev));
-pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
- PCI_EXP_SLTSTA_PDS);
-pcie_cap_slot_event(PCI_DEVICE(hotplug_dev), PCI_EXP_HP_EV_PDC);
+pcie_cap_slot_push_attention_button(PCI_DEVICE(hotplug_dev));
}
/* pci express slot for pci express root/downstream port
@@ -383,6 +381,11 @@ void pcie_cap_slot_reset(PCIDevice *dev)
hotplug_event_update_event_status(dev);
}
+static void pcie_unplug_device(PCIBus *bus, PCIDevice *dev, void *opaque)
+{
+object_unparent(OBJECT(dev));
+}
+
void pcie_cap_slot_write_config(PCIDevice *dev,
uint32_t addr, uint32_t val, int len)
{
@@ -407,6 +410,22 @@ void pcie_cap_slot_write_config(PCIDevice *dev,
sltsta);
}
+/*
+ * If the slot is polulated, power indicator is off and power
+ * controller is off, it is safe to detach the devices.
+ */
+if ((sltsta & PCI_EXP_SLTSTA_PDS) && (val & PCI_EXP_SLTCTL_PCC) &&
+((val & PCI_EXP_SLTCTL_PIC_OFF) == PCI_EXP_SLTCTL_PIC_OFF)) {
+PCIBus *sec_bus = pci_bridge_get_sec_bus(PCI_BRIDGE(dev));
+pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
+pcie_unplug_device, NULL);
+
+pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
+ PCI_EXP_SLTSTA_PDS);
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
+ PCI_EXP_SLTSTA_PDC);
+}
+
hotplug_event_notify(dev);
/*
--
1.8.3.1
[Qemu-devel] [PATCH v3 0/3] hw/pcie: better hotplug/hotunplug support
v2 -> v3: - Rebased the series on PCI branch v1 -> v2: - Addressed Michael S. Tsirkin's comments: - patch 2/3: - Added "power controller present" to compat_props. - patch 3/3: - Unplug all bus functions on hot-unplug, not only function 0. - Minor code refactoring The current code is broken: it does surprise removal which crashes guests. Reimplemented the steps: - Hotplug triggers both 'present detect change' and 'attention button pressed'. - Hotunplug starts by triggering 'attention button pressed', then waits for the OS to power off the device and only then detaches it. Fixes CVE-2014-3471. patch 1/3: trivial debug message fix patch 2/3: enable 'power controller' to receive power events from guests patch 3/3: the actual hotplug/hotunplug implementation. Tested with Linux and Windows guests and with an e1000 with "PCIe" capability. Notes: Windows requires devices to be pci express in order to enable hotplug functionality, so we need to think about converting virtio devices to pci express. Linux outputs a "Surprise Removal/Addition" info message because we trigger 2 events in the same time, however this warning can be disregarded or a kernel patch submitted for our scenario. Marcel Apfelbaum (3): hw/pcie: corrected a debug message hw/pcie: implement power controller functionality hw/pcie: better hotplug/hotunplug support hw/pci-bridge/ioh3420.c| 7 + hw/pci-bridge/xio3130_downstream.c | 7 + hw/pci/pcie.c | 64 +- include/hw/i386/pc.h | 10 +- include/hw/pci/pci.h | 3 ++ include/hw/pci/pcie.h | 2 ++ include/hw/pci/pcie_regs.h | 2 ++ 7 files changed, 87 insertions(+), 8 deletions(-) -- 1.8.3.1
[Qemu-devel] [PATCH v3 1/3] hw/pcie: corrected a debug message
Trivial issue, discovered while debugging.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 02cde6f..ae92f00 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -224,7 +224,7 @@ static void pcie_cap_slot_hotplug_common(PCIDevice
*hotplug_dev,
*exp_cap = hotplug_dev->config + hotplug_dev->exp.exp_cap;
uint16_t sltsta = pci_get_word(*exp_cap + PCI_EXP_SLTSTA);
-PCIE_DEV_PRINTF(PCI_DEVICE(dev), "hotplug state: %d\n", state);
+PCIE_DEV_PRINTF(PCI_DEVICE(dev), "hotplug state: 0x%x\n", sltsta);
if (sltsta & PCI_EXP_SLTSTA_EIS) {
/* the slot is electromechanically locked.
* This error is propagated up to qdev and then to HMP/QMP.
--
1.8.3.1
[Qemu-devel] [PATCH v3 2/3] hw/pcie: implement power controller functionality
It is needed by hot-unplug in order to get an indication
from the OS when the device can be physically detached.
Signed-off-by: Marcel Apfelbaum
---
hw/pci-bridge/ioh3420.c| 7 +++
hw/pci-bridge/xio3130_downstream.c | 7 +++
hw/pci/pcie.c | 33 -
include/hw/i386/pc.h | 10 +-
include/hw/pci/pci.h | 3 +++
include/hw/pci/pcie.h | 2 ++
include/hw/pci/pcie_regs.h | 2 ++
7 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
index f4e17ac..7cd87fc 100644
--- a/hw/pci-bridge/ioh3420.c
+++ b/hw/pci-bridge/ioh3420.c
@@ -180,6 +180,12 @@ PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool
multifunction,
return PCIE_SLOT(d);
}
+static Property ioh3420_props[] = {
+DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,
+QEMU_PCIE_SLTCAP_PCP_BITNR, true),
+DEFINE_PROP_END_OF_LIST()
+};
+
static const VMStateDescription vmstate_ioh3420 = {
.name = "ioh-3240-express-root-port",
.version_id = 1,
@@ -210,6 +216,7 @@ static void ioh3420_class_init(ObjectClass *klass, void
*data)
dc->desc = "Intel IOH device id 3420 PCIE Root Port";
dc->reset = ioh3420_reset;
dc->vmsd = &vmstate_ioh3420;
+dc->props = ioh3420_props;
}
static const TypeInfo ioh3420_info = {
diff --git a/hw/pci-bridge/xio3130_downstream.c
b/hw/pci-bridge/xio3130_downstream.c
index 8f22f93..51f20d7 100644
--- a/hw/pci-bridge/xio3130_downstream.c
+++ b/hw/pci-bridge/xio3130_downstream.c
@@ -147,6 +147,12 @@ PCIESlot *xio3130_downstream_init(PCIBus *bus, int devfn,
bool multifunction,
return PCIE_SLOT(d);
}
+static Property xio3130_downstream_props[] = {
+DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,
+QEMU_PCIE_SLTCAP_PCP_BITNR, true),
+DEFINE_PROP_END_OF_LIST()
+};
+
static const VMStateDescription vmstate_xio3130_downstream = {
.name = "xio3130-express-downstream-port",
.version_id = 1,
@@ -177,6 +183,7 @@ static void xio3130_downstream_class_init(ObjectClass
*klass, void *data)
dc->desc = "TI X3130 Downstream Port of PCI Express Switch";
dc->reset = xio3130_downstream_reset;
dc->vmsd = &vmstate_xio3130_downstream;
+dc->props = xio3130_downstream_props;
}
static const TypeInfo xio3130_downstream_info = {
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index ae92f00..d6d9eb8 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -294,6 +294,15 @@ void pcie_cap_slot_init(PCIDevice *dev, uint16_t slot)
PCI_EXP_SLTCAP_AIP |
PCI_EXP_SLTCAP_ABP);
+if (dev->cap_present & QEMU_PCIE_SLTCAP_PCP) {
+pci_long_test_and_set_mask(dev->config + pos + PCI_EXP_SLTCAP,
+ PCI_EXP_SLTCAP_PCP);
+pci_word_test_and_clear_mask(dev->config + pos + PCI_EXP_SLTCTL,
+ PCI_EXP_SLTCTL_PCC);
+pci_word_test_and_set_mask(dev->wmask + pos + PCI_EXP_SLTCTL,
+ PCI_EXP_SLTCTL_PCC);
+}
+
pci_word_test_and_clear_mask(dev->config + pos + PCI_EXP_SLTCTL,
PCI_EXP_SLTCTL_PIC |
PCI_EXP_SLTCTL_AIC);
@@ -327,6 +336,10 @@ void pcie_cap_slot_init(PCIDevice *dev, uint16_t slot)
void pcie_cap_slot_reset(PCIDevice *dev)
{
uint8_t *exp_cap = dev->config + dev->exp.exp_cap;
+uint8_t port_type = pcie_cap_get_type(dev);
+
+assert(port_type == PCI_EXP_TYPE_DOWNSTREAM ||
+ port_type == PCI_EXP_TYPE_ROOT_PORT);
PCIE_DEV_PRINTF(dev, "reset\n");
@@ -339,9 +352,27 @@ void pcie_cap_slot_reset(PCIDevice *dev)
PCI_EXP_SLTCTL_PDCE |
PCI_EXP_SLTCTL_ABPE);
pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTCTL,
- PCI_EXP_SLTCTL_PIC_OFF |
PCI_EXP_SLTCTL_AIC_OFF);
+if (dev->cap_present & QEMU_PCIE_SLTCAP_PCP) {
+bool populated;
+uint16_t pic;
+
+/* Downstream ports enforce device number 0. */
+populated = (pci_bridge_get_sec_bus(PCI_BRIDGE(dev))->devices[0] !=
NULL);
+
+if (populated) {
+pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTCTL,
+ PCI_EXP_SLTCTL_PCC);
+} else {
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTCTL,
+ PCI_EXP_SLTCTL_PCC);
+}
+
+pic = populated ? PCI_EXP_SLTCTL_PIC_ON : PCI_EXP_SLTCTL_PIC_OFF;
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTCTL, pic);
+ }
+
pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
[Qemu-devel] [SeaBIOS] [PATCH v3] hw/pci: reserve IO and mem for pci express downstream ports with no devices attached
Commit c6e298e1f12e0f4ca02b6da5e42919ae055f6830
hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached
introduced support for hot-plugging devices behind pci-2-pci bridges.
Extend hotplug support also for pci express downstream ports.
Signed-off-by: Marcel Apfelbaum
---
v2 -> v3:
Addressed Michael S. Tsirkin comments:
- Refactored pci_bus_hotplug_support function.
- Removed PCI_EXP_FLAGS_TYPE_SHIFT macro.
v1 -> v2:
Wrong prefix on first patch.
src/fw/pciinit.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 0ad548f..fd5dfb9 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -636,6 +636,36 @@ pci_region_create_entry(struct pci_bus *bus, struct
pci_device *dev,
return entry;
}
+static int pci_bus_hotplug_support(struct pci_bus *bus)
+{
+u8 pcie_cap = pci_find_capability(bus->bus_dev, PCI_CAP_ID_EXP);
+u8 shpc_cap;
+
+if (pcie_cap) {
+u16 pcie_flags = pci_config_readw(bus->bus_dev->bdf,
+ pcie_cap + PCI_EXP_FLAGS);
+u8 port_type = ((pcie_flags & PCI_EXP_FLAGS_TYPE) >>
+ (__builtin_ffs(PCI_EXP_FLAGS_TYPE) - 1));
+u8 downstream_port = (port_type == PCI_EXP_TYPE_DOWNSTREAM) ||
+ (port_type == PCI_EXP_TYPE_ROOT_PORT);
+/*
+ * PCI Express SPEC, 7.8.2:
+ * Slot Implemented – When Set, this bit indicates that the Link
+ * HwInit associated with this Port is connected to a slot (as
+ * compared to being connected to a system-integrated device or
+ * being disabled).
+ * This bit is valid for Downstream Ports. This bit is undefined
+ * for Upstream Ports.
+ */
+u16 slot_implemented = pcie_flags & PCI_EXP_FLAGS_SLOT;
+
+return downstream_port && slot_implemented;
+}
+
+shpc_cap = pci_find_capability(bus->bus_dev, PCI_CAP_ID_SHPC);
+return !!shpc_cap;
+}
+
static int pci_bios_check_devices(struct pci_bus *busses)
{
dprintf(1, "PCI: check devices\n");
@@ -678,7 +708,7 @@ static int pci_bios_check_devices(struct pci_bus *busses)
continue;
struct pci_bus *parent = &busses[pci_bdf_to_bus(s->bus_dev->bdf)];
int type;
-u8 shpc_cap = pci_find_capability(s->bus_dev, PCI_CAP_ID_SHPC);
+int hotplug_support = pci_bus_hotplug_support(s);
for (type = 0; type < PCI_REGION_TYPE_COUNT; type++) {
u64 align = (type == PCI_REGION_TYPE_IO) ?
PCI_BRIDGE_IO_MIN : PCI_BRIDGE_MEM_MIN;
@@ -687,7 +717,7 @@ static int pci_bios_check_devices(struct pci_bus *busses)
if (pci_region_align(&s->r[type]) > align)
align = pci_region_align(&s->r[type]);
u64 sum = pci_region_sum(&s->r[type]);
-if (!sum && shpc_cap)
+if (!sum && hotplug_support)
sum = align; /* reserve min size for hot-plug */
u64 size = ALIGN(sum, align);
int is64 = pci_bios_bridge_region_is64(&s->r[type],
--
1.8.3.1
Re: [Qemu-devel] machines and versions - why so many?
On Mon, 2014-06-23 at 23:41 +0200, Andreas Färber wrote: > Am 23.06.2014 23:35, schrieb Alexey Kardashevskiy: > > Looks like I must copy PC_COMPAT_X_X as PSERIES_COMPAT_X_X starting 1.6 (or > > 1.7 - whichever starts supporting migration well enough on pseries) because > > pretty much of what they do is tweaking PCI devices and we can have all of > > these devices on pseries. And then keep an eye on what is happening in PC > > world to copy same tweaks to pseries as they come. Is that correct? > > Please don't. There's a series by Marcel on the list converting those PC > macros to QOM. Actually, I think you are referring to is Eduardo's series :) http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg03155.html Thanks, Marcel > You already have a QOM sPAPR machine, so you should just > derive new legacy types as needed and override things there. > > Also, -machine *is* the global mechanism we have to tell QEMU which > version you want, it's a shorthand for setting a list of global > properties. Don't forget that QEMU can be used without libvirt, so the > knowledge of which properties to set for which version is kept in QEMU. > > Cheers, > Andreas >
Re: [Qemu-devel] per-machine vs per-qemu-version compat_props macros (was Re: acpi:ich9: add memory hotplug handling)
On Tue, 2014-06-24 at 14:55 -0300, Eduardo Habkost wrote: > On Tue, Jun 24, 2014 at 05:47:53PM +0100, Peter Maydell wrote: > > On 24 June 2014 17:44, Eduardo Habkost wrote: > > > (I would go even further and say that no compat_props bit need to be > > > specific to a machine-type family, and they are simply tied to the code > > > included in a QEMU version. So every PC_COMPAT_* bit could go to a > > > common QEMU_COMPAT_ macro, that could be reusable by all > > > machine-types, and there's no need PC-specific compat macros.) > > > > What if different machines in a particular release had the > > property set to different defaults? > > I never saw that happen, and I don't think it is even likely: default > values set in instance_init, and compat_props are applied just after > instance_init, before object_new() returns. So a machine-type would need > to find a way to change fields after instance_init but before > compat_props are applied. > > Anyway, if a machine-type really needs that, it can still have its own > set of compat macros to implement machine-type-specific compat_props. My > point is that there's no need for that on the PC code today. > +1 As discussed in today's KVM call, compat props per version is the best approach. Thanks, Marcel
Re: [Qemu-devel] [PATCH 3/4] machine: Introduce QEMU_COMPAT_* macros
On Tue, 2014-06-24 at 15:02 -0300, Eduardo Habkost wrote:
> The QEMU_COMPAT_* macros will contain compat properties that are not
> specific to PC, and may be reused by other machine-types.
>
> PC-specific properties were left on the PC_COMPAT_* macros.
>
> Signed-off-by: Eduardo Habkost
> ---
> include/hw/boards.h | 161
> +++
> include/hw/i386/pc.h | 150 ++-
> 2 files changed, 166 insertions(+), 145 deletions(-)
>
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 605a970..709b582 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -134,4 +134,165 @@ struct MachineState {
> const char *cpu_model;
> };
>
> +
> +/* Macros for compat_props corresponding to specific QEMU versions: */
Only a suggestion: Maybe we can move all the compat props to a new header file,
say include/hw/compat.h so we don't need to modify board.h every time we need a
compat prop? board.h will remain cleaner this way.
Thanks,
Marcel
> +
> +#define QEMU_COMPAT_2_0 \
> +{\
> +.driver = "virtio-scsi-pci",\
> +.property = "any_layout",\
> +.value= "off",\
> +},\
> +{\
> +.driver = "apic",\
> +.property = "version",\
> +.value= stringify(0x11),\
> +},\
> +{\
> +.driver = "nec-usb-xhci",\
> +.property = "superspeed-ports-first",\
> +.value= "off",\
> +},\
> +{\
> +.driver = "pci-serial",\
> +.property = "prog_if",\
> +.value= stringify(0),\
> +},\
> +{\
> +.driver = "pci-serial-2x",\
> +.property = "prof_if",\
> +.value= stringify(0),\
> +},\
> +{\
> +.driver = "pci-serial-4x",\
> +.property = "prog_if",\
> +.value= stringify(0),\
> +},\
> +{\
> +.driver = "virtio-net-pci",\
> +.property = "guest_announce",\
> +.value= "off",\
> +}
> +
> +#define QEMU_COMPAT_1_7 \
> +{\
> +.driver = TYPE_USB_DEVICE,\
> +.property = "msos-desc",\
> +.value= "no",\
> +}
> +
> +#define QEMU_COMPAT_1_6 \
> +{\
> +.driver = "e1000",\
> +.property = "mitigation",\
> +.value= "off",\
> +},{\
> +.driver = "qemu64-" TYPE_X86_CPU,\
> +.property = "model",\
> +.value= stringify(2),\
> +},{\
> +.driver = "qemu32-" TYPE_X86_CPU,\
> +.property = "model",\
> +.value= stringify(3),\
> +}
> +
> +#define QEMU_COMPAT_1_5 \
> +{\
> +.driver = "Conroe-" TYPE_X86_CPU,\
> +.property = "model",\
> +.value= stringify(2),\
> +},{\
> +.driver = "Conroe-" TYPE_X86_CPU,\
> +.property = "level",\
> +.value= stringify(2),\
> +},{\
> +.driver = "Penryn-" TYPE_X86_CPU,\
> +.property = "model",\
> +.value= stringify(2),\
> +},{\
> +.driver = "Penryn-" TYPE_X86_CPU,\
> +.property = "level",\
> +.value= stringify(2),\
> +},{\
> +.driver = "Nehalem-" TYPE_X86_CPU,\
> +.property = "model",\
> +.value= stringify(2),\
> +},{\
> +.driver = "Nehalem-" TYPE_X86_CPU,\
> +.property = "level",\
> +.value= stringify(2),\
> +},{\
> +.driver = "virtio-net-pci",\
> +.property = "any_layout",\
> +.value= "off",\
> +},{\
> +.driver = TYPE_X86_CPU,\
> +.property = "pmu",\
> +.value = "on",\
> +}
> +
> +#define QEMU_COMPAT_1_4 \
> +{\
> +.driver = "scsi-hd",\
> +.property = "discard_granularity",\
> +.value= stringify(0),\
> +},{\
> +.driver = "scsi-cd",\
> +.property = "discard_granularity",\
> +.value= stringify(0),\
> +},{\
> +.driver = "scsi-disk",\
> +.property = "discard_granularity",\
> +.value= stringify(0),\
> +},{\
> +.driver = "ide-hd",\
> +.property = "discard_granularity",\
> +.value= stringify(0),\
> +},{\
> +.driver = "ide-cd",\
> +.property = "discard_granularity",\
> +.value= stringify(0),\
> +},{\
> +.driver = "ide-drive",\
> +.property = "discard_granularity",\
> +.value= stringify(0),\
> +},{\
> +.driver = "virtio-blk-pci",\
> +.property = "discard_granularity",\
> +.value= stringify(0),\
> +},{\
> +.driver = "virtio-serial-pci",\
> +.property = "vectors",\
> +/* DEV_NVECTORS_UNSPECIFIED as a uint32_t string */\
> +.value= stringify(0x),\
> +},{ \
> +.driver = "virtio-net-pci", \
> +.property = "ctrl_guest_offloads", \
> +.value= "off", \
> +},{\
> +.driver =
Re: [Qemu-devel] [PATCH 1/4] q35: Move q35-specific compat macros to pc_q35.c
On Tue, 2014-06-24 at 15:02 -0300, Eduardo Habkost wrote:
> They are not used anywhere else, to it is simpler to just keep them
> closer to the places where they are used.
Isolation is always welcomed.
Reviewed-by: Marcel Apfelbaum
>
> Signed-off-by: Eduardo Habkost
> ---
> hw/i386/pc_q35.c | 37 +
> include/hw/i386/pc.h | 37 -
> 2 files changed, 37 insertions(+), 37 deletions(-)
>
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 155db99..c640e7b 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -354,6 +354,22 @@ static QEMUMachine pc_q35_machine_v2_1 = {
> .init = pc_q35_init,
> };
>
> +#define PC_Q35_COMPAT_2_0 \
> +PC_COMPAT_2_0, \
> +{\
> +.driver = "ICH9-LPC",\
> +.property = "memory-hotplug-support",\
> +.value= "off",\
> +},{\
> +.driver = "xio3130-downstream",\
> +.property = COMPAT_PROP_PCP,\
> +.value= "off",\
> +},{\
> +.driver = "ioh3420",\
> +.property = COMPAT_PROP_PCP,\
> +.value= "off",\
> +}
> +
> #define PC_Q35_2_0_MACHINE_OPTIONS PC_Q35_2_1_MACHINE_OPTIONS
>
> static QEMUMachine pc_q35_machine_v2_0 = {
> @@ -366,6 +382,15 @@ static QEMUMachine pc_q35_machine_v2_0 = {
> },
> };
>
> +#define PC_Q35_COMPAT_1_7 \
> +PC_COMPAT_1_7, \
> +PC_Q35_COMPAT_2_0, \
> +{\
> +.driver = "hpet",\
> +.property = HPET_INTCAP,\
> +.value= stringify(4),\
> +}
> +
> #define PC_Q35_1_7_MACHINE_OPTIONS PC_Q35_MACHINE_OPTIONS
>
> static QEMUMachine pc_q35_machine_v1_7 = {
> @@ -378,6 +403,10 @@ static QEMUMachine pc_q35_machine_v1_7 = {
> },
> };
>
> +#define PC_Q35_COMPAT_1_6 \
> +PC_COMPAT_1_6, \
> +PC_Q35_COMPAT_1_7
> +
> #define PC_Q35_1_6_MACHINE_OPTIONS PC_Q35_MACHINE_OPTIONS
>
> static QEMUMachine pc_q35_machine_v1_6 = {
> @@ -390,6 +419,10 @@ static QEMUMachine pc_q35_machine_v1_6 = {
> },
> };
>
> +#define PC_Q35_COMPAT_1_5 \
> +PC_COMPAT_1_5, \
> +PC_Q35_COMPAT_1_6
> +
> static QEMUMachine pc_q35_machine_v1_5 = {
> PC_Q35_1_6_MACHINE_OPTIONS,
> .name = "pc-q35-1.5",
> @@ -400,6 +433,10 @@ static QEMUMachine pc_q35_machine_v1_5 = {
> },
> };
>
> +#define PC_Q35_COMPAT_1_4 \
> +PC_COMPAT_1_4, \
> +PC_Q35_COMPAT_1_5
> +
> #define PC_Q35_1_4_MACHINE_OPTIONS \
> PC_Q35_1_6_MACHINE_OPTIONS, \
> .hot_add_cpu = NULL
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 486e98f..fb7d68d 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -294,43 +294,6 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
> int e820_get_num_entries(void);
> bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
>
> -#define PC_Q35_COMPAT_2_0 \
> -PC_COMPAT_2_0, \
> -{\
> -.driver = "ICH9-LPC",\
> -.property = "memory-hotplug-support",\
> -.value= "off",\
> -},{\
> -.driver = "xio3130-downstream",\
> -.property = COMPAT_PROP_PCP,\
> -.value= "off",\
> -},{\
> -.driver = "ioh3420",\
> -.property = COMPAT_PROP_PCP,\
> -.value= "off",\
> -}
> -
> -#define PC_Q35_COMPAT_1_7 \
> -PC_COMPAT_1_7, \
> -PC_Q35_COMPAT_2_0, \
> -{\
> -.driver = "hpet",\
> -.property = HPET_INTCAP,\
> -.value= stringify(4),\
> -}
> -
> -#define PC_Q35_COMPAT_1_6 \
> -PC_COMPAT_1_6, \
> -PC_Q35_COMPAT_1_7
> -
> -#define PC_Q35_COMPAT_1_5 \
> -PC_COMPAT_1_5, \
> -PC_Q35_COMPAT_1_6
> -
> -#define PC_Q35_COMPAT_1_4 \
> -PC_COMPAT_1_4, \
> -PC_Q35_COMPAT_1_5
> -
> #define PC_COMPAT_2_0 \
> {\
> .driver = "virtio-scsi-pci",\
Re: [Qemu-devel] [PATCH 4/4] [RFC] Eliminate PC-specific compat_props
On Tue, 2014-06-24 at 15:02 -0300, Eduardo Habkost wrote:
> All compat properties are only applied if a device of an specific type
> is instantiated. There's no need to keep a PC-specific list of compat
> properties, as properties for PC-specific devices won't affect other
> machine-types anyway.
So why do we still need 2 sets of hierarchies PC_I440FX_COMPAT_x_y and
PC_Q35_COMPAT_x_y? It seems that QEMU_COMPAT_x_y is enough.
Am I missing something?
Thanks,
Marcel
>
> This patch moves all compat_props properties from PC compat macros, to
> QEMU_COMPAT_*.
>
> In case somebody wonders why the nesting was kept on the
> machine-type-specific PC_*_COMPAT_* macros instead of making
> QEMU_COMPAT_* macros nested. The answer is that making QEMU_COMPAT_*
> nested would make it more difficult to migrate the existing machine-type
> code to QOM later using class_init reuse. See:
>
> https://github.com/ehabkost/qemu-hacks/commit/9edb1f70fc2bd74131f54a2dfed1e890a5859736
>
> PC_COMPAT_1_3 and older are being left untouched by now, as they still
> need some additional cleanup and are unlikely to be reused by new
> machine-types anyway.
>
> Signed-off-by: Eduardo Habkost
> ---
> hw/i386/pc_piix.c| 10 +-
> hw/i386/pc_q35.c | 28 +---
> include/hw/boards.h | 46 ++
> include/hw/i386/pc.h | 43 ---
> 4 files changed, 56 insertions(+), 71 deletions(-)
>
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index d8010d16..5e3d24d 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -442,7 +442,7 @@ static QEMUMachine pc_i440fx_machine_v2_1 = {
> };
>
> #define PC_I440FX_COMPAT_2_0 \
> -PC_COMPAT_2_0
> +QEMU_COMPAT_2_0
>
> #define PC_I440FX_2_0_MACHINE_OPTIONS PC_I440FX_2_1_MACHINE_OPTIONS
>
> @@ -458,7 +458,7 @@ static QEMUMachine pc_i440fx_machine_v2_0 = {
>
> #define PC_I440FX_COMPAT_1_7 \
> PC_I440FX_COMPAT_2_0, \
> -PC_COMPAT_1_7
> +QEMU_COMPAT_1_7
>
> #define PC_I440FX_1_7_MACHINE_OPTIONS PC_I440FX_MACHINE_OPTIONS
>
> @@ -474,7 +474,7 @@ static QEMUMachine pc_i440fx_machine_v1_7 = {
>
> #define PC_I440FX_COMPAT_1_6 \
> PC_I440FX_COMPAT_1_7, \
> -PC_COMPAT_1_6
> +QEMU_COMPAT_1_6
>
> #define PC_I440FX_1_6_MACHINE_OPTIONS PC_I440FX_MACHINE_OPTIONS
>
> @@ -490,7 +490,7 @@ static QEMUMachine pc_i440fx_machine_v1_6 = {
>
> #define PC_I440FX_COMPAT_1_5 \
> PC_I440FX_COMPAT_1_6, \
> -PC_COMPAT_1_5
> +QEMU_COMPAT_1_5
>
> static QEMUMachine pc_i440fx_machine_v1_5 = {
> PC_I440FX_1_6_MACHINE_OPTIONS,
> @@ -504,7 +504,7 @@ static QEMUMachine pc_i440fx_machine_v1_5 = {
>
> #define PC_I440FX_COMPAT_1_4 \
> PC_I440FX_COMPAT_1_5, \
> -PC_COMPAT_1_4
> +QEMU_COMPAT_1_4
>
> #define PC_I440FX_1_4_MACHINE_OPTIONS \
> PC_I440FX_1_6_MACHINE_OPTIONS, \
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 57eecc3..b59d22d 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -355,20 +355,7 @@ static QEMUMachine pc_q35_machine_v2_1 = {
> };
>
> #define PC_Q35_COMPAT_2_0 \
> -PC_COMPAT_2_0, \
> -{\
> -.driver = "ICH9-LPC",\
> -.property = "memory-hotplug-support",\
> -.value= "off",\
> -},{\
> -.driver = "xio3130-downstream",\
> -.property = COMPAT_PROP_PCP,\
> -.value= "off",\
> -},{\
> -.driver = "ioh3420",\
> -.property = COMPAT_PROP_PCP,\
> -.value= "off",\
> -}
> +QEMU_COMPAT_2_0
>
> #define PC_Q35_2_0_MACHINE_OPTIONS PC_Q35_2_1_MACHINE_OPTIONS
>
> @@ -384,12 +371,7 @@ static QEMUMachine pc_q35_machine_v2_0 = {
>
> #define PC_Q35_COMPAT_1_7 \
> PC_Q35_COMPAT_2_0, \
> -PC_COMPAT_1_7, \
> -{\
> -.driver = "hpet",\
> -.property = HPET_INTCAP,\
> -.value= stringify(4),\
> -}
> +QEMU_COMPAT_1_7
>
> #define PC_Q35_1_7_MACHINE_OPTIONS PC_Q35_MACHINE_OPTIONS
>
> @@ -405,7 +387,7 @@ static QEMUMachine pc_q35_machine_v1_7 = {
>
> #define PC_Q35_COMPAT_1_6 \
> PC_Q35_COMPAT_1_7, \
> -PC_COMPAT_1_6
> +QEMU_COMPAT_1_6
>
> #define PC_Q35_1_6_MACHINE_OPTIONS PC_Q35_MACHINE_OPTIONS
>
> @@ -421,7 +403,7 @@ static QEMUMachine pc_q35_machine_v1_6 = {
>
> #define PC_Q35_COMPAT_1_5 \
> PC_Q35_COMPAT_1_6, \
> -PC_COMPAT_1_5
> +QEMU_COMPAT_1_5
>
> static QEMUMachine pc_q35_machine_v1_5 = {
> PC_Q35_1_6_MACHINE_OPTIONS,
> @@ -435,7 +417,7 @@ static QEMUMachine pc_q35_machine_v1_5 = {
>
> #define PC_Q35_COMPAT_1_4 \
> PC_Q35_COMPAT_1_5, \
> -PC_COMPAT_1_4
> +QEMU_COMPAT_1_4
>
> #define PC_Q35_1_4_MACHINE_OPTIONS \
> PC_Q35_1_6_MACHINE_OPTIONS, \
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 709b582..fa7ceb7 1006
Re: [Qemu-devel] [Question] Why doesn't PCIe hotplug work for Q35 machine?
On Sun, 2014-08-17 at 13:00 +0200, Michael S. Tsirkin wrote: > On Fri, Aug 15, 2014 at 07:33:29AM +, Gonglei (Arei) wrote: > > Hi, > > > > I noticed that the qemu-2.1 release change log says > > " PCIe: Basic hot-plug/hot-unplug support for Q35 machine." > > And then I made a testing for the hotplugging function of Q35. > > But I'm failed, and I got the dmesg log in guest os as below: > > > > [ 159.035250] Pciehp :05:00.0:pcie24: Button pressed on Slot (0 - 4) > > [ 159.035274] Pciehp :05:00.0:pcie24: Card present on Slot (0 - 4) > > [ 159.036517] Pciehp :05:00.0:pcie24: PCI slot #0 - 4 - powering on due > > to button press. > > [ 159.188049] Pciehp :05:00.0:pcie24: Failed to check link status > > [ 159.201968] Pciehp :05:00.0:pcie24: Card not present on Slot (0 - 4) > > [ 159.202529] Pciehp :05:00.0:pcie24: Already disabled on Slot (0 - 4) > > > > Steps of testing: > > > > #1. QEMU version: > > > > The lateset master tree source. > > > > #2. Command line: > > > > ./qemu-system-x86_64 -enable-kvm -m 2048 -machine q35 -device > > ide-drive,bus=ide.2,drive=MacHDD \ > > -drive id=MacHDD,if=none,file=/mnt/sdb/gonglei/image/redhat_q35.img > > -monitor stdio -vnc :10 -readconfig ../docs/q35-chipset.cfg > > QEMU 2.0.93 monitor - type 'help' for more information > > (qemu) device_add > > virtio-net-pci,id=nic2,bus=pcie-switch-downstream-port-1-1,addr=1.0 > > I don't think you can use any slot except slot 0 for pci express. Indeed, only slot 0 can be used, try the same without specifying the addr property. > > (qemu) info network > > hub 0 > > \ user.0: index=0,type=user,net=10.0.2.0,restrict=off > > \ e1000.0: index=0,type=nic,model=e1000,macaddr=52:54:00:12:34:56 > > > > #3. Guest OS: > > > > Both rhel-server-7.0-x86_64 and SLES-11-SP3-DVD-x86_64-GM. > > > > #4. Content of ../docs/q35-chipset.cfg: > > > > [snip] > > > > ## > > # Example PCIe switch with two downstream ports > > # > > [device "pcie-switch-upstream-port-1"] > > driver = "x3130-upstream" > > bus = "ich9-pcie-port-4" > > addr = "00.0" > > > > [device "pcie-switch-downstream-port-1-1"] > > driver = "xio3130-downstream" > > multifunction = "on" > > bus = "pcie-switch-upstream-port-1" > > addr = "00.0" > > port = "1" > > chassis = "5" > > > > [device "pcie-switch-downstream-port-1-2"] > > driver = "xio3130-downstream" > > multifunction = "on" > > bus = "pcie-switch-upstream-port-1" > > addr = "00.1" > > port = "1" > > chassis = "6" > > > > [device "ich9-ehci-1"] > > driver = "ich9-usb-ehci1" > > multifunction = "on" > > bus = "pcie.0" > > addr = "1d.7" > > > > [snip] > > > > BTW, except testing hotplug of downstream ports, I also test the root port > > with "device_add virtio-net-pci,id=nic2,bus=ich9-pcie-port-1,addr=1.0", but > > I got the same result. > > Same thing. Agreed, and also make sure that ich9-pcie-port-1 is a root port's bus and not an upstream port's bus. Thanks, Marcel > > > Am I wrong in some places? Or a QEMU bug? Thanks for any help. > > > > Best regards, > > -Gonglei > > > > We might want to add a check for this, to produce a > better error message. >
Re: [Qemu-devel] [PATCH v7] tests/bios-tables-test: check the value returned by fopen()
On Mon, 2014-08-18 at 15:54 +0800, zhanghailiang wrote:
> The function fopen() may fail, so check its return value.
>
> Signed-off-by: zhanghailiang
> Signed-off-by: Li Liu
> Reviewed-by: Alex Bennée
> ---
> tests/bios-tables-test.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
> index 045eb27..feb3b58 100644
> --- a/tests/bios-tables-test.c
> +++ b/tests/bios-tables-test.c
> @@ -790,6 +790,11 @@ int main(int argc, char *argv[])
> const char *arch = qtest_get_arch();
> FILE *f = fopen(disk, "w");
> int ret;
> +
> +if (!f) {
> +fprintf(stderr, "Couldn't open \"%s\": %s", disk, strerror(errno));
> +return -1;
> +}
Hi,
I think we should use an assert here, we need an indication
that the test failed and a print to stderr is not enough.
Thanks,
Marcel
> fwrite(boot_sector, 1, sizeof boot_sector, f);
> fclose(f);
>
Re: [Qemu-devel] [Qemu-trivial] [PATCH v7] tests/bios-tables-test: check the value returned by fopen()
On Mon, 2014-08-18 at 15:37 +0400, Michael Tokarev wrote:
> 18.08.2014 13:13, Marcel Apfelbaum wrote:
> > On Mon, 2014-08-18 at 15:54 +0800, zhanghailiang wrote:
> >> The function fopen() may fail, so check its return value.
> >>
> >> Signed-off-by: zhanghailiang
> >> Signed-off-by: Li Liu
> >> Reviewed-by: Alex Bennée
> >> ---
> >> tests/bios-tables-test.c | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
> >> index 045eb27..feb3b58 100644
> >> --- a/tests/bios-tables-test.c
> >> +++ b/tests/bios-tables-test.c
> >> @@ -790,6 +790,11 @@ int main(int argc, char *argv[])
> >> const char *arch = qtest_get_arch();
> >> FILE *f = fopen(disk, "w");
> >> int ret;
> >> +
> >> +if (!f) {
> >> +fprintf(stderr, "Couldn't open \"%s\": %s", disk,
> >> strerror(errno));
> >> +return -1;
> >> +}
> > Hi,
> > I think we should use an assert here, we need an indication
> > that the test failed and a print to stderr is not enough.
>
> Guys, please stop misusing (or trying to misuse) assert(). assert() is for
> code path which are impossible by program logic. Here, it is a error check,
> not a code logic check -- the fopen() _may_ fail, and this is not something
> the code around makes impossible. So in cases like this (and in other similar
> case like vvfat.log open check), we should either print to stderr and exit,
> or print elsewhere, but we should NOT use assert(). Think what will be if
> the program will be compiled with -D_NDEBUG and all assert()s are turned into
> a no-op.
>
> So, no assert() in cases like this here and elsewhere (not only in qemu). It
> is not what assert() is provided for.
Hi Michael,
Thanks for the reminder, it really helps.
While I agree 100% with your explanation, I was thinking to use
assert only because there would be no reason for the fopen to fail
while creating a file in current directory.
But fopen *may* fail(no writing rights for current directory) and this is an
error check.
Thanks again,
Marcel
>
> Thanks,
>
> /mjt
Re: [Qemu-devel] [PATCH 2/2] pci: add check for pcie root ports and downstream ports
On Tue, 2014-08-19 at 21:08 +0800, arei.gong...@huawei.com wrote:
> From: Gonglei
Hi,
>
> Right now, ARI Forwarding dose not support in QEMU.
I would replace the above sentence with "ARI Forwarding is not supported".
By the way, there is some support for ARI, I don't know if
is enabled yet. I'll have a look.
> According to PCIe spec section 7.3.1, only slot 0 with
> the device attached to logic bus representing the link from
> downstream ports and root ports.
>
> So, adding check about slot 0 for PCIe downstream ports and
> root ports, which avoid useless operation, both hotplug and
> coldplug.
>
> Signed-off-by: Gonglei
> ---
> hw/pci/pci.c | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 351d320..f2d267f 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -773,6 +773,42 @@ static int pci_init_multifunction(PCIBus *bus, PCIDevice
> *dev)
> return 0;
> }
>
> +static int pci_check_pcie_port(PCIBus *bus, PCIDevice *dev)
> +{
> +Object *obj = OBJECT(bus);
> +
> +if (!strcmp(object_get_typename(obj), TYPE_PCIE_BUS)) {
Maybe there is another way to check that this is a PCIe bus?
> +DeviceState *parent = qbus_get_parent(BUS(obj));
> +const char *name = object_get_typename(OBJECT(parent));
> +
> +/*
> + * Root ports and downstream ports of switches are the hot
> + * pluggable ports in a PCI Express hierarchy.
> + * PCI Express supports chip-to-chip interconnect, a PCIe link can
> + * only connect one pci device/Switch/EndPoint or PCI-bridge.
> + *
> + * 7.3. Configuration Transaction Rules (PCI Express specification
> 3.0)
> + * 7.3.1. Device Number
> + *
> + * Downstream Ports that do not have ARI Forwarding enabled must
> + * associate only Device 0 with the device attached to the Logical
> Bus
> + * representing the Link from the Port.
> + *
> + * Right now, ARI Forwarding dose not support. So, only slot 0 is
As above, maybe replace it with "ARI Forwarding is not supported"
> + * supported, regardless of hotplug or coldplug.
> + */
> +if (!strcmp(name, "ioh3420") || !strcmp(name, "xio3130-downstream"))
> {
Please use port_type flag from extended configuration space, don't use device
names.
If you need help for this, let me know.
> +if (PCI_SLOT(dev->devfn) != 0) {
> +error_report("Unsupported PCI slot %d for %s ports, only "
> + "supported slot 0", PCI_SLOT(dev->devfn), name);
> +return -1;
> +}
> +}
> +}
> +
> +return 0;
> +}
> +
> static void pci_config_alloc(PCIDevice *pci_dev)
> {
> int config_size = pci_config_size(pci_dev);
> @@ -871,6 +907,11 @@ static PCIDevice *do_pci_register_device(PCIDevice
> *pci_dev, PCIBus *bus,
> return NULL;
> }
>
> +if (pci_check_pcie_port(bus, pci_dev)) {
> +do_pci_unregister_device(pci_dev);
> +return NULL;
> +}
It is possible to move the above check earlier in do_pci_register_device
function?
Maybe move it into the first if statement(s)?
Thanks,
Marcel
> +
> if (!config_read)
> config_read = pci_default_read_config;
> if (!config_write)
Re: [Qemu-devel] [PATCH] pcihp: fix possible array out of bounds
On Tue, 2014-08-19 at 15:18 +0800, arei.gong...@huawei.com wrote:
> From: Gonglei
>
> When 'bsel == ACPI_PCIHP_MAX_HOTPLUG_BUS', the
> s->acpi_pcihp_pci_status[bsel] array will out of bounds.
I would change the commit message to something like
"Prevent out-of-bounds array access on acpi_pcihp_pci_status.
Other than that, it looks OK to me.
Thanks,
Marcel
>
> Add check for this.
>
> Signed-off-by: Gonglei
> ---
> hw/acpi/pcihp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> index fae663a..34dedf1 100644
> --- a/hw/acpi/pcihp.c
> +++ b/hw/acpi/pcihp.c
> @@ -231,7 +231,7 @@ static uint64_t pci_read(void *opaque, hwaddr addr,
> unsigned int size)
> uint32_t val = 0;
> int bsel = s->hotplug_select;
>
> -if (bsel < 0 || bsel > ACPI_PCIHP_MAX_HOTPLUG_BUS) {
> +if (bsel < 0 || bsel >= ACPI_PCIHP_MAX_HOTPLUG_BUS) {
> return 0;
> }
>
Re: [Qemu-devel] [PATCH v2] pcihp: fix possible array out of bounds
On Wed, 2014-08-20 at 13:52 +0800, arei.gong...@huawei.com wrote:
> From: Gonglei
>
> Prevent out-of-bounds array access on
> acpi_pcihp_pci_status.
>
> Signed-off-by: Gonglei
> Reviewed-by: Peter Crosthwaite
> ---
> v2:
> - change commit message.
> - add 'Reviewed-by'
> ---
> hw/acpi/pcihp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> index fae663a..34dedf1 100644
> --- a/hw/acpi/pcihp.c
> +++ b/hw/acpi/pcihp.c
> @@ -231,7 +231,7 @@ static uint64_t pci_read(void *opaque, hwaddr addr,
> unsigned int size)
> uint32_t val = 0;
> int bsel = s->hotplug_select;
>
> -if (bsel < 0 || bsel > ACPI_PCIHP_MAX_HOTPLUG_BUS) {
> +if (bsel < 0 || bsel >= ACPI_PCIHP_MAX_HOTPLUG_BUS) {
> return 0;
> }
>
Reviewed-by: Marcel Apfelbaum
Re: [Qemu-devel] [PATCH 2/2] pci: add check for pcie root ports and downstream ports
On Wed, 2014-08-20 at 03:20 +, Gonglei (Arei) wrote:
> Hi,
>
> > > Right now, ARI Forwarding dose not support in QEMU.
> > I would replace the above sentence with "ARI Forwarding is not supported".
> >
> OK.
>
> > By the way, there is some support for ARI, I don't know if
> > is enabled yet. I'll have a look.
> >
> MST had pointed out the pcie_ari_init(), but not completed.
>
> > > According to PCIe spec section 7.3.1, only slot 0 with
> > > the device attached to logic bus representing the link from
> > > downstream ports and root ports.
> > >
> > > So, adding check about slot 0 for PCIe downstream ports and
> > > root ports, which avoid useless operation, both hotplug and
> > > coldplug.
> > >
> > > Signed-off-by: Gonglei
> > > ---
> > > hw/pci/pci.c | 41 +
> > > 1 file changed, 41 insertions(+)
> > >
> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > index 351d320..f2d267f 100644
> > > --- a/hw/pci/pci.c
> > > +++ b/hw/pci/pci.c
> > > @@ -773,6 +773,42 @@ static int pci_init_multifunction(PCIBus *bus,
> > PCIDevice *dev)
> > > return 0;
> > > }
> > >
> > > +static int pci_check_pcie_port(PCIBus *bus, PCIDevice *dev)
> > > +{
> > > +Object *obj = OBJECT(bus);
> > > +
> > > +if (!strcmp(object_get_typename(obj), TYPE_PCIE_BUS)) {
> > Maybe there is another way to check that this is a PCIe bus?
> >
> Yes. Paolo has said that object_dynamic_cast() is appropriated.
>
> > > +DeviceState *parent = qbus_get_parent(BUS(obj));
> > > +const char *name = object_get_typename(OBJECT(parent));
> > > +
> > > +/*
> > > + * Root ports and downstream ports of switches are the hot
> > > + * pluggable ports in a PCI Express hierarchy.
> > > + * PCI Express supports chip-to-chip interconnect, a PCIe link
> > > can
> > > + * only connect one pci device/Switch/EndPoint or PCI-bridge.
> > > + *
> > > + * 7.3. Configuration Transaction Rules (PCI Express
> > > specification
> > 3.0)
> > > + * 7.3.1. Device Number
> > > + *
> > > + * Downstream Ports that do not have ARI Forwarding enabled
> > must
> > > + * associate only Device 0 with the device attached to the
> > > Logical
> > Bus
> > > + * representing the Link from the Port.
> > > + *
> > > + * Right now, ARI Forwarding dose not support. So, only slot 0 is
> > As above, maybe replace it with "ARI Forwarding is not supported"
> >
> OK.
>
> > > + * supported, regardless of hotplug or coldplug.
> > > + */
> > > +if (!strcmp(name, "ioh3420") || !strcmp(name,
> > "xio3130-downstream")) {
> > Please use port_type flag from extended configuration space, don't use
> > device
> > names.
> > If you need help for this, let me know.
> >
> Yes, please. I appreciate very much that you can help me.
Sure,
I checked and we already have the pcie_cap_get_type function that returns the
port type.
port_type = pcie_cap_get_type(dev);
if (port_type == PCI_EXP_TYPE_DOWNSTREAM ||
port_type == PCI_EXP_TYPE_ROOT_PORT) {
...
}
Thanks,
Marcel
>
> > > +if (PCI_SLOT(dev->devfn) != 0) {
> > > +error_report("Unsupported PCI slot %d for %s ports,
> > only "
> > > + "supported slot 0",
> > PCI_SLOT(dev->devfn), name);
> > > +return -1;
> > > +}
> > > +}
> > > +}
> > > +
> > > +return 0;
> > > +}
> > > +
> > > static void pci_config_alloc(PCIDevice *pci_dev)
> > > {
> > > int config_size = pci_config_size(pci_dev);
> > > @@ -871,6 +907,11 @@ static PCIDevice
> > *do_pci_register_device(PCIDevice *pci_dev, PCIBus *bus,
> > > return NULL;
> > > }
> > >
> > > +if (pci_check_pcie_port(bus, pci_dev)) {
> > > +do_pci_unregister_device(pci_dev);
> > > +return NULL;
> > > +}
> > It is possible to move the above check earlier in do_pci_register_device
> > function?
> > Maybe move it into the first if statement(s)?
> >
> Agreed, Thanks, Marcel.
>
> Best regards,
> -Gonglei
Re: [Qemu-devel] [PATCH 3/3] ioh3420: Support ARI forwarding
On Wed, 2014-08-20 at 08:53 +0200, Knut Omang wrote:
> Enable the PCIe capability bit that indicates that this port is able to
> support
> and forward requests to > 8 functions for ARI capable devices.
>
> Signed-off-by: Knut Omang
> ---
> hw/pci-bridge/ioh3420.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
> index 8f6c8b0..c14ea6b 100644
> --- a/hw/pci-bridge/ioh3420.c
> +++ b/hw/pci-bridge/ioh3420.c
> @@ -92,8 +92,10 @@ static void ioh3420_reset(DeviceState *qdev)
>
> static int ioh3420_initfn(PCIDevice *d)
> {
> +PCIBridge* br = PCI_BRIDGE(d);
> PCIEPort *p = PCIE_PORT(d);
> PCIESlot *s = PCIE_SLOT(d);
> +uint8_t *exp_cap;
> int rc;
> char tmp[100];
> sprintf(tmp, "pcie_port.%d", s->slot);
> @@ -121,6 +123,10 @@ static int ioh3420_initfn(PCIDevice *d)
> if (rc < 0) {
> goto err_msi;
> }
> +/* Support ARI forwarding */
> +exp_cap = d->config + d->exp.exp_cap;
> +pci_word_test_and_set_mask(exp_cap + PCI_EXP_DEVCAP2,
> PCI_EXP_DEVCAP2_ARI);
> +
Hi,
I think is better to move the implementation to a function, say
pcie_cap_ari_init
and place it into hw/pci/pcie.c so other devices like downstream ports can use
it.
Thanks,
Marcel
> pcie_cap_deverr_init(d);
> pcie_cap_slot_init(d, s->slot);
> pcie_chassis_create(s->chassis);
> @@ -151,6 +157,7 @@ err_bridge:
> static void ioh3420_exitfn(PCIDevice *d)
> {
> PCIESlot *s = PCIE_SLOT(d);
> +PCIBridge* br = PCI_BRIDGE(d);
>
> pcie_aer_exit(d);
> pcie_chassis_del_slot(s);
Re: [Qemu-devel] [PATCH 1/3] pcie: Fix next function setting
On Wed, 2014-08-20 at 08:52 +0200, Knut Omang wrote:
> PCI_ARI_CAP_NFN is for reading next function not writing it
The commit message is not so clear, maybe something like
"Fix incorrect write to ari capability
or similar?
Other than that the patch looks OK to me.
Thanks,
Marcel
>
> Signed-off-by: Knut Omang
> ---
> hw/pci/pcie.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> index a123c01..de0e967 100644
> --- a/hw/pci/pcie.c
> +++ b/hw/pci/pcie.c
> @@ -630,5 +630,5 @@ void pcie_ari_init(PCIDevice *dev, uint16_t offset,
> uint16_t nextfn)
> {
> pcie_add_capability(dev, PCI_EXT_CAP_ID_ARI, PCI_ARI_VER,
> offset, PCI_ARI_SIZEOF);
> -pci_set_long(dev->config + offset + PCI_ARI_CAP,
> PCI_ARI_CAP_NFN(nextfn));
> +pci_set_long(dev->config + offset + PCI_ARI_CAP, (nextfn & 0xff) << 8);
> }
Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root ports and downstream ports
On Thu, 2014-08-21 at 17:47 +0800, arei.gong...@huawei.com wrote:
> From: Gonglei
>
> If ARI Forwarding is disabled, according to PCIe spec
> section 7.3.1, only slot 0 with the device attached to
> logic bus representing the link from downstream
> ports and root ports.
>
> So, adding check for PCIe downstream ports and root ports,
> which avoid useless operation, both hotplug and coldplug.
>
> Signed-off-by: Gonglei
> ---
> hw/pci/pci.c | 51 +++
> 1 file changed, 51 insertions(+)
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index daeaeac..aa0af0c 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -773,6 +773,52 @@ static int pci_init_multifunction(PCIBus *bus, PCIDevice
> *dev)
> return 0;
> }
>
> +static int pci_check_pcie_port(PCIBus *bus, PCIDevice *dev)
Hi,
This function is specific to pcie, I think it should be placed
in hw/pci/pcie.c. hw/pci/pci.c is for general pci functionality.
Other thing, I think the function name does not completely match
the functionality, maybe "pcie_check_slot" or "pcie_validate_slot"?
Thanks,
Marcel
> +{
> +Object *obj = OBJECT(bus);
> +
> +if (pci_bus_is_root(bus)) {
> +return 0;
> +}
> +
> +if (object_dynamic_cast(obj, TYPE_PCIE_BUS)) {
> +DeviceState *parent = qbus_get_parent(BUS(obj));
> +PCIDevice *pci_dev = PCI_DEVICE(parent);
> +uint8_t port_type;
> +/*
> + * Root ports and downstream ports of switches are the hot
> + * pluggable ports in a PCI Express hierarchy.
> + * PCI Express supports chip-to-chip interconnect, a PCIe link can
> + * only connect one pci device/Switch/EndPoint or PCI-bridge.
> + *
> + * 7.3. Configuration Transaction Rules (PCI Express specification
> 3.0)
> + * 7.3.1. Device Number
> + *
> + * Downstream Ports that do not have ARI Forwarding enabled must
> + * associate only Device 0 with the device attached to the Logical
> Bus
> + * representing the Link from the Port.
> + *
> + * If ARI Forwarding is not enabled on root ports and downstream
> + * ports, only support the devices with slot non-0, regardless of
> + * hotplug or coldplug.
> + */
> +port_type = pcie_cap_get_type(pci_dev);
> +if (port_type == PCI_EXP_TYPE_DOWNSTREAM ||
> +port_type == PCI_EXP_TYPE_ROOT_PORT) {
> +if (!pcie_cap_is_ari_enabled(pci_dev)) {
> +if (PCI_SLOT(dev->devfn) != 0) {
> +error_report("PCIe: Port's ARI Forwarding is disabled, "
> + "device can't be populated in slot %d",
> + PCI_SLOT(dev->devfn));
> +return -1;
> +}
> +}
> +}
> +}
> +
> +return 0;
> +}
> +
> static void pci_config_alloc(PCIDevice *pci_dev)
> {
> int config_size = pci_config_size(pci_dev);
> @@ -827,6 +873,11 @@ static PCIDevice *do_pci_register_device(PCIDevice
> *pci_dev, PCIBus *bus,
>
> pci_dev->bus = bus;
> pci_dev->devfn = devfn;
> +
> +if (pci_check_pcie_port(bus, pci_dev)) {
> +return NULL;
> +}
> +
> dma_as = pci_device_iommu_address_space(pci_dev);
>
> memory_region_init_alias(&pci_dev->bus_master_enable_region,
[Qemu-devel] [PATCH 1/2] qemu-help: Sort devices by logical functionality
Categorize devices that appear as output to "-device ?" command
by logical functionality. Sort the devices by logical categories
before showing them to user.
The sort is done by functionality rather than alphabetical.
Signed-off-by: Marcel Apfelbaum
---
Changes from RFC
Made category a bitmap to support multifunction PCI devices
include/hw/qdev-core.h | 15
qdev-monitor.c | 62 --
2 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 7fbffcb..9130f97 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -17,6 +17,19 @@ enum {
#define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
TYPE_DEVICE)
#define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj), TYPE_DEVICE)
+#define MAX_DEVICE_CATEGORY 8
+
+typedef enum DeviceCategory {
+DEVICE_CATEGORY_ASSEMBLY,
+DEVICE_CATEGORY_MANAGEMENT,
+DEVICE_CATEGORY_STORAGE,
+DEVICE_CATEGORY_NETWORK,
+DEVICE_CATEGORY_INPUT,
+DEVICE_CATEGORY_DISPLAY,
+DEVICE_CATEGORY_SOUND,
+DEVICE_CATEGORY_MISC,
+} DeviceCategory;
+
typedef int (*qdev_initfn)(DeviceState *dev);
typedef int (*qdev_event)(DeviceState *dev);
typedef void (*qdev_resetfn)(DeviceState *dev);
@@ -80,6 +93,8 @@ typedef struct DeviceClass {
ObjectClass parent_class;
/*< public >*/
+/* DeviceCategory bitmap */
+unsigned int categories;
const char *fw_name;
const char *desc;
Property *props;
diff --git a/qdev-monitor.c b/qdev-monitor.c
index e54dbc2..2e6d14e 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -51,6 +51,18 @@ static const QDevAlias qdev_alias_table[] = {
{ }
};
+/* Category names corresponding to DeviceCategory values */
+static const char *qdev_category_names[] = {
+"Assembly",
+"Management",
+"Storage",
+"Network",
+"Input",
+"Display",
+"Sound",
+"Misc",
+};
+
static const char *qdev_class_get_alias(DeviceClass *dc)
{
const char *typename = object_class_get_name(OBJECT_CLASS(dc));
@@ -75,11 +87,20 @@ static bool qdev_class_has_alias(DeviceClass *dc)
return (qdev_class_get_alias(dc) != NULL);
}
+typedef struct PrintDevInfoData {
+bool *show_no_user;
+DeviceCategory *category;
+} PrintDevInfoData ;
+
static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
{
DeviceClass *dc;
-bool *show_no_user = opaque;
+PrintDevInfoData *data = opaque;
+bool *show_no_user;
+DeviceCategory category;
+show_no_user = data ? data->show_no_user : NULL;
+category = data && data->category ? *data->category : 0;
dc = (DeviceClass *)object_class_dynamic_cast(klass, TYPE_DEVICE);
if (!dc || (show_no_user && !*show_no_user && dc->no_user)) {
@@ -93,6 +114,18 @@ static void qdev_print_devinfo(ObjectClass *klass, void
*opaque)
if (qdev_class_has_alias(dc)) {
error_printf(", alias \"%s\"", qdev_class_get_alias(dc));
}
+if (dc->categories) {
+if (dc->categories & (1 << category)) {
+error_printf(", category \"%s\"", qdev_category_names[category]);
+} else {
+error_printf(", categories");
+for (category = 0; category < MAX_DEVICE_CATEGORY; ++category) {
+if (dc->categories & (1 << category)) {
+error_printf(" \"%s\"", qdev_category_names[category]);
+}
+}
+}
+}
if (dc->desc) {
error_printf(", desc \"%s\"", dc->desc);
}
@@ -139,6 +172,23 @@ static const char *find_typename_by_alias(const char
*alias)
return NULL;
}
+static GSList *qdev_get_devices_by_category(unsigned long categories)
+{
+DeviceClass *dc;
+GSList *list, *curr, *ret_list = NULL;
+
+list = object_class_get_list(TYPE_DEVICE, false);
+for (curr = list; curr; curr = g_slist_next(curr)) {
+dc = (DeviceClass *)object_class_dynamic_cast(curr->data, TYPE_DEVICE);
+if ((dc->categories & categories) == categories) {
+ret_list = g_slist_append(ret_list, dc);
+}
+}
+g_slist_free(list);
+
+return ret_list;
+}
+
int qdev_device_help(QemuOpts *opts)
{
const char *driver;
@@ -148,7 +198,15 @@ int qdev_device_help(QemuOpts *opts)
driver = qemu_opt_get(opts, "driver");
if (driver && is_help_option(driver)) {
bool show_no_user = false;
-object_class_foreach(qdev_print_devinfo, TYPE_DEVICE, false,
&show_no_user);
+DeviceCategory category;
+PrintDevInfoData data = { &show_no_user, &category };
+
+for (category = 0; category < MAX_DEVICE_CATEGORY; ++category) {
+GSList *list = qdev_get_devices_by_category(1 << category);
+g_slist_foreach(list, (GFunc)qdev_print_devinfo, &data);
+g_slist_free(list);
+}
+
return 1;
}
--
1.8.3.1
[Qemu-devel] [PATCH 0/2] qemu-help: improve -device command line help
Running qemu with "-device ?" option returns ~145 lines. It is hard to manage understanding the output. Theses patches aim to partially solve the problem by dividing the devices into logical categories like "Network/Display/..." and sorting them by it. Categories: Assembly - hosts/hubs/... Management - controllers ... (All others are self explanatory) Changes from RFC patch: Made category a bitmap to support multifunction PCI devices. Assigned all devices to their category. Marcel Apfelbaum (2): qemu-help: Sort devices by logical functionality devices: Associate devices to their logical category hw/9pfs/virtio-9p-device.c | 1 + hw/audio/ac97.c| 1 + hw/audio/adlib.c | 1 + hw/audio/cs4231a.c | 1 + hw/audio/es1370.c | 1 + hw/audio/gus.c | 1 + hw/audio/hda-codec.c | 3 ++ hw/audio/intel-hda.c | 3 ++ hw/audio/pcspk.c | 1 + hw/audio/pl041.c | 1 + hw/audio/sb16.c| 1 + hw/block/fdc.c | 3 ++ hw/block/nvme.c| 1 + hw/block/pc_sysfw.c| 1 + hw/block/pflash_cfi01.c| 1 + hw/block/virtio-blk.c | 1 + hw/char/imx_serial.c | 1 + hw/char/ipack.c| 1 + hw/char/ipoctal232.c | 1 + hw/char/parallel.c | 1 + hw/char/serial-isa.c | 1 + hw/char/serial-pci.c | 3 ++ hw/char/tpci200.c | 1 + hw/char/virtio-serial-bus.c| 2 ++ hw/core/sysbus.c | 1 + hw/display/cirrus_vga.c| 2 ++ hw/display/g364fb.c| 1 + hw/display/pl110.c | 3 ++ hw/display/qxl.c | 2 ++ hw/display/vga-isa.c | 1 + hw/display/vga-pci.c | 1 + hw/display/vmware_vga.c| 1 + hw/i2c/bitbang_i2c.c | 1 + hw/i2c/core.c | 1 + hw/i386/kvm/pci-assign.c | 1 + hw/ide/ahci.c | 1 + hw/ide/ich.c | 1 + hw/ide/isa.c | 1 + hw/ide/piix.c | 3 ++ hw/ide/qdev.c | 1 + hw/ide/via.c | 1 + hw/isa/i82378.c| 1 + hw/isa/isa-bus.c | 1 + hw/isa/lpc_ich9.c | 1 + hw/isa/vt82c686.c | 3 ++ hw/misc/applesmc.c | 1 + hw/misc/debugexit.c| 1 + hw/misc/ivshmem.c | 1 + hw/misc/pc-testdev.c | 1 + hw/misc/pci-testdev.c | 1 + hw/misc/sga.c | 1 + hw/misc/vfio.c | 1 + hw/net/e1000.c | 1 + hw/net/eepro100.c | 1 + hw/net/lance.c | 1 + hw/net/mipsnet.c | 1 + hw/net/ne2000-isa.c| 1 + hw/net/ne2000.c| 1 + hw/net/opencores_eth.c | 1 + hw/net/pcnet-pci.c | 1 + hw/net/rtl8139.c | 1 + hw/net/virtio-net.c| 1 + hw/net/vmxnet3.c | 1 + hw/pci-bridge/i82801b11.c | 2 ++ hw/pci-bridge/ioh3420.c| 1 + hw/pci-bridge/pci_bridge_dev.c | 1 + hw/pci-bridge/xio3130_downstream.c | 1 + hw/pci-bridge/xio3130_upstream.c | 1 + hw/pci-host/apb.c | 2 ++ hw/pci-host/ppce500.c | 1 + hw/pci-host/prep.c | 1 + hw/pci-host/q35.c | 2 ++ hw/scsi/esp-pci.c | 2 ++ hw/scsi/esp.c | 1 + hw/scsi/lsi53c895a.c | 1 + hw/scsi/megasas.c | 1 + hw/scsi/scsi-bus.c | 1 + hw/scsi/vhost-scsi.c | 1 + hw/scsi/virtio-scsi.c | 3 ++ hw/scsi/vmw_pvscsi.c | 1 + hw/usb/ccid-card-emulated.c| 1 + hw/usb/ccid-card-passthru.c| 1 + hw/usb/dev-audio.c | 1 + hw/usb/dev-bluetooth.c | 1 + hw/usb/dev-hid.c | 3 ++ hw/usb/dev-hub.c | 1 + hw/usb/dev-network.c | 1 + hw/usb/dev-serial.c| 2 ++ hw/usb/dev-smartcard-reader.c | 2 ++ hw/usb/dev-storage.c | 1 + hw/usb/dev-uas.c | 1 + hw/usb/dev-wacom.c | 1 + hw/usb/hcd-ehci-pci.c | 2 ++ hw/usb/hcd-ehci-sysbus.c | 8 + hw/usb/hcd-ohci.c | 2 ++ hw/usb/hcd-uhci.c | 1 + hw/usb/hcd-xhci.c | 1 + hw/usb/host-libusb.c | 1 + hw/usb/host-linux.c| 1 + hw/usb/redirect.c | 1 + hw/virtio/virtio-balloon.c
[Qemu-devel] [PATCH v2 0/3] qemu-help: improve -device command line help
Running qemu with "-device ?" option returns ~145 lines. It is hard to manage understanding the output. Theses patches aim to partially solve the problem by dividing the devices into logical categories like "Network/Display/..." and sorting them by it. Categories: Assembly - hosts/hubs/... Management - controllers ... (All others are self explanatory) Changes from v1: Addressed Michael Tsirkin review: Used bitmap operations on categories Moved category names into the header file Changes from RFC patch: Made category a bitmap to support multifunction PCI devices. Assigned all devices to their category. Marcel Apfelbaum (3): hw: import bitmap operations in qdev-core header qemu-help: Sort devices by logical functionality devices: Associate devices to their logical category hw/9pfs/virtio-9p-device.c | 1 + hw/audio/ac97.c| 1 + hw/audio/adlib.c | 1 + hw/audio/cs4231a.c | 1 + hw/audio/es1370.c | 1 + hw/audio/gus.c | 1 + hw/audio/hda-codec.c | 3 +++ hw/audio/intel-hda.c | 3 +++ hw/audio/pcspk.c | 1 + hw/audio/pl041.c | 1 + hw/audio/sb16.c| 1 + hw/block/fdc.c | 3 +++ hw/block/nvme.c| 1 + hw/block/pc_sysfw.c| 1 + hw/block/pflash_cfi01.c| 1 + hw/block/virtio-blk.c | 1 + hw/char/debugcon.c | 1 + hw/char/imx_serial.c | 1 + hw/char/ipack.c| 1 + hw/char/ipoctal232.c | 1 + hw/char/parallel.c | 1 + hw/char/serial-isa.c | 1 + hw/char/serial-pci.c | 3 +++ hw/char/tpci200.c | 1 + hw/char/virtio-serial-bus.c| 2 ++ hw/core/qdev-properties.c | 4 +-- hw/cpu/icc_bus.c | 8 ++ hw/display/cirrus_vga.c| 2 ++ hw/display/g364fb.c| 1 + hw/display/pl110.c | 3 +++ hw/display/qxl.c | 2 ++ hw/display/vga-isa.c | 1 + hw/display/vga-pci.c | 1 + hw/display/vmware_vga.c| 1 + hw/i2c/bitbang_i2c.c | 1 + hw/i2c/core.c | 1 + hw/i386/kvm/pci-assign.c | 1 + hw/ide/ahci.c | 1 + hw/ide/ich.c | 1 + hw/ide/isa.c | 1 + hw/ide/piix.c | 3 +++ hw/ide/qdev.c | 1 + hw/ide/via.c | 1 + hw/isa/i82378.c| 1 + hw/isa/lpc_ich9.c | 1 + hw/isa/vt82c686.c | 3 +++ hw/misc/applesmc.c | 1 + hw/misc/debugexit.c| 1 + hw/misc/ivshmem.c | 1 + hw/misc/pc-testdev.c | 1 + hw/misc/pci-testdev.c | 1 + hw/misc/sga.c | 1 + hw/misc/vfio.c | 1 + hw/net/e1000.c | 1 + hw/net/eepro100.c | 2 +- hw/net/lance.c | 1 + hw/net/mipsnet.c | 1 + hw/net/ne2000-isa.c| 1 + hw/net/ne2000.c| 1 + hw/net/opencores_eth.c | 1 + hw/net/pcnet-pci.c | 1 + hw/net/rtl8139.c | 1 + hw/net/virtio-net.c| 1 + hw/net/vmxnet3.c | 1 + hw/pci-bridge/i82801b11.c | 2 ++ hw/pci-bridge/ioh3420.c| 1 + hw/pci-bridge/pci_bridge_dev.c | 1 + hw/pci-bridge/xio3130_downstream.c | 1 + hw/pci-bridge/xio3130_upstream.c | 1 + hw/pci-host/apb.c | 2 ++ hw/pci-host/ppce500.c | 1 + hw/pci-host/prep.c | 1 + hw/pci-host/q35.c | 2 ++ hw/scsi/esp-pci.c | 2 ++ hw/scsi/esp.c | 1 + hw/scsi/lsi53c895a.c | 1 + hw/scsi/megasas.c | 1 + hw/scsi/scsi-bus.c | 1 + hw/scsi/vhost-scsi.c | 1 + hw/scsi/virtio-scsi.c | 3 +++ hw/scsi/vmw_pvscsi.c | 1 + hw/usb/ccid-card-emulated.c| 1 + hw/usb/ccid-card-passthru.c| 1 + hw/usb/dev-audio.c | 1 + hw/usb/dev-bluetooth.c | 1 + hw/usb/dev-hid.c | 3 +++ hw/usb/dev-hub.c | 1 + hw/usb/dev-network.c | 1 + hw/usb/dev-serial.c| 2 ++ hw/usb/dev-smartcard-reader.c | 1 + hw/usb/dev-storage.c | 1 + hw/usb/dev-uas.c | 1 + hw/usb/dev-wacom.c | 1 + hw/usb/hcd-ehci-pci.c | 2 ++ hw/usb/hcd-ehci-sysbus.c | 9 +++ hw/usb/hcd-ohci.c | 2 +
[Qemu-devel] [PATCH v2 1/3] hw: import bitmap operations in qdev-core header
Made small tweaks in code to prevent compilation issues
when importing qemu/bitmap.h in qdev-core
Signed-off-by: Marcel Apfelbaum
---
hw/core/qdev-properties.c | 4 ++--
hw/net/eepro100.c | 1 -
include/hw/qdev-core.h| 1 +
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index 3a324fb..01b27eb 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -91,7 +91,7 @@ static void get_bit(Object *obj, Visitor *v, void *opaque,
visit_type_bool(v, &value, name, errp);
}
-static void set_bit(Object *obj, Visitor *v, void *opaque,
+static void prop_set_bit(Object *obj, Visitor *v, void *opaque,
const char *name, Error **errp)
{
DeviceState *dev = DEVICE(obj);
@@ -117,7 +117,7 @@ PropertyInfo qdev_prop_bit = {
.legacy_name = "on/off",
.print = print_bit,
.get = get_bit,
-.set = set_bit,
+.set = prop_set_bit,
};
/* --- bool --- */
diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index e0befb2..3dc4937 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -105,7 +105,6 @@
#define PCI_IO_SIZE 64
#define PCI_FLASH_SIZE (128 * KiB)
-#define BIT(n) (1 << (n))
#define BITS(n, m) (((0xU << (31 - n)) >> (31 - n + m)) << m)
/* The SCB accepts the following controls for the Tx and Rx units: */
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 7fbffcb..e8b89b1 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -4,6 +4,7 @@
#include "qemu/queue.h"
#include "qemu/option.h"
#include "qemu/typedefs.h"
+#include "qemu/bitmap.h"
#include "qom/object.h"
#include "hw/irq.h"
#include "qapi/error.h"
--
1.8.3.1
[Qemu-devel] [PATCH v2 2/3] qemu-help: Sort devices by logical functionality
Categorize devices that appear as output to "-device ?" command
by logical functionality. Sort the devices by logical categories
before showing them to user.
The sort is done by functionality rather than alphabetical.
Signed-off-by: Marcel Apfelbaum
---
Changes from v1:
Addressed Michael Tsirkin review:
Used bitmap operations on categories
Moved category names into the header file
include/hw/qdev-core.h | 33 +
qdev-monitor.c | 50 ++
2 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index e8b89b1..80b06ac 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -18,6 +18,38 @@ enum {
#define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
TYPE_DEVICE)
#define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj), TYPE_DEVICE)
+typedef enum DeviceCategory {
+DEVICE_CATEGORY_ASSEMBLY,
+DEVICE_CATEGORY_MANAGEMENT,
+DEVICE_CATEGORY_STORAGE,
+DEVICE_CATEGORY_NETWORK,
+DEVICE_CATEGORY_INPUT,
+DEVICE_CATEGORY_DISPLAY,
+DEVICE_CATEGORY_SOUND,
+DEVICE_CATEGORY_MISC,
+DEVICE_CATEGORY_MAX
+} DeviceCategory;
+
+static inline const char *qdev_category_get_name(DeviceCategory category)
+{
+/* Category names corresponding to DeviceCategory values
+ * The array elements must be in the same order as they
+ * appear in DeviceCategory enum.
+ */
+static const char *category_names[] = {
+"Assembly",
+"Management",
+"Storage",
+"Network",
+"Input",
+"Display",
+"Sound",
+"Misc",
+};
+
+return category_names[category];
+}
+
typedef int (*qdev_initfn)(DeviceState *dev);
typedef int (*qdev_event)(DeviceState *dev);
typedef void (*qdev_resetfn)(DeviceState *dev);
@@ -81,6 +113,7 @@ typedef struct DeviceClass {
ObjectClass parent_class;
/*< public >*/
+DECLARE_BITMAP(categories, 20);
const char *fw_name;
const char *desc;
Property *props;
diff --git a/qdev-monitor.c b/qdev-monitor.c
index e54dbc2..c3a3550 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -75,14 +75,21 @@ static bool qdev_class_has_alias(DeviceClass *dc)
return (qdev_class_get_alias(dc) != NULL);
}
+typedef struct PrintDevInfoData {
+bool show_no_user;
+DeviceCategory category;
+} PrintDevInfoData ;
+
static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
{
DeviceClass *dc;
-bool *show_no_user = opaque;
+PrintDevInfoData *data = opaque;
+DeviceCategory category;
+category = data ? data->category : DEVICE_CATEGORY_MAX;
dc = (DeviceClass *)object_class_dynamic_cast(klass, TYPE_DEVICE);
-if (!dc || (show_no_user && !*show_no_user && dc->no_user)) {
+if (!dc || (data && !data->show_no_user && dc->no_user)) {
return;
}
@@ -93,6 +100,18 @@ static void qdev_print_devinfo(ObjectClass *klass, void
*opaque)
if (qdev_class_has_alias(dc)) {
error_printf(", alias \"%s\"", qdev_class_get_alias(dc));
}
+if (dc->categories) {
+if (test_bit(category, dc->categories)) {
+error_printf(", category \"%s\"",
qdev_category_get_name(category));
+} else {
+error_printf(", categories");
+for (category = 0; category < DEVICE_CATEGORY_MAX; ++category) {
+if (test_bit(category, dc->categories)) {
+error_printf(" \"%s\"", qdev_category_get_name(category));
+}
+}
+}
+}
if (dc->desc) {
error_printf(", desc \"%s\"", dc->desc);
}
@@ -139,6 +158,23 @@ static const char *find_typename_by_alias(const char
*alias)
return NULL;
}
+static GSList *qdev_get_devices_by_category(DeviceCategory category)
+{
+DeviceClass *dc;
+GSList *list, *curr, *ret_list = NULL;
+
+list = object_class_get_list(TYPE_DEVICE, false);
+for (curr = list; curr; curr = g_slist_next(curr)) {
+dc = (DeviceClass *)object_class_dynamic_cast(curr->data, TYPE_DEVICE);
+if (test_bit(category, dc->categories)) {
+ret_list = g_slist_append(ret_list, dc);
+}
+}
+g_slist_free(list);
+
+return ret_list;
+}
+
int qdev_device_help(QemuOpts *opts)
{
const char *driver;
@@ -147,8 +183,14 @@ int qdev_device_help(QemuOpts *opts)
driver = qemu_opt_get(opts, "driver");
if (driver && is_help_option(driver)) {
-bool show_no_user = false;
-object_class_foreach(qdev_print_devinfo, TYPE_DEVICE, false,
&show_no_user);
+DeviceCategory category;
+for (category =
Re: [Qemu-devel] [PATCH 0/2] qemu-help: improve -device command line help
On Mon, 2013-07-29 at 09:36 +0200, Paolo Bonzini wrote:
> Il 28/07/2013 11:14, Marcel Apfelbaum ha scritto:
> > Categories:
> > Assembly - hosts/hubs/...
>
> A lot of these seem to fit in a "bridge" category.
I wanted to group in a category as much as possible having in
mind the user shall "grep" by category to find devices.
My goal is a top category with devices that are not nodes and
are used as a way to combine other devices.
>
> I'm not sure why usbhost is in the assembly category though. Also, why
> is this the default category for isa and i2c devices?
The same argument as above. I am looking for top devices and not for
their type
>
> > Management - controllers
>
> AHCI is storage.
Thanks, it looked like management to me.
Devices in management category shall control other devices.
It looked like a fit for me.
>
> applesmc is something like a microcontroller ("misc"?).
Thanks, I'll move to misc
>
> Everything else in this category is USB host controllers, I think it
> deserves a special category since USB devices are generally somewhat
> self-explanatory (hubs too).
I didn't want to include the "USB" keyword, because the user will be lost
when filtering by this word. The goal is to help the user to concentrate
on a specific "category". Maybe USB-Controller ?
>
> Paolo
Thanks for the review!
Marcel
Re: [Qemu-devel] [PATCH v2 1/3] hw: import bitmap operations in qdev-core header
On Mon, 2013-07-29 at 10:42 +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 29, 2013 at 10:07:33AM +0300, Marcel Apfelbaum wrote:
> > Made small tweaks in code to prevent compilation issues
> > when importing qemu/bitmap.h in qdev-core
> >
> > Signed-off-by: Marcel Apfelbaum
> > ---
> > hw/core/qdev-properties.c | 4 ++--
> > hw/net/eepro100.c | 1 -
> > include/hw/qdev-core.h| 1 +
> > 3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
> > index 3a324fb..01b27eb 100644
> > --- a/hw/core/qdev-properties.c
> > +++ b/hw/core/qdev-properties.c
> > @@ -91,7 +91,7 @@ static void get_bit(Object *obj, Visitor *v, void *opaque,
> > visit_type_bool(v, &value, name, errp);
> > }
> >
> > -static void set_bit(Object *obj, Visitor *v, void *opaque,
> > +static void prop_set_bit(Object *obj, Visitor *v, void *opaque,
> > const char *name, Error **errp)
> > {
> > DeviceState *dev = DEVICE(obj);
> > @@ -117,7 +117,7 @@ PropertyInfo qdev_prop_bit = {
> > .legacy_name = "on/off",
> > .print = print_bit,
> > .get = get_bit,
> > -.set = set_bit,
> > +.set = prop_set_bit,
> > };
> >
> > /* --- bool --- */
>
> Other code uses qdev_prop prefix, which makes sense I think.
> Let's also update get_bit and print_bit, keep it consistent.
Sure
>
> > diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
> > index e0befb2..3dc4937 100644
> > --- a/hw/net/eepro100.c
> > +++ b/hw/net/eepro100.c
> > @@ -105,7 +105,6 @@
> > #define PCI_IO_SIZE 64
> > #define PCI_FLASH_SIZE (128 * KiB)
> >
> > -#define BIT(n) (1 << (n))
> > #define BITS(n, m) (((0xU << (31 - n)) >> (31 - n + m)) << m)
> >
> > /* The SCB accepts the following controls for the Tx and Rx units: */
>
> Please #include "qemu/bitops.h" - don't rely on other headers
> pulling it in.
Thanks
Marcel
>
> > diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> > index 7fbffcb..e8b89b1 100644
> > --- a/include/hw/qdev-core.h
> > +++ b/include/hw/qdev-core.h
> > @@ -4,6 +4,7 @@
> > #include "qemu/queue.h"
> > #include "qemu/option.h"
> > #include "qemu/typedefs.h"
> > +#include "qemu/bitmap.h"
> > #include "qom/object.h"
> > #include "hw/irq.h"
> > #include "qapi/error.h"
> > --
> > 1.8.3.1
Re: [Qemu-devel] [PATCH v2 2/3] qemu-help: Sort devices by logical functionality
On Mon, 2013-07-29 at 11:04 +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 29, 2013 at 10:07:34AM +0300, Marcel Apfelbaum wrote:
> > Categorize devices that appear as output to "-device ?" command
> > by logical functionality. Sort the devices by logical categories
> > before showing them to user.
> >
> > The sort is done by functionality rather than alphabetical.
> >
> > Signed-off-by: Marcel Apfelbaum
> > ---
> > Changes from v1:
> > Addressed Michael Tsirkin review:
> > Used bitmap operations on categories
> > Moved category names into the header file
> >
> > include/hw/qdev-core.h | 33 +
> > qdev-monitor.c | 50
> > ++
> > 2 files changed, 79 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> > index e8b89b1..80b06ac 100644
> > --- a/include/hw/qdev-core.h
> > +++ b/include/hw/qdev-core.h
> > @@ -18,6 +18,38 @@ enum {
> > #define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
> > TYPE_DEVICE)
> > #define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj),
> > TYPE_DEVICE)
> >
> > +typedef enum DeviceCategory {
> > +DEVICE_CATEGORY_ASSEMBLY,
> > +DEVICE_CATEGORY_MANAGEMENT,
> > +DEVICE_CATEGORY_STORAGE,
> > +DEVICE_CATEGORY_NETWORK,
> > +DEVICE_CATEGORY_INPUT,
> > +DEVICE_CATEGORY_DISPLAY,
> > +DEVICE_CATEGORY_SOUND,
> > +DEVICE_CATEGORY_MISC,
> > +DEVICE_CATEGORY_MAX
> > +} DeviceCategory;
> > +
> > +static inline const char *qdev_category_get_name(DeviceCategory category)
> > +{
> > +/* Category names corresponding to DeviceCategory values
> > + * The array elements must be in the same order as they
> > + * appear in DeviceCategory enum.
> > + */
>
> I would simply do:
> static const char *category_names[DEVICE_CATEGORY_MAX] = {
> [DEVICE_CATEGORY_ASSEMBLY] = "Assembly",
> [DEVICE_CATEGORY_MANAGEMENT] = "Management",
> [DEVICE_CATEGORY_STORAGE] = "Storage",
> [DEVICE_CATEGORY_NETWORK] = "Network",
> [DEVICE_CATEGORY_INPUT] = "Input",
> [DEVICE_CATEGORY_DISPLAY] = "Display",
> [DEVICE_CATEGORY_SOUND] = "Sound",
> [DEVICE_CATEGORY_MISC] = "Misc",
> };
>
> and drop the requirement to use same order.
OK
>
> > +static const char *category_names[] = {
> > +"Assembly",
> > +"Management",
> > +"Storage",
> > +"Network",
> > +"Input",
> > +"Display",
> > +"Sound",
> > +"Misc",
> > +};
>
>
> > +
> > +return category_names[category];
> > +}
> > +
> > typedef int (*qdev_initfn)(DeviceState *dev);
> > typedef int (*qdev_event)(DeviceState *dev);
> > typedef void (*qdev_resetfn)(DeviceState *dev);
> > @@ -81,6 +113,7 @@ typedef struct DeviceClass {
> > ObjectClass parent_class;
> > /*< public >*/
> >
> > +DECLARE_BITMAP(categories, 20);
>
> Why 20? Not DEVICE_CATEGORY_MAX ?
OK
>
>
> > const char *fw_name;
> > const char *desc;
> > Property *props;
> > diff --git a/qdev-monitor.c b/qdev-monitor.c
> > index e54dbc2..c3a3550 100644
> > --- a/qdev-monitor.c
> > +++ b/qdev-monitor.c
> > @@ -75,14 +75,21 @@ static bool qdev_class_has_alias(DeviceClass *dc)
> > return (qdev_class_get_alias(dc) != NULL);
> > }
> >
> > +typedef struct PrintDevInfoData {
> > +bool show_no_user;
> > +DeviceCategory category;
> > +} PrintDevInfoData ;
> > +
> > static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
> > {
> > DeviceClass *dc;
> > -bool *show_no_user = opaque;
> > +PrintDevInfoData *data = opaque;
>
> So all callers of qdev_print_devinfo would have to be updated,
> but you only updated one caller.
> Lack of type checking here is nasty. It's required
> by the object_class_foreach but you are not using that
> anymore.
>
> So please refactor this function: e.g.
> qdev_print_devinfo which gets void *,
> and qdev_print_class_devinfo which gets show_no_user and category.
> In fact, this way there won't be need for use of void *
> at all.
OK
Re: [Qemu-devel] [PATCH v2 2/3] qemu-help: Sort devices by logical functionality
On Mon, 2013-07-29 at 11:20 +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 29, 2013 at 11:14:11AM +0300, Marcel Apfelbaum wrote:
> > On Mon, 2013-07-29 at 11:04 +0300, Michael S. Tsirkin wrote:
> > > On Mon, Jul 29, 2013 at 10:07:34AM +0300, Marcel Apfelbaum wrote:
> > > > Categorize devices that appear as output to "-device ?" command
> > > > by logical functionality. Sort the devices by logical categories
> > > > before showing them to user.
> > > >
> > > > The sort is done by functionality rather than alphabetical.
> > > >
> > > > Signed-off-by: Marcel Apfelbaum
> > > > ---
> > > > Changes from v1:
> > > > Addressed Michael Tsirkin review:
> > > > Used bitmap operations on categories
> > > > Moved category names into the header file
> > > >
> > > > include/hw/qdev-core.h | 33 +
> > > > qdev-monitor.c | 50
> > > > ++
> > > > 2 files changed, 79 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> > > > index e8b89b1..80b06ac 100644
> > > > --- a/include/hw/qdev-core.h
> > > > +++ b/include/hw/qdev-core.h
> > > > @@ -18,6 +18,38 @@ enum {
> > > > #define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
> > > > TYPE_DEVICE)
> > > > #define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj),
> > > > TYPE_DEVICE)
> > > >
> > > > +typedef enum DeviceCategory {
> > > > +DEVICE_CATEGORY_ASSEMBLY,
> > > > +DEVICE_CATEGORY_MANAGEMENT,
> > > > +DEVICE_CATEGORY_STORAGE,
> > > > +DEVICE_CATEGORY_NETWORK,
> > > > +DEVICE_CATEGORY_INPUT,
> > > > +DEVICE_CATEGORY_DISPLAY,
> > > > +DEVICE_CATEGORY_SOUND,
> > > > +DEVICE_CATEGORY_MISC,
> > > > +DEVICE_CATEGORY_MAX
> > > > +} DeviceCategory;
> > > > +
> > > > +static inline const char *qdev_category_get_name(DeviceCategory
> > > > category)
> > > > +{
> > > > +/* Category names corresponding to DeviceCategory values
> > > > + * The array elements must be in the same order as they
> > > > + * appear in DeviceCategory enum.
> > > > + */
> > >
> > > I would simply do:
> > > static const char *category_names[DEVICE_CATEGORY_MAX] = {
> > > [DEVICE_CATEGORY_ASSEMBLY] = "Assembly",
> > > [DEVICE_CATEGORY_MANAGEMENT] = "Management",
> > > [DEVICE_CATEGORY_STORAGE] = "Storage",
> > > [DEVICE_CATEGORY_NETWORK] = "Network",
> > > [DEVICE_CATEGORY_INPUT] = "Input",
> > > [DEVICE_CATEGORY_DISPLAY] = "Display",
> > > [DEVICE_CATEGORY_SOUND] = "Sound",
> > > [DEVICE_CATEGORY_MISC] = "Misc",
> > > };
> > >
> > > and drop the requirement to use same order.
> > OK
> > >
> > > > +static const char *category_names[] = {
> > > > +"Assembly",
> > > > +"Management",
> > > > +"Storage",
> > > > +"Network",
> > > > +"Input",
> > > > +"Display",
> > > > +"Sound",
> > > > +"Misc",
> > > > +};
> > >
> > >
> > > > +
> > > > +return category_names[category];
> > > > +}
> > > > +
> > > > typedef int (*qdev_initfn)(DeviceState *dev);
> > > > typedef int (*qdev_event)(DeviceState *dev);
> > > > typedef void (*qdev_resetfn)(DeviceState *dev);
> > > > @@ -81,6 +113,7 @@ typedef struct DeviceClass {
> > > > ObjectClass parent_class;
> > > > /*< public >*/
> > > >
> > > > +DECLARE_BITMAP(categories, 20);
> > >
> > > Why 20? Not DEVICE_CATEGORY_MAX ?
> > OK
> > >
> > >
> > > > const char *fw_name;
> > > > const char *desc;
> > > > Property *props;
> > > > diff --git a/qdev-monitor.c b/qdev-monitor.c
> > > > index e54db
Re: [Qemu-devel] [PATCH v2 2/3] qemu-help: Sort devices by logical functionality
On Mon, 2013-07-29 at 12:22 +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 29, 2013 at 12:09:45PM +0300, Marcel Apfelbaum wrote:
> > On Mon, 2013-07-29 at 11:20 +0300, Michael S. Tsirkin wrote:
> > > On Mon, Jul 29, 2013 at 11:14:11AM +0300, Marcel Apfelbaum wrote:
> > > > On Mon, 2013-07-29 at 11:04 +0300, Michael S. Tsirkin wrote:
> > > > > On Mon, Jul 29, 2013 at 10:07:34AM +0300, Marcel Apfelbaum wrote:
> > > > > > Categorize devices that appear as output to "-device ?" command
> > > > > > by logical functionality. Sort the devices by logical categories
> > > > > > before showing them to user.
> > > > > >
> > > > > > The sort is done by functionality rather than alphabetical.
> > > > > >
> > > > > > Signed-off-by: Marcel Apfelbaum
> > > > > > ---
> > > > > > Changes from v1:
> > > > > > Addressed Michael Tsirkin review:
> > > > > > Used bitmap operations on categories
> > > > > > Moved category names into the header file
> > > > > >
> > > > > > include/hw/qdev-core.h | 33 +
> > > > > > qdev-monitor.c | 50
> > > > > > ++
> > > > > > 2 files changed, 79 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> > > > > > index e8b89b1..80b06ac 100644
> > > > > > --- a/include/hw/qdev-core.h
> > > > > > +++ b/include/hw/qdev-core.h
> > > > > > @@ -18,6 +18,38 @@ enum {
> > > > > > #define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass,
> > > > > > (klass), TYPE_DEVICE)
> > > > > > #define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj),
> > > > > > TYPE_DEVICE)
> > > > > >
> > > > > > +typedef enum DeviceCategory {
> > > > > > +DEVICE_CATEGORY_ASSEMBLY,
> > > > > > +DEVICE_CATEGORY_MANAGEMENT,
> > > > > > +DEVICE_CATEGORY_STORAGE,
> > > > > > +DEVICE_CATEGORY_NETWORK,
> > > > > > +DEVICE_CATEGORY_INPUT,
> > > > > > +DEVICE_CATEGORY_DISPLAY,
> > > > > > +DEVICE_CATEGORY_SOUND,
> > > > > > +DEVICE_CATEGORY_MISC,
> > > > > > +DEVICE_CATEGORY_MAX
> > > > > > +} DeviceCategory;
> > > > > > +
> > > > > > +static inline const char *qdev_category_get_name(DeviceCategory
> > > > > > category)
> > > > > > +{
> > > > > > +/* Category names corresponding to DeviceCategory values
> > > > > > + * The array elements must be in the same order as they
> > > > > > + * appear in DeviceCategory enum.
> > > > > > + */
> > > > >
> > > > > I would simply do:
> > > > > static const char *category_names[DEVICE_CATEGORY_MAX] = {
> > > > > [DEVICE_CATEGORY_ASSEMBLY] = "Assembly",
> > > > > [DEVICE_CATEGORY_MANAGEMENT] = "Management",
> > > > > [DEVICE_CATEGORY_STORAGE] = "Storage",
> > > > > [DEVICE_CATEGORY_NETWORK] = "Network",
> > > > > [DEVICE_CATEGORY_INPUT] = "Input",
> > > > > [DEVICE_CATEGORY_DISPLAY] = "Display",
> > > > > [DEVICE_CATEGORY_SOUND] = "Sound",
> > > > > [DEVICE_CATEGORY_MISC] = "Misc",
> > > > > };
> > > > >
> > > > > and drop the requirement to use same order.
> > > > OK
> > > > >
> > > > > > +static const char *category_names[] = {
> > > > > > +"Assembly",
> > > > > > +"Management",
> > > > > > +"Storage",
> > > > > > +"Network",
> > > > > > +"Input",
> > > > > > +"Display",
> > > > > > +"Sound",
> > > > > > +"Misc",
> > > > > > +};
> > > > >
> >
[Qemu-devel] [PATCH v3 0/3] qemu-help: improve -device command line help
Running qemu with "-device ?" option returns ~145 lines. It is hard to manage understanding the output. Theses patches aim to partially solve the problem by dividing the devices into logical categories like "Network/Display/..." and sorting them by it. Categories: Assembly - hosts/hubs/... ... (All others are self explanatory) Changes from v2: Addressed Michael Tsirkin's review - assign category to its name explicitly - refactoring of unsafe code Addressed Paolo Bonzini's review - moved several devices to the correct category - replaced Management category by USB Changes from v1: Addressed Michael Tsirkin review: Used bitmap operations on categories Moved category names into the header file Changes from RFC patch: Made category a bitmap to support multifunction PCI devices. Assigned all devices to their category. Marcel Apfelbaum (3): hw: import bitmap operations in qdev-core header qemu-help: Sort devices by logical functionality devices: Associate devices to their logical category hw/9pfs/virtio-9p-device.c | 1 + hw/audio/ac97.c| 1 + hw/audio/adlib.c | 1 + hw/audio/cs4231a.c | 1 + hw/audio/es1370.c | 1 + hw/audio/gus.c | 1 + hw/audio/hda-codec.c | 3 +++ hw/audio/intel-hda.c | 3 +++ hw/audio/pcspk.c | 1 + hw/audio/pl041.c | 1 + hw/audio/sb16.c| 1 + hw/block/fdc.c | 3 +++ hw/block/nvme.c| 1 + hw/block/pc_sysfw.c| 1 + hw/block/pflash_cfi01.c| 1 + hw/block/virtio-blk.c | 1 + hw/char/debugcon.c | 1 + hw/char/imx_serial.c | 1 + hw/char/ipack.c| 1 + hw/char/ipoctal232.c | 1 + hw/char/parallel.c | 1 + hw/char/serial-isa.c | 1 + hw/char/serial-pci.c | 3 +++ hw/char/tpci200.c | 1 + hw/char/virtio-serial-bus.c| 2 ++ hw/core/qdev-properties.c | 13 +- hw/cpu/icc_bus.c | 8 ++ hw/display/cirrus_vga.c| 2 ++ hw/display/g364fb.c| 1 + hw/display/pl110.c | 3 +++ hw/display/qxl.c | 2 ++ hw/display/vga-isa.c | 1 + hw/display/vga-pci.c | 1 + hw/display/vmware_vga.c| 1 + hw/i2c/bitbang_i2c.c | 1 + hw/i2c/core.c | 1 + hw/i386/kvm/pci-assign.c | 1 + hw/ide/ahci.c | 1 + hw/ide/ich.c | 1 + hw/ide/isa.c | 1 + hw/ide/piix.c | 3 +++ hw/ide/qdev.c | 1 + hw/ide/via.c | 1 + hw/isa/i82378.c| 1 + hw/isa/lpc_ich9.c | 1 + hw/isa/vt82c686.c | 3 +++ hw/misc/applesmc.c | 1 + hw/misc/debugexit.c| 1 + hw/misc/ivshmem.c | 1 + hw/misc/pc-testdev.c | 1 + hw/misc/pci-testdev.c | 1 + hw/misc/sga.c | 1 + hw/misc/vfio.c | 1 + hw/net/e1000.c | 1 + hw/net/eepro100.c | 3 ++- hw/net/lance.c | 1 + hw/net/mipsnet.c | 1 + hw/net/ne2000-isa.c| 1 + hw/net/ne2000.c| 1 + hw/net/opencores_eth.c | 1 + hw/net/pcnet-pci.c | 1 + hw/net/rtl8139.c | 1 + hw/net/virtio-net.c| 1 + hw/net/vmxnet3.c | 1 + hw/pci-bridge/i82801b11.c | 2 ++ hw/pci-bridge/ioh3420.c| 1 + hw/pci-bridge/pci_bridge_dev.c | 1 + hw/pci-bridge/xio3130_downstream.c | 1 + hw/pci-bridge/xio3130_upstream.c | 1 + hw/pci-host/apb.c | 2 ++ hw/pci-host/ppce500.c | 1 + hw/pci-host/prep.c | 1 + hw/pci-host/q35.c | 2 ++ hw/scsi/esp-pci.c | 2 ++ hw/scsi/esp.c | 1 + hw/scsi/lsi53c895a.c | 1 + hw/scsi/megasas.c | 1 + hw/scsi/scsi-bus.c | 1 + hw/scsi/vhost-scsi.c | 1 + hw/scsi/virtio-scsi.c | 3 +++ hw/scsi/vmw_pvscsi.c | 1 + hw/usb/ccid-card-emulated.c| 1 + hw/usb/ccid-card-passthru.c| 1 + hw/usb/dev-audio.c | 1 + hw/usb/dev-bluetooth.c | 1 + hw/usb/dev-hid.c | 3 +++ hw/usb/dev-hub.c | 1 + hw/usb/dev-network.c | 1 + hw/usb/dev-serial.c| 2 ++ hw/usb/dev-smartcard-reader.c | 1 + hw/usb/dev-storage.c
[Qemu-devel] [PATCH v3 2/3] qemu-help: Sort devices by logical functionality
Categorize devices that appear as output to "-device ?" command
by logical functionality. Sort the devices by logical categories
before showing them to user.
The sort is done by functionality rather than alphabetical.
Signed-off-by: Marcel Apfelbaum
---
Changes from v2:
Addressed Michael Tsirkin's review:
- Explicit connection between the categories
and their names
- Refactoring of unsafe code
Addressed Paolo Bonzini's review
- Replaced Management category by USB
Changes from v1:
Addressed Michael Tsirkin's review:
- Used bitmap operations on categories
- Moved category names into the header file
include/hw/qdev-core.h | 29
qdev-monitor.c | 52 +-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index e8b89b1..111ad06 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -18,6 +18,34 @@ enum {
#define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
TYPE_DEVICE)
#define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj), TYPE_DEVICE)
+typedef enum DeviceCategory {
+DEVICE_CATEGORY_ASSEMBLY,
+DEVICE_CATEGORY_USB,
+DEVICE_CATEGORY_STORAGE,
+DEVICE_CATEGORY_NETWORK,
+DEVICE_CATEGORY_INPUT,
+DEVICE_CATEGORY_DISPLAY,
+DEVICE_CATEGORY_SOUND,
+DEVICE_CATEGORY_MISC,
+DEVICE_CATEGORY_MAX
+} DeviceCategory;
+
+static inline const char *qdev_category_get_name(DeviceCategory category)
+{
+static const char *category_names[DEVICE_CATEGORY_MAX] = {
+[DEVICE_CATEGORY_ASSEMBLY] = "Assembly",
+[DEVICE_CATEGORY_USB] = "USB",
+[DEVICE_CATEGORY_STORAGE] = "Storage",
+[DEVICE_CATEGORY_NETWORK] = "Network",
+[DEVICE_CATEGORY_INPUT]= "Input",
+[DEVICE_CATEGORY_DISPLAY] = "Display",
+[DEVICE_CATEGORY_SOUND]= "Sound",
+[DEVICE_CATEGORY_MISC] = "Misc",
+};
+
+return category_names[category];
+};
+
typedef int (*qdev_initfn)(DeviceState *dev);
typedef int (*qdev_event)(DeviceState *dev);
typedef void (*qdev_resetfn)(DeviceState *dev);
@@ -81,6 +109,7 @@ typedef struct DeviceClass {
ObjectClass parent_class;
/*< public >*/
+DECLARE_BITMAP(categories, DEVICE_CATEGORY_MAX);
const char *fw_name;
const char *desc;
Property *props;
diff --git a/qdev-monitor.c b/qdev-monitor.c
index e54dbc2..536e246 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -75,24 +75,27 @@ static bool qdev_class_has_alias(DeviceClass *dc)
return (qdev_class_get_alias(dc) != NULL);
}
-static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
+static void qdev_print_class_devinfo(DeviceClass *dc)
{
-DeviceClass *dc;
-bool *show_no_user = opaque;
-
-dc = (DeviceClass *)object_class_dynamic_cast(klass, TYPE_DEVICE);
+DeviceCategory category;
-if (!dc || (show_no_user && !*show_no_user && dc->no_user)) {
+if (!dc || dc->no_user) {
return;
}
-error_printf("name \"%s\"", object_class_get_name(klass));
+error_printf("name \"%s\"", object_class_get_name(OBJECT_CLASS(dc)));
if (dc->bus_type) {
error_printf(", bus %s", dc->bus_type);
}
if (qdev_class_has_alias(dc)) {
error_printf(", alias \"%s\"", qdev_class_get_alias(dc));
}
+error_printf(", categories");
+for (category = 0; category < DEVICE_CATEGORY_MAX; ++category) {
+if (test_bit(category, dc->categories)) {
+error_printf(" \"%s\"", qdev_category_get_name(category));
+}
+}
if (dc->desc) {
error_printf(", desc \"%s\"", dc->desc);
}
@@ -102,6 +105,20 @@ static void qdev_print_devinfo(ObjectClass *klass, void
*opaque)
error_printf("\n");
}
+static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
+{
+DeviceClass *dc;
+bool *show_no_user = opaque;
+
+dc = (DeviceClass *)object_class_dynamic_cast(klass, TYPE_DEVICE);
+
+if (!dc || (show_no_user && !*show_no_user && dc->no_user)) {
+return;
+}
+
+qdev_print_class_devinfo(dc);
+}
+
static int set_property(const char *name, const char *value, void *opaque)
{
DeviceState *dev = opaque;
@@ -139,6 +156,20 @@ static const char *find_typename_by_alias(const char
*alias)
return NULL;
}
+static void qdev_print_category_devices(DeviceCategory category)
+{
+DeviceClass *dc;
+GSList *list, *curr;
+
+list = object_class_get_list(TYPE_DEVICE, false);
+for (curr = list; curr; curr = g_slist_next(curr)) {
+dc = (DeviceClass *)object_class_dynamic_cast(
[Qemu-devel] [PATCH v3 1/3] hw: import bitmap operations in qdev-core header
Made small tweaks in code to prevent compilation issues
when importing qemu/bitmap.h in qdev-core
Signed-off-by: Marcel Apfelbaum
---
Changes from v2
- explicit inclusion of the bitmap headers
- modified names of all methods of qdev_prop_bit
to prevent compilation errors
hw/core/qdev-properties.c | 13 +++--
hw/net/eepro100.c | 2 +-
include/hw/qdev-core.h| 1 +
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index 3a324fb..6e1ed1e 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -74,13 +74,14 @@ static void bit_prop_set(DeviceState *dev, Property *props,
bool val)
}
}
-static int print_bit(DeviceState *dev, Property *prop, char *dest, size_t len)
+static int prop_print_bit(DeviceState *dev, Property *prop, char *dest,
+ size_t len)
{
uint32_t *p = qdev_get_prop_ptr(dev, prop);
return snprintf(dest, len, (*p & qdev_get_prop_mask(prop)) ? "on" : "off");
}
-static void get_bit(Object *obj, Visitor *v, void *opaque,
+static void prop_get_bit(Object *obj, Visitor *v, void *opaque,
const char *name, Error **errp)
{
DeviceState *dev = DEVICE(obj);
@@ -91,7 +92,7 @@ static void get_bit(Object *obj, Visitor *v, void *opaque,
visit_type_bool(v, &value, name, errp);
}
-static void set_bit(Object *obj, Visitor *v, void *opaque,
+static void prop_set_bit(Object *obj, Visitor *v, void *opaque,
const char *name, Error **errp)
{
DeviceState *dev = DEVICE(obj);
@@ -115,9 +116,9 @@ static void set_bit(Object *obj, Visitor *v, void *opaque,
PropertyInfo qdev_prop_bit = {
.name = "boolean",
.legacy_name = "on/off",
-.print = print_bit,
-.get = get_bit,
-.set = set_bit,
+.print = prop_print_bit,
+.get = prop_get_bit,
+.set = prop_set_bit,
};
/* --- bool --- */
diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index e0befb2..25b7d0c 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -47,6 +47,7 @@
#include "hw/nvram/eeprom93xx.h"
#include "sysemu/sysemu.h"
#include "sysemu/dma.h"
+#include "qemu/bitops.h"
/* QEMU sends frames smaller than 60 bytes to ethernet nics.
* Such frames are rejected by real nics and their emulations.
@@ -105,7 +106,6 @@
#define PCI_IO_SIZE 64
#define PCI_FLASH_SIZE (128 * KiB)
-#define BIT(n) (1 << (n))
#define BITS(n, m) (((0xU << (31 - n)) >> (31 - n + m)) << m)
/* The SCB accepts the following controls for the Tx and Rx units: */
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 7fbffcb..e8b89b1 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -4,6 +4,7 @@
#include "qemu/queue.h"
#include "qemu/option.h"
#include "qemu/typedefs.h"
+#include "qemu/bitmap.h"
#include "qom/object.h"
#include "hw/irq.h"
#include "qapi/error.h"
--
1.8.3.1
Re: [Qemu-devel] [PATCH v3 2/3] qemu-help: Sort devices by logical functionality
On Mon, 2013-07-29 at 15:11 +0300, Marcel Apfelbaum wrote:
> Categorize devices that appear as output to "-device ?" command
> by logical functionality. Sort the devices by logical categories
> before showing them to user.
>
> The sort is done by functionality rather than alphabetical.
>
> Signed-off-by: Marcel Apfelbaum
> ---
> Changes from v2:
> Addressed Michael Tsirkin's review:
> - Explicit connection between the categories
> and their names
> - Refactoring of unsafe code
> Addressed Paolo Bonzini's review
> - Replaced Management category by USB
>
> Changes from v1:
> Addressed Michael Tsirkin's review:
> - Used bitmap operations on categories
> - Moved category names into the header file
>
> include/hw/qdev-core.h | 29
> qdev-monitor.c | 52
> +-
> 2 files changed, 72 insertions(+), 9 deletions(-)
>
> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> index e8b89b1..111ad06 100644
> --- a/include/hw/qdev-core.h
> +++ b/include/hw/qdev-core.h
> @@ -18,6 +18,34 @@ enum {
> #define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
> TYPE_DEVICE)
> #define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj),
> TYPE_DEVICE)
>
> +typedef enum DeviceCategory {
> +DEVICE_CATEGORY_ASSEMBLY,
> +DEVICE_CATEGORY_USB,
> +DEVICE_CATEGORY_STORAGE,
> +DEVICE_CATEGORY_NETWORK,
> +DEVICE_CATEGORY_INPUT,
> +DEVICE_CATEGORY_DISPLAY,
> +DEVICE_CATEGORY_SOUND,
> +DEVICE_CATEGORY_MISC,
> +DEVICE_CATEGORY_MAX
> +} DeviceCategory;
> +
> +static inline const char *qdev_category_get_name(DeviceCategory category)
> +{
> +static const char *category_names[DEVICE_CATEGORY_MAX] = {
> +[DEVICE_CATEGORY_ASSEMBLY] = "Assembly",
> +[DEVICE_CATEGORY_USB] = "USB",
> +[DEVICE_CATEGORY_STORAGE] = "Storage",
> +[DEVICE_CATEGORY_NETWORK] = "Network",
> +[DEVICE_CATEGORY_INPUT]= "Input",
> +[DEVICE_CATEGORY_DISPLAY] = "Display",
> +[DEVICE_CATEGORY_SOUND]= "Sound",
> +[DEVICE_CATEGORY_MISC] = "Misc",
> +};
> +
> +return category_names[category];
> +};
> +
> typedef int (*qdev_initfn)(DeviceState *dev);
> typedef int (*qdev_event)(DeviceState *dev);
> typedef void (*qdev_resetfn)(DeviceState *dev);
> @@ -81,6 +109,7 @@ typedef struct DeviceClass {
> ObjectClass parent_class;
> /*< public >*/
>
> +DECLARE_BITMAP(categories, DEVICE_CATEGORY_MAX);
> const char *fw_name;
> const char *desc;
> Property *props;
> diff --git a/qdev-monitor.c b/qdev-monitor.c
> index e54dbc2..536e246 100644
> --- a/qdev-monitor.c
> +++ b/qdev-monitor.c
> @@ -75,24 +75,27 @@ static bool qdev_class_has_alias(DeviceClass *dc)
> return (qdev_class_get_alias(dc) != NULL);
> }
>
> -static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
> +static void qdev_print_class_devinfo(DeviceClass *dc)
> {
> -DeviceClass *dc;
> -bool *show_no_user = opaque;
> -
> -dc = (DeviceClass *)object_class_dynamic_cast(klass, TYPE_DEVICE);
> +DeviceCategory category;
>
> -if (!dc || (show_no_user && !*show_no_user && dc->no_user)) {
> +if (!dc || dc->no_user) {
> return;
> }
>
> -error_printf("name \"%s\"", object_class_get_name(klass));
> +error_printf("name \"%s\"", object_class_get_name(OBJECT_CLASS(dc)));
> if (dc->bus_type) {
> error_printf(", bus %s", dc->bus_type);
> }
> if (qdev_class_has_alias(dc)) {
> error_printf(", alias \"%s\"", qdev_class_get_alias(dc));
> }
> +error_printf(", categories");
> +for (category = 0; category < DEVICE_CATEGORY_MAX; ++category) {
> +if (test_bit(category, dc->categories)) {
> +error_printf(" \"%s\"", qdev_category_get_name(category));
> +}
> +}
> if (dc->desc) {
> error_printf(", desc \"%s\"", dc->desc);
> }
> @@ -102,6 +105,20 @@ static void qdev_print_devinfo(ObjectClass *klass, void
> *opaque)
> error_printf("\n");
> }
>
> +static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
> +{
> +DeviceClass *dc;
> +bool *show_no_user = opaque;
> +
> +dc = (DeviceClass *)object_class_dyn
Re: [Qemu-devel] [PATCH 0/2] qemu-help: improve -device command line help
On Mon, 2013-07-29 at 13:27 +0200, Paolo Bonzini wrote:
> Il 29/07/2013 10:00, Marcel Apfelbaum ha scritto:
> > On Mon, 2013-07-29 at 09:36 +0200, Paolo Bonzini wrote:
> >> Il 28/07/2013 11:14, Marcel Apfelbaum ha scritto:
> >>> Categories:
> >>> Assembly - hosts/hubs/...
> >>
> >> A lot of these seem to fit in a "bridge" category.
> > I wanted to group in a category as much as possible having in
> > mind the user shall "grep" by category to find devices.
> > My goal is a top category with devices that are not nodes and
> > are used as a way to combine other devices.
> >>
> >> I'm not sure why usbhost is in the assembly category though. Also, why
> >> is this the default category for isa and i2c devices?
> > The same argument as above. I am looking for top devices and not for
> > their type
>
> USB host is a leaf device. As to ISA and I2C, which devices exactly are
> using the default you're setting here? Are they really bridge- or
> controller-type device?
After moving the devices you specified from "Management" to their
correct category, all the remaining devices were usb, so I renamed
the category to USB (Management is empty, so removed)
Regarding the ISA devices, I spread them between categories:
name "isa-ide", bus ISA, categories "Storage"
name "ne2k_isa", bus ISA, categories "Network"
name "isa-parallel", bus ISA, categories "Input"
name "isa-serial", bus ISA, categories "Input"
name "isa-cirrus-vga", bus ISA, categories "Display"
name "isa-vga", bus ISA, categories "Display"
name "isa-applesmc", bus ISA, categories "Misc"
name "isa-debugcon", bus ISA, categories "Misc"
name "isa-debug-exit", bus ISA, categories "Misc"
Regarding the I2C device, I moved it to the misc Category, I
was misled by the name. Thanks
>
> >>> Management - controllers
> >>
> >> AHCI is storage.
> > Thanks, it looked like management to me.
> > Devices in management category shall control other devices.
> > It looked like a fit for me.
>
> Yeah, it does, but then the same is true for all SCSI HBAs.
>
> >> applesmc is something like a microcontroller ("misc"?).
> > Thanks, I'll move to misc
> >>
> >> Everything else in this category is USB host controllers, I think it
> >> deserves a special category since USB devices are generally somewhat
> >> self-explanatory (hubs too).
> > I didn't want to include the "USB" keyword, because the user will be lost
> > when filtering by this word. The goal is to help the user to concentrate
> > on a specific "category". Maybe USB-Controller ?
>
> Maybe two categories (USB | Controller)? There is also difference
> between storage controllers and storage devices (i.e. disks).
>
> I think assembly and management can be merged into a single
> "controller/hub/bridge" category. You can then use multiple categories
> for HBAs, for AHCI, etc.
As mentioned above , the "Management" category disappear, so Assembly
includes should be now controller/hub/bridge
I'll release a version soon.
Thanks!
>
> Paolo
Re: [Qemu-devel] [PATCH v3 0/3] qemu-help: improve -device command line help
On Mon, 2013-07-29 at 14:32 +0200, Paolo Bonzini wrote: > Il 29/07/2013 14:11, Marcel Apfelbaum ha scritto: > > Running qemu with "-device ?" option returns ~145 lines. > > It is hard to manage understanding the output. > > > > Theses patches aim to partially solve the problem by dividing the devices > > into logical categories like "Network/Display/..." and sorting them by it. > > > > Categories: > > Assembly - hosts/hubs/... > > ... > > (All others are self explanatory) > > Can we rename it to something like "bridge" that you can print as > "Controller/Bridge/Hub"? Sure > > Paolo
Re: [Qemu-devel] [PATCH v3 2/3] qemu-help: Sort devices by logical functionality
On Mon, 2013-07-29 at 15:28 +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 29, 2013 at 03:11:42PM +0300, Marcel Apfelbaum wrote:
> > Categorize devices that appear as output to "-device ?" command
> > by logical functionality. Sort the devices by logical categories
> > before showing them to user.
> >
> > The sort is done by functionality rather than alphabetical.
> >
> > Signed-off-by: Marcel Apfelbaum
> > ---
> > Changes from v2:
> > Addressed Michael Tsirkin's review:
> > - Explicit connection between the categories
> > and their names
> > - Refactoring of unsafe code
> > Addressed Paolo Bonzini's review
> > - Replaced Management category by USB
> >
> > Changes from v1:
> > Addressed Michael Tsirkin's review:
> > - Used bitmap operations on categories
> > - Moved category names into the header file
> >
> > include/hw/qdev-core.h | 29
> > qdev-monitor.c | 52
> > +-
> > 2 files changed, 72 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> > index e8b89b1..111ad06 100644
> > --- a/include/hw/qdev-core.h
> > +++ b/include/hw/qdev-core.h
> > @@ -18,6 +18,34 @@ enum {
> > #define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
> > TYPE_DEVICE)
> > #define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj),
> > TYPE_DEVICE)
> >
> > +typedef enum DeviceCategory {
> > +DEVICE_CATEGORY_ASSEMBLY,
> > +DEVICE_CATEGORY_USB,
> > +DEVICE_CATEGORY_STORAGE,
> > +DEVICE_CATEGORY_NETWORK,
> > +DEVICE_CATEGORY_INPUT,
> > +DEVICE_CATEGORY_DISPLAY,
> > +DEVICE_CATEGORY_SOUND,
> > +DEVICE_CATEGORY_MISC,
> > +DEVICE_CATEGORY_MAX
> > +} DeviceCategory;
> > +
> > +static inline const char *qdev_category_get_name(DeviceCategory category)
> > +{
> > +static const char *category_names[DEVICE_CATEGORY_MAX] = {
> > +[DEVICE_CATEGORY_ASSEMBLY] = "Assembly",
> > +[DEVICE_CATEGORY_USB] = "USB",
> > +[DEVICE_CATEGORY_STORAGE] = "Storage",
> > +[DEVICE_CATEGORY_NETWORK] = "Network",
> > +[DEVICE_CATEGORY_INPUT]= "Input",
> > +[DEVICE_CATEGORY_DISPLAY] = "Display",
> > +[DEVICE_CATEGORY_SOUND]= "Sound",
> > +[DEVICE_CATEGORY_MISC] = "Misc",
> > +};
> > +
> > +return category_names[category];
> > +};
> > +
> > typedef int (*qdev_initfn)(DeviceState *dev);
> > typedef int (*qdev_event)(DeviceState *dev);
> > typedef void (*qdev_resetfn)(DeviceState *dev);
> > @@ -81,6 +109,7 @@ typedef struct DeviceClass {
> > ObjectClass parent_class;
> > /*< public >*/
> >
> > +DECLARE_BITMAP(categories, DEVICE_CATEGORY_MAX);
> > const char *fw_name;
> > const char *desc;
> > Property *props;
> > diff --git a/qdev-monitor.c b/qdev-monitor.c
> > index e54dbc2..536e246 100644
> > --- a/qdev-monitor.c
> > +++ b/qdev-monitor.c
> > @@ -75,24 +75,27 @@ static bool qdev_class_has_alias(DeviceClass *dc)
> > return (qdev_class_get_alias(dc) != NULL);
> > }
> >
> > -static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
> > +static void qdev_print_class_devinfo(DeviceClass *dc)
> > {
> > -DeviceClass *dc;
> > -bool *show_no_user = opaque;
> > -
> > -dc = (DeviceClass *)object_class_dynamic_cast(klass, TYPE_DEVICE);
> > +DeviceCategory category;
> >
> > -if (!dc || (show_no_user && !*show_no_user && dc->no_user)) {
> > +if (!dc || dc->no_user) {
> > return;
> > }
> >
> > -error_printf("name \"%s\"", object_class_get_name(klass));
> > +error_printf("name \"%s\"", object_class_get_name(OBJECT_CLASS(dc)));
> > if (dc->bus_type) {
> > error_printf(", bus %s", dc->bus_type);
> > }
> > if (qdev_class_has_alias(dc)) {
> > error_printf(", alias \"%s\"", qdev_class_get_alias(dc));
> > }
> > +error_printf(", categories");
> > +for (category = 0; category < DEVICE_CATEGORY_MAX; ++category) {
> > +if (test_bit(category, dc-&g
Re: [Qemu-devel] [PATCH v3 2/3] qemu-help: Sort devices by logical functionality
On Mon, 2013-07-29 at 15:42 +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 29, 2013 at 03:36:24PM +0300, Marcel Apfelbaum wrote:
> > On Mon, 2013-07-29 at 15:28 +0300, Michael S. Tsirkin wrote:
> > > On Mon, Jul 29, 2013 at 03:11:42PM +0300, Marcel Apfelbaum wrote:
> > > > Categorize devices that appear as output to "-device ?" command
> > > > by logical functionality. Sort the devices by logical categories
> > > > before showing them to user.
> > > >
> > > > The sort is done by functionality rather than alphabetical.
> > > >
> > > > Signed-off-by: Marcel Apfelbaum
> > > > ---
> > > > Changes from v2:
> > > > Addressed Michael Tsirkin's review:
> > > > - Explicit connection between the categories
> > > > and their names
> > > > - Refactoring of unsafe code
> > > > Addressed Paolo Bonzini's review
> > > > - Replaced Management category by USB
> > > >
> > > > Changes from v1:
> > > > Addressed Michael Tsirkin's review:
> > > > - Used bitmap operations on categories
> > > > - Moved category names into the header file
> > > >
> > > > include/hw/qdev-core.h | 29
> > > > qdev-monitor.c | 52
> > > > +-
> > > > 2 files changed, 72 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> > > > index e8b89b1..111ad06 100644
> > > > --- a/include/hw/qdev-core.h
> > > > +++ b/include/hw/qdev-core.h
> > > > @@ -18,6 +18,34 @@ enum {
> > > > #define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
> > > > TYPE_DEVICE)
> > > > #define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj),
> > > > TYPE_DEVICE)
> > > >
> > > > +typedef enum DeviceCategory {
> > > > +DEVICE_CATEGORY_ASSEMBLY,
> > > > +DEVICE_CATEGORY_USB,
> > > > +DEVICE_CATEGORY_STORAGE,
> > > > +DEVICE_CATEGORY_NETWORK,
> > > > +DEVICE_CATEGORY_INPUT,
> > > > +DEVICE_CATEGORY_DISPLAY,
> > > > +DEVICE_CATEGORY_SOUND,
> > > > +DEVICE_CATEGORY_MISC,
> > > > +DEVICE_CATEGORY_MAX
> > > > +} DeviceCategory;
> > > > +
> > > > +static inline const char *qdev_category_get_name(DeviceCategory
> > > > category)
> > > > +{
> > > > +static const char *category_names[DEVICE_CATEGORY_MAX] = {
> > > > +[DEVICE_CATEGORY_ASSEMBLY] = "Assembly",
> > > > +[DEVICE_CATEGORY_USB] = "USB",
> > > > +[DEVICE_CATEGORY_STORAGE] = "Storage",
> > > > +[DEVICE_CATEGORY_NETWORK] = "Network",
> > > > +[DEVICE_CATEGORY_INPUT]= "Input",
> > > > +[DEVICE_CATEGORY_DISPLAY] = "Display",
> > > > +[DEVICE_CATEGORY_SOUND]= "Sound",
> > > > +[DEVICE_CATEGORY_MISC] = "Misc",
> > > > +};
> > > > +
> > > > +return category_names[category];
> > > > +};
> > > > +
> > > > typedef int (*qdev_initfn)(DeviceState *dev);
> > > > typedef int (*qdev_event)(DeviceState *dev);
> > > > typedef void (*qdev_resetfn)(DeviceState *dev);
> > > > @@ -81,6 +109,7 @@ typedef struct DeviceClass {
> > > > ObjectClass parent_class;
> > > > /*< public >*/
> > > >
> > > > +DECLARE_BITMAP(categories, DEVICE_CATEGORY_MAX);
> > > > const char *fw_name;
> > > > const char *desc;
> > > > Property *props;
> > > > diff --git a/qdev-monitor.c b/qdev-monitor.c
> > > > index e54dbc2..536e246 100644
> > > > --- a/qdev-monitor.c
> > > > +++ b/qdev-monitor.c
> > > > @@ -75,24 +75,27 @@ static bool qdev_class_has_alias(DeviceClass *dc)
> > > > return (qdev_class_get_alias(dc) != NULL);
> > > > }
> > > >
> > > > -static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
> > > > +static void qdev_print_class_devinfo(DeviceClass *dc)
> > > > {
> > > > -DeviceClass *dc;
> > > >
[Qemu-devel] [PATCH v4 0/3] qemu-help: improve -device command line help
Running qemu with "-device ?" option returns ~145 lines. It is hard to manage understanding the output. Theses patches aim to partially solve the problem by dividing the devices into logical categories like "Network/Display/..." and sorting them by it. Changes from v3: - fixed a memory leak in patch 2/3 Addressed Michael S. Tsirkin's review - removed dead code - qdev_print_class_devinfo can print info on abstract classes Addressed Paolo Bonzini's review - Renamed "Assembly" category to "Controller/Bridge/Hub" Changes from v2: Addressed Michael S. Tsirkin's review - assign category to its name explicitly - refactoring of unsafe code Addressed Paolo Bonzini's review - moved several devices to the correct category - replaced Management category by USB Changes from v1: Addressed Michael S. Tsirkin review: Used bitmap operations on categories Moved category names into the header file Changes from RFC patch: Made category a bitmap to support multifunction PCI devices. Assigned all devices to their category. Marcel Apfelbaum (3): hw: import bitmap operations in qdev-core header qemu-help: Sort devices by logical functionality devices: Associate devices to their logical category hw/9pfs/virtio-9p-device.c | 1 + hw/audio/ac97.c| 1 + hw/audio/adlib.c | 1 + hw/audio/cs4231a.c | 1 + hw/audio/es1370.c | 1 + hw/audio/gus.c | 1 + hw/audio/hda-codec.c | 3 +++ hw/audio/intel-hda.c | 3 +++ hw/audio/pcspk.c | 1 + hw/audio/pl041.c | 1 + hw/audio/sb16.c| 1 + hw/block/fdc.c | 3 +++ hw/block/nvme.c| 1 + hw/block/pc_sysfw.c| 1 + hw/block/pflash_cfi01.c| 1 + hw/block/virtio-blk.c | 1 + hw/char/debugcon.c | 1 + hw/char/imx_serial.c | 1 + hw/char/ipack.c| 1 + hw/char/ipoctal232.c | 1 + hw/char/parallel.c | 1 + hw/char/serial-isa.c | 1 + hw/char/serial-pci.c | 3 +++ hw/char/tpci200.c | 1 + hw/char/virtio-serial-bus.c| 2 ++ hw/core/qdev-properties.c | 13 ++- hw/cpu/icc_bus.c | 8 +++ hw/display/cirrus_vga.c| 2 ++ hw/display/g364fb.c| 1 + hw/display/pl110.c | 3 +++ hw/display/qxl.c | 2 ++ hw/display/vga-isa.c | 1 + hw/display/vga-pci.c | 1 + hw/display/vmware_vga.c| 1 + hw/i2c/bitbang_i2c.c | 1 + hw/i2c/core.c | 1 + hw/i386/kvm/pci-assign.c | 1 + hw/ide/ahci.c | 1 + hw/ide/ich.c | 1 + hw/ide/isa.c | 1 + hw/ide/piix.c | 3 +++ hw/ide/qdev.c | 1 + hw/ide/via.c | 1 + hw/isa/i82378.c| 1 + hw/isa/lpc_ich9.c | 1 + hw/isa/vt82c686.c | 3 +++ hw/misc/applesmc.c | 1 + hw/misc/debugexit.c| 1 + hw/misc/ivshmem.c | 1 + hw/misc/pc-testdev.c | 1 + hw/misc/pci-testdev.c | 1 + hw/misc/sga.c | 1 + hw/misc/vfio.c | 1 + hw/net/e1000.c | 1 + hw/net/eepro100.c | 3 ++- hw/net/lance.c | 1 + hw/net/mipsnet.c | 1 + hw/net/ne2000-isa.c| 1 + hw/net/ne2000.c| 1 + hw/net/opencores_eth.c | 1 + hw/net/pcnet-pci.c | 1 + hw/net/rtl8139.c | 1 + hw/net/virtio-net.c| 1 + hw/net/vmxnet3.c | 1 + hw/pci-bridge/i82801b11.c | 2 ++ hw/pci-bridge/ioh3420.c| 1 + hw/pci-bridge/pci_bridge_dev.c | 1 + hw/pci-bridge/xio3130_downstream.c | 1 + hw/pci-bridge/xio3130_upstream.c | 1 + hw/pci-host/apb.c | 2 ++ hw/pci-host/ppce500.c | 1 + hw/pci-host/prep.c | 1 + hw/pci-host/q35.c | 2 ++ hw/scsi/esp-pci.c | 2 ++ hw/scsi/esp.c | 1 + hw/scsi/lsi53c895a.c | 1 + hw/scsi/megasas.c | 1 + hw/scsi/scsi-bus.c | 1 + hw/scsi/vhost-scsi.c | 1 + hw/scsi/virtio-scsi.c | 3 +++ hw/scsi/vmw_pvscsi.c | 1 + hw/usb/ccid-card-emulated.c| 1 + hw/usb/ccid-card-passthru.c| 1 + hw/usb/dev-audio.c | 1 + hw/usb/dev-bluetooth.c | 1 + h
[Qemu-devel] [PATCH v4 1/3] hw: import bitmap operations in qdev-core header
Made small tweaks in code to prevent compilation issues
when importing qemu/bitmap.h in qdev-core
Signed-off-by: Marcel Apfelbaum
---
Changes from v2
- explicit inclusion of the bitmap headers
- modified names of all methods of qdev_prop_bit
to prevent compilation errors
hw/core/qdev-properties.c | 13 +++--
hw/net/eepro100.c | 2 +-
include/hw/qdev-core.h| 1 +
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index 3a324fb..6e1ed1e 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -74,13 +74,14 @@ static void bit_prop_set(DeviceState *dev, Property *props,
bool val)
}
}
-static int print_bit(DeviceState *dev, Property *prop, char *dest, size_t len)
+static int prop_print_bit(DeviceState *dev, Property *prop, char *dest,
+ size_t len)
{
uint32_t *p = qdev_get_prop_ptr(dev, prop);
return snprintf(dest, len, (*p & qdev_get_prop_mask(prop)) ? "on" : "off");
}
-static void get_bit(Object *obj, Visitor *v, void *opaque,
+static void prop_get_bit(Object *obj, Visitor *v, void *opaque,
const char *name, Error **errp)
{
DeviceState *dev = DEVICE(obj);
@@ -91,7 +92,7 @@ static void get_bit(Object *obj, Visitor *v, void *opaque,
visit_type_bool(v, &value, name, errp);
}
-static void set_bit(Object *obj, Visitor *v, void *opaque,
+static void prop_set_bit(Object *obj, Visitor *v, void *opaque,
const char *name, Error **errp)
{
DeviceState *dev = DEVICE(obj);
@@ -115,9 +116,9 @@ static void set_bit(Object *obj, Visitor *v, void *opaque,
PropertyInfo qdev_prop_bit = {
.name = "boolean",
.legacy_name = "on/off",
-.print = print_bit,
-.get = get_bit,
-.set = set_bit,
+.print = prop_print_bit,
+.get = prop_get_bit,
+.set = prop_set_bit,
};
/* --- bool --- */
diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index e0befb2..25b7d0c 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -47,6 +47,7 @@
#include "hw/nvram/eeprom93xx.h"
#include "sysemu/sysemu.h"
#include "sysemu/dma.h"
+#include "qemu/bitops.h"
/* QEMU sends frames smaller than 60 bytes to ethernet nics.
* Such frames are rejected by real nics and their emulations.
@@ -105,7 +106,6 @@
#define PCI_IO_SIZE 64
#define PCI_FLASH_SIZE (128 * KiB)
-#define BIT(n) (1 << (n))
#define BITS(n, m) (((0xU << (31 - n)) >> (31 - n + m)) << m)
/* The SCB accepts the following controls for the Tx and Rx units: */
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 7fbffcb..e8b89b1 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -4,6 +4,7 @@
#include "qemu/queue.h"
#include "qemu/option.h"
#include "qemu/typedefs.h"
+#include "qemu/bitmap.h"
#include "qom/object.h"
#include "hw/irq.h"
#include "qapi/error.h"
--
1.8.3.1
[Qemu-devel] [PATCH v4 2/3] qemu-help: Sort devices by logical functionality
Categorize devices that appear as output to "-device ?" command
by logical functionality. Sort the devices by logical categories
before showing them to user.
The sort is done by functionality rather than alphabetical.
Signed-off-by: Marcel Apfelbaum
---
Changes from v3:
- fixed a memory leak introduced by v3
Addressed Michael S. Tsirkin's review
- removed dead code
- qdev_print_class_devinfo can print info
on abstract classes
Addressed Paolo Bonzini's review
- Renamed "Assembly" category to "Controller/Bridge/Hub"
Changes from v2:
Addressed Michael S. Tsirkin's review:
- Explicit connection between the categories
and their names
- Refactoring of unsafe code
Addressed Paolo Bonzini's review
- Replaced Management category by USB
Changes from v1:
Addressed Michael S. Tsirkin's review:
- Used bitmap operations on categories
- Moved category names into the header file
include/hw/qdev-core.h | 29 +
qdev-monitor.c | 48 +++-
2 files changed, 68 insertions(+), 9 deletions(-)
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index e8b89b1..46972f4 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -18,6 +18,34 @@ enum {
#define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
TYPE_DEVICE)
#define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj), TYPE_DEVICE)
+typedef enum DeviceCategory {
+DEVICE_CATEGORY_BRIDGE,
+DEVICE_CATEGORY_USB,
+DEVICE_CATEGORY_STORAGE,
+DEVICE_CATEGORY_NETWORK,
+DEVICE_CATEGORY_INPUT,
+DEVICE_CATEGORY_DISPLAY,
+DEVICE_CATEGORY_SOUND,
+DEVICE_CATEGORY_MISC,
+DEVICE_CATEGORY_MAX
+} DeviceCategory;
+
+static inline const char *qdev_category_get_name(DeviceCategory category)
+{
+static const char *category_names[DEVICE_CATEGORY_MAX] = {
+[DEVICE_CATEGORY_BRIDGE] = "Controller/Bridge/Hub",
+[DEVICE_CATEGORY_USB] = "USB",
+[DEVICE_CATEGORY_STORAGE] = "Storage",
+[DEVICE_CATEGORY_NETWORK] = "Network",
+[DEVICE_CATEGORY_INPUT] = "Input",
+[DEVICE_CATEGORY_DISPLAY] = "Display",
+[DEVICE_CATEGORY_SOUND] = "Sound",
+[DEVICE_CATEGORY_MISC]= "Misc",
+};
+
+return category_names[category];
+};
+
typedef int (*qdev_initfn)(DeviceState *dev);
typedef int (*qdev_event)(DeviceState *dev);
typedef void (*qdev_resetfn)(DeviceState *dev);
@@ -81,6 +109,7 @@ typedef struct DeviceClass {
ObjectClass parent_class;
/*< public >*/
+DECLARE_BITMAP(categories, DEVICE_CATEGORY_MAX);
const char *fw_name;
const char *desc;
Property *props;
diff --git a/qdev-monitor.c b/qdev-monitor.c
index e54dbc2..230a8df 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -75,24 +75,27 @@ static bool qdev_class_has_alias(DeviceClass *dc)
return (qdev_class_get_alias(dc) != NULL);
}
-static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
+static void qdev_print_class_devinfo(DeviceClass *dc)
{
-DeviceClass *dc;
-bool *show_no_user = opaque;
-
-dc = (DeviceClass *)object_class_dynamic_cast(klass, TYPE_DEVICE);
+DeviceCategory category;
-if (!dc || (show_no_user && !*show_no_user && dc->no_user)) {
+if (!dc) {
return;
}
-error_printf("name \"%s\"", object_class_get_name(klass));
+error_printf("name \"%s\"", object_class_get_name(OBJECT_CLASS(dc)));
if (dc->bus_type) {
error_printf(", bus %s", dc->bus_type);
}
if (qdev_class_has_alias(dc)) {
error_printf(", alias \"%s\"", qdev_class_get_alias(dc));
}
+error_printf(", categories");
+for (category = 0; category < DEVICE_CATEGORY_MAX; ++category) {
+if (test_bit(category, dc->categories)) {
+error_printf(" \"%s\"", qdev_category_get_name(category));
+}
+}
if (dc->desc) {
error_printf(", desc \"%s\"", dc->desc);
}
@@ -102,6 +105,15 @@ static void qdev_print_devinfo(ObjectClass *klass, void
*opaque)
error_printf("\n");
}
+static void qdev_print_devinfo(ObjectClass *klass, void *opaque)
+{
+DeviceClass *dc;
+
+dc = (DeviceClass *)object_class_dynamic_cast(klass, TYPE_DEVICE);
+
+qdev_print_class_devinfo(dc);
+}
+
static int set_property(const char *name, const char *value, void *opaque)
{
DeviceState *dev = opaque;
@@ -139,6 +151,21 @@ static const char *find_typename_by_alias(const char
*alias)
return NULL;
}
+static void qdev_print_category_devices(DeviceCategory category)
+{
+DeviceClass *dc;
+GSList *list, *c
Re: [Qemu-devel] [PATCH for 1.6] tci: Fix broken build (compiler warning caused by redefined macro BIT)
On Tue, 2013-07-30 at 22:41 +0200, Stefan Weil wrote: > The definition of macro BIT in tci/tcg-target.c now conflicts with the > definition of the same macro in includes qemu/bitops.h. > > This conflict was triggered by a recent change in the include chain of > tcg.c (probably commit 949fc82314cc84162e64a5323764527a542421ce). I would add explicit "#include qemu/bitops.h" For some reason the compilation was ok when the path was submitted, thanks! Marcel > > Signed-off-by: Stefan Weil > --- > tcg/tci/tcg-target.c |3 --- > 1 file changed, 3 deletions(-) > > diff --git a/tcg/tci/tcg-target.c b/tcg/tci/tcg-target.c > index d1241b5..e118bc7 100644 > --- a/tcg/tci/tcg-target.c > +++ b/tcg/tci/tcg-target.c > @@ -34,9 +34,6 @@ > tcg_abort(); \ > } while (0) > > -/* Single bit n. */ > -#define BIT(n) (1 << (n)) > - > /* Bitfield n...m (in 32 bit value). */ > #define BITS(n, m) (((0xU << (31 - n)) >> (31 - n + m)) << m) >
[Qemu-devel] pvpanic device should not be automatically included as an internal device
Hi, The problem with pvpanic being an internal device is that VMs running operating systems without a driver for this device will have problems when qemu will be upgraded (from qemu without this pvpanic). The outcome may be, for example: in Windows(let's say XP) the Device manager will open a "new device" wizard and the device will appear as an unrecognized device. Now what will happen on a cluster with hundreds of such VMs? If that cluster has a health monitoring service it may show all the VMs in a "not healthy" state. My point is that a device that requires a driver that is not "inbox", should not be present by default. One possible solution is to add it manually with -device from command line. Any thoughts? Marcel
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On Thu, 2013-08-01 at 19:31 +0300, Michael S. Tsirkin wrote: > On Thu, Aug 01, 2013 at 10:26:53AM -0600, Eric Blake wrote: > > On 08/01/2013 08:18 AM, Gerd Hoffmann wrote: > > > On 08/01/13 15:08, Marcel Apfelbaum wrote: > > >> Hi, > > >> > > >> The problem with pvpanic being an internal device is that VMs running > > >> operating systems without a driver for this device will have problems > > >> when qemu will be upgraded (from qemu without this pvpanic). > > >> > > >> The outcome may be, for example: in Windows(let's say XP) the Device > > >> manager > > >> will open a "new device" wizard and the device will appear as an > > >> unrecognized device. > > > > > > Only happens when also changing the machine type on upgrade as it is > > > turned off on old machine types. > > > > > > But, yes, pvpanic will show up as "Unknown device" without driver and > > > with the funky yellow exclamation mark in device manager in windows > > > guests. Newer windows versions don't kick the "new device" wizard. But > > > still I have my doubts that it is a good idea to add it unconditionally > > > ... > > > > Automatic devices with no command line argument have proven to be a > > nightmare for libvirt as well. Although the just-released libvirt 1.1.1 > > now supports the element for controlling the command line > > parameters of qemu related to how qemu will behave when the pvpanic > > device is triggered, I would also welcome having the ability to control > > whether the guest even has a pvpanic device exposed, just as we can > > control whether a guest has a memballoon device exposed. > > > A natural way to do this would be with -device pvpanic. > I'm not sure why it wasn't done like this from the beginning, > but it shouldn't be hard to redo, hopefully we can fix this > bug in time for 1.6. > I'll come up with something, hopefully in time. Marcel
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On Thu, 2013-08-01 at 16:32 +0300, Michael S. Tsirkin wrote: > On Thu, Aug 01, 2013 at 04:08:57PM +0300, Marcel Apfelbaum wrote: > > Hi, > > > > The problem with pvpanic being an internal device is that VMs running > > operating systems without a driver for this device will have problems > > when qemu will be upgraded (from qemu without this pvpanic). > > > > The outcome may be, for example: in Windows(let's say XP) the Device manager > > will open a "new device" wizard and the device will appear as an > > unrecognized device. > > Now what will happen on a cluster with hundreds of such VMs? If that > > cluster has a health > > monitoring service it may show all the VMs in a "not healthy" state. > > > > My point is that a device that requires a driver that is not "inbox", > > should not > > be present by default. > > One possible solution is to add it manually with -device from command line. > > > > Any thoughts? > > Marcel > > Interesting. You are basically saying we should have a rule > that no new builtin devices should be added > without an explicit request from management interface? Basically, yes. The only builtin devices shall be devices that the operating systems know how to handle with the default drivers. Marcel > >
[Qemu-devel] [PATCH for-1.6 V2 1/2] hw/misc: don't create pvpanic device by default
This patch is based on Hu Tao's:
http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00124.html
No need to hard-code pvpanic as part of the machine.
It can be added with "-device pvpanic" from command line (The next patch).
Anyway, for backport compatibility it is still part of 1.5
machine.
Signed-off-by: Marcel Apfelbaum
---
Changes from v1:
- Keep pvpanic device enabled by default for 1.5
for backport compatibility
hw/i386/pc_piix.c | 9 -
hw/i386/pc_q35.c | 7 ---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index ab25458..679d2e5 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -56,7 +56,7 @@ static const int ide_iobase[MAX_IDE_BUS] = { 0x1f0, 0x170 };
static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 };
static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
-static bool has_pvpanic = true;
+static bool has_pvpanic;
static bool has_pci_info = true;
/* PC hardware initialisation */
@@ -252,14 +252,15 @@ static void pc_init_pci(QEMUMachineInitArgs *args)
static void pc_init_pci_1_5(QEMUMachineInitArgs *args)
{
has_pci_info = false;
+has_pvpanic = true;
pc_init_pci(args);
}
static void pc_init_pci_1_4(QEMUMachineInitArgs *args)
{
-has_pvpanic = false;
x86_cpu_compat_set_features("n270", FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
-pc_init_pci_1_5(args);
+has_pci_info = false;
+pc_init_pci(args);
}
static void pc_init_pci_1_3(QEMUMachineInitArgs *args)
@@ -290,7 +291,6 @@ static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs
*args)
const char *kernel_cmdline = args->kernel_cmdline;
const char *initrd_filename = args->initrd_filename;
const char *boot_device = args->boot_device;
-has_pvpanic = false;
has_pci_info = false;
disable_kvm_pv_eoi();
enable_compat_apic_id_mode();
@@ -309,7 +309,6 @@ static void pc_init_isa(QEMUMachineInitArgs *args)
const char *kernel_cmdline = args->kernel_cmdline;
const char *initrd_filename = args->initrd_filename;
const char *boot_device = args->boot_device;
-has_pvpanic = false;
has_pci_info = false;
if (cpu_model == NULL)
cpu_model = "486";
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 2f35d12..d2bb248 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -46,7 +46,7 @@
/* ICH9 AHCI has 6 ports */
#define MAX_SATA_PORTS 6
-static bool has_pvpanic = true;
+static bool has_pvpanic;
static bool has_pci_info = true;
/* PC hardware initialisation */
@@ -220,14 +220,15 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
static void pc_q35_init_1_5(QEMUMachineInitArgs *args)
{
has_pci_info = false;
+has_pvpanic = true;
pc_q35_init(args);
}
static void pc_q35_init_1_4(QEMUMachineInitArgs *args)
{
-has_pvpanic = false;
x86_cpu_compat_set_features("n270", FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
-pc_q35_init_1_5(args);
+has_pci_info = false;
+pc_q35_init(args);
}
static QEMUMachine pc_q35_machine_v1_6 = {
--
1.8.3.1
[Qemu-devel] [PATCH for-1.6 V2 2/2] hw/misc: make pvpanic known to user
This patch is based on Hu Tao's:
http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00125.html
The pvpanic device may be enabled now with "-device pvpanic"
from command line.
Signed-off-by: Marcel Apfelbaum
---
Changes from V1:
- Addressed Andreas Färber review (removed bus type)
- Small changes to be posible to enable pvpanic
both from command line and from machine_init
- Added pvpanic to MISC category
hw/misc/pvpanic.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
index 7bb49a5..b64e3bb 100644
--- a/hw/misc/pvpanic.c
+++ b/hw/misc/pvpanic.c
@@ -97,29 +97,24 @@ static void pvpanic_isa_realizefn(DeviceState *dev, Error
**errp)
{
ISADevice *d = ISA_DEVICE(dev);
PVPanicState *s = ISA_PVPANIC_DEVICE(dev);
+FWCfgState *fw_cfg = fw_cfg_find();
+uint16_t *pvpanic_port;
-isa_register_ioport(d, &s->io, s->ioport);
-}
+if (!fw_cfg) {
+return;
+}
-static void pvpanic_fw_cfg(ISADevice *dev, FWCfgState *fw_cfg)
-{
-PVPanicState *s = ISA_PVPANIC_DEVICE(dev);
-uint16_t *pvpanic_port = g_malloc(sizeof(*pvpanic_port));
+pvpanic_port = g_malloc(sizeof(*pvpanic_port));
*pvpanic_port = cpu_to_le16(s->ioport);
-
fw_cfg_add_file(fw_cfg, "etc/pvpanic-port", pvpanic_port,
sizeof(*pvpanic_port));
+
+isa_register_ioport(d, &s->io, s->ioport);
}
void pvpanic_init(ISABus *bus)
{
-ISADevice *dev;
-FWCfgState *fw_cfg = fw_cfg_find();
-if (!fw_cfg) {
-return;
-}
-dev = isa_create_simple (bus, TYPE_ISA_PVPANIC_DEVICE);
-pvpanic_fw_cfg(dev, fw_cfg);
+isa_create_simple(bus, TYPE_ISA_PVPANIC_DEVICE);
}
static Property pvpanic_isa_properties[] = {
@@ -132,8 +127,8 @@ static void pvpanic_isa_class_init(ObjectClass *klass, void
*data)
DeviceClass *dc = DEVICE_CLASS(klass);
dc->realize = pvpanic_isa_realizefn;
-dc->no_user = 1;
dc->props = pvpanic_isa_properties;
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
}
static TypeInfo pvpanic_isa_info = {
--
1.8.3.1
[Qemu-devel] [PATCH for-1.6 V2 0/2] pvpanic: Separate pvpanic from machine type
Creating the pvpanic device as part of the machine type has the potential to trigger guest OS, guest firmware and driver bugs. The potential of such was originally viewed as minimal. However, since releasing 1.5 with pvpanic as part of the builtin machine type, several issues were observed in the field: - Some Windows versions triggered 'New Hardware Wizard' and an unidentified device appeared in Device Manager. - Issue reported off list: on Linux >= 3.10 the pvpanic driver breaks the reset on crash option: VM stops instead of being reset. pvpanic device also changes monitor command behaviour in some cases, such silent incompatible changes aren't expected by management tools: - Monitor command requires 'cont' before 'system_reset' in order to restart the VM after kernel panic/BSOD Note that libvirt is the main user and libvirt people indicated their preference to creating device with -device pvpanic rather than a built-in one that can't be removed. These issues were raised at last KVM call. The agreement reached there was that we were a bit too rash to make the device a builtin, and that for 1.6 we should drop the pvpanic device from the default machine type, instead teach management tools to add it by default using -device pvpanic. It's not clear whether changing 1.5 behaviour at this point is a sane thing, so this patchset doesn't touch 1.5 machine type. This patch series reworks the patchset from Hu Tao (don't create pvpanic device by default) addressing comments and modifying behaviour according to what was discussed on the call. Please review and consider for 1.6. A related discussion can be followed at http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00036.html. This is a continuation of patches sent by Hu Tao: http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00124.html http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00125.html Changes from v1 (by Hu Tao): - Keep pvpanic device enabled by default for 1.5 for backport compatibility - Addressed Andreas Färber review (removed bus type) - Small changes to be posible to enable pvpanic both from command line and from machine_init - Added pvpanic to MISC category Marcel Apfelbaum (2): hw/misc: don't create pvpanic device by default hw/misc: make pvpanic known to user hw/i386/pc_piix.c | 9 - hw/i386/pc_q35.c | 7 --- hw/misc/pvpanic.c | 25 ++--- 3 files changed, 18 insertions(+), 23 deletions(-) -- 1.8.3.1
Re: [Qemu-devel] [PATCH for-1.6 1/2] don't create pvpanic device by default.
On Sun, 2013-08-11 at 16:45 +0200, Andreas Färber wrote: > Am 11.08.2013 12:33, schrieb Michael S. Tsirkin: > > On Fri, Aug 02, 2013 at 10:27:31AM +0200, Paolo Bonzini wrote: > >> On 08/02/2013 09:04 AM, Hu Tao wrote: > >>> The problem with pvpanic being an internal device is that VMs running > >>> operating systems without a driver for this device will have problems > >>> when qemu will be upgraded (from qemu without this pvpanic). > >>> > >>> The outcome may be, for example: in Windows(let's say XP) the Device > >>> manager will open a "new device" wizard and the device will appear as > >>> an unrecognized device. On a cluster with hundreds of such VMs, If > >>> that cluster has a health monitoring service it may show all the VMs > >>> in a "not healthy" state. > >>> > >>> Reported-by: Marcel Apfelbaum > >>> Signed-off-by: Hu Tao > >> > >> NACK, > >> > >> this is premature. It is fundamentally a firmware problem. > >> > >> We have time to apply an even smaller patch that doesn't set > >> has_pvpanic to true, and delay the whole feature to 1.7, if we do > >> not fix the firmware in the next two weeks. > >> > >> Paolo > > > > I think this is not just a firmware problem. Adding device by default > > was too rush, assumption was risk of guest bugs was 0. > > > > We are now seeing problems with bios guest code and with linux guest > > drivers as well. Yes they all can be fixed, but we simply shouldn't > > force this risk of broken guests on everyone. > > > > libvirt is the main user and libvirt people > > indicated their preference to creating device with > > -device pvpanic rather than a built-in one that > > can't be removed. > > > > So please reconsider, and here's an ack from me. > > > > Acked-by: Michael S. Tsirkin > > NACK for this v1: As pointed out on the KVM call, we still need to keep > the pvpanic device around by default for pc-*-1.5. Removing has_pvpanic > completely therefore seems wrong. Can you submit a v2 for rc3 tomorrow? I just sent a patchset with V2. Can you please review it? Thanks, Marcel > > Andreas >
Re: [Qemu-devel] [PATCH for-1.6 V2 0/2] pvpanic: Separate pvpanic from machine type
On Mon, 2013-08-12 at 09:53 -0600, Eric Blake wrote: > On 08/11/2013 09:10 AM, Marcel Apfelbaum wrote: > > Creating the pvpanic device as part of the machine type has the > > potential to trigger guest OS, guest firmware and driver bugs. > > The potential of such was originally viewed as minimal. > > However, since releasing 1.5 with pvpanic as part > > of the builtin machine type, several issues were observed > > in the field: > > - Some Windows versions triggered 'New Hardware Wizard' and > >an unidentified device appeared in Device Manager. > > - Issue reported off list: on Linux >= 3.10 > >the pvpanic driver breaks the reset on crash option: > >VM stops instead of being reset. > > > > pvpanic device also changes monitor command behaviour in some cases, > > such silent incompatible changes aren't expected by management tools: > > - Monitor command requires 'cont' before 'system_reset' > >in order to restart the VM after kernel panic/BSOD > > > > Note that libvirt is the main user and libvirt people indicated their > > preference to creating device with -device pvpanic rather than a > > built-in one that can't be removed. > > > > These issues were raised at last KVM call. The agreement reached > > there was that we were a bit too rash to make the device > > a builtin, and that for 1.6 we should drop the pvpanic device from the > > default machine type, instead teach management tools to add it by > > default using -device pvpanic. > > It's not clear whether changing 1.5 behaviour at this point > > is a sane thing, so this patchset doesn't touch 1.5 machine type. > > Thanks for doing this; it makes sense to get this in for 1.6. From the > libvirt point of view: Eric, my pleasure! And I really think that using "-device pvpanic" is the right thing to to do. Marcel > > Series: Reviewed-by: Eric Blake >
Re: [Qemu-devel] [QEMU-1.6 PATCH] vl.c: Output error on invalid machine type provided
On Mon, 2013-08-12 at 18:28 +0200, Michal Novotny wrote:
> Output error message using qemu's error_report() function when user
> provides the invalid machine type on the command line. This also saves
> time to find what issue is when you downgrade from one version of qemu
> to another that doesn't support required machine type yet (the version
> user downgraded to have to have this patch applied too, of course).
>
> Signed-off-by: Michal Novotny
> ---
> vl.c | 5 +
> 1 file changed, 5 insertions(+)
>
Reviewed-by: Marcel Apfelbaum
> diff --git a/vl.c b/vl.c
> index f422a1c..9b4a3f9 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2671,6 +2671,11 @@ static QEMUMachine *machine_parse(const char *name)
> if (machine) {
> return machine;
> }
> +
> +if (name && !is_help_option(name)) {
> +error_report("Unsupported machine type");
> +}
> +
> printf("Supported machines are:\n");
> for (m = first_machine; m != NULL; m = m->next) {
> if (m->alias) {
[Qemu-devel] [PATCH] apci: fix ACPI tables for -no-hpet option
A wrong offset was added to the tables pointed by RSDT
if the HPET table is not present.
Signed-off-by: Marcel Apfelbaum
---
hw/i386/acpi-build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index c98df88..d65fab0 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1417,8 +1417,8 @@ void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables
*tables)
acpi_add_table(table_offsets, tables->table_data);
build_madt(tables->table_data, tables->linker, &cpu, guest_info);
-acpi_add_table(table_offsets, tables->table_data);
if (misc.has_hpet) {
+acpi_add_table(table_offsets, tables->table_data);
build_hpet(tables->table_data, tables->linker);
}
if (guest_info->numa_nodes) {
--
1.8.3.1
Re: [Qemu-devel] [PATCH v2] Add remove_boot_device_path() function for hot-unplug device
On Sun, 2014-05-11 at 11:07 +0800, lijun wrote:
> On 04/22/2014 05:21 PM, Marcel Apfelbaum wrote:
> > On Wed, 2014-04-16 at 22:20 +0800, Jun Li wrote:
> >> Add remove_boot_device_path() function to remove bootindex when hot-unplug
> >> a device. This patch fixed virtio-blk/virtio-net/scsi-disk/scsi-generic
> >> device.
> >> So it has fixed bug1086603, ref:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1086603
> >>
> >> Make some changes based on Andreas's good suggestion.
> >>
> >> Signed-off-by: Jun Li
> >> ---
> >> hw/block/virtio-blk.c | 1 +
> >> hw/net/virtio-net.c | 1 +
> >> hw/scsi/scsi-disk.c | 6 --
> >> hw/scsi/scsi-generic.c | 3 +++
> >> include/sysemu/sysemu.h | 2 ++
> >> vl.c| 16
> >> 6 files changed, 27 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> >> index 8a568e5..ecdd266 100644
> >> --- a/hw/block/virtio-blk.c
> >> +++ b/hw/block/virtio-blk.c
> >> @@ -752,6 +752,7 @@ static void virtio_blk_device_unrealize(DeviceState
> >> *dev, Error **errp)
> >> unregister_savevm(dev, "virtio-blk", s);
> >> blockdev_mark_auto_del(s->bs);
> >> virtio_cleanup(vdev);
> >> +remove_boot_device_path(s->conf->bootindex, dev, "/disk@0,0");
> >> }
> >>
> >> static Property virtio_blk_properties[] = {
> >> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> >> index 33bd233..520c029 100644
> >> --- a/hw/net/virtio-net.c
> >> +++ b/hw/net/virtio-net.c
> >> @@ -1633,6 +1633,7 @@ static void virtio_net_device_unrealize(DeviceState
> >> *dev, Error **errp)
> >> g_free(n->vqs);
> >> qemu_del_nic(n->nic);
> >> virtio_cleanup(vdev);
> >> +remove_boot_device_path(n->nic_conf.bootindex, dev,
> >> "/ethernet-phy@0");
> >> }
> >>
> >> static void virtio_net_instance_init(Object *obj)
> >> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> >> index 48a28ae..bb2176a 100644
> >> --- a/hw/scsi/scsi-disk.c
> >> +++ b/hw/scsi/scsi-disk.c
> >> @@ -2150,12 +2150,14 @@ static void scsi_disk_reset(DeviceState *dev)
> >> s->tray_open = 0;
> >> }
> >>
> >> -static void scsi_destroy(SCSIDevice *dev)
> >> +static void scsi_destroy(SCSIDevice *sdev)
> >> {
> >> -SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, dev);
> >> +SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, sdev);
> >> +DeviceState *dev = DEVICE(sdev);
> >>
> >> scsi_device_purge_requests(&s->qdev, SENSE_CODE(NO_SENSE));
> >> blockdev_mark_auto_del(s->qdev.conf.bs);
> >> +remove_boot_device_path(s->qdev.conf.bootindex, dev, NULL);
> >> }
> >>
> >> static void scsi_disk_resize_cb(void *opaque)
> >> diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c
> >> index 8d92e0d..2531a44 100644
> >> --- a/hw/scsi/scsi-generic.c
> >> +++ b/hw/scsi/scsi-generic.c
> >> @@ -388,8 +388,11 @@ static void scsi_generic_reset(DeviceState *dev)
> >>
> >> static void scsi_destroy(SCSIDevice *s)
> >> {
> >> +DeviceState *dev = DEVICE(s);
> >> +
> >> scsi_device_purge_requests(s, SENSE_CODE(NO_SENSE));
> >> blockdev_mark_auto_del(s->conf.bs);
> >> +remove_boot_device_path(s->conf.bootindex, dev, NULL);
> >> }
> >>
> >> static int scsi_generic_initfn(SCSIDevice *s)
> >> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> >> index ba5c7f8..f7ad1e2 100644
> >> --- a/include/sysemu/sysemu.h
> >> +++ b/include/sysemu/sysemu.h
> >> @@ -193,6 +193,8 @@ void rtc_change_mon_event(struct tm *tm);
> >>
> >> void add_boot_device_path(int32_t bootindex, DeviceState *dev,
> >> const char *suffix);
> >> +void remove_boot_device_path(int32_t bootindex, DeviceState *dev,
> >> + const char *suffix);
> >> char *get_boot_devices_list(size_t *size, bool ignore_suffixes);
> >>
> >> DeviceState *get_boot_device(uint32_t position);
> >> diff --git a/vl.c b/vl.c
> >> index 9975e5a..1713c68 100644
> >> ---
