On 26 September 2017 at 18:27, Thomas Huth wrote:
> On 25.09.2017 19:59, Eduardo Habkost wrote:
>> On Mon, Sep 25, 2017 at 07:42:13PM +0200, Thomas Huth wrote:
>> "make check" found a few candidates:
>> https://travis-ci.org/ehabkost/qemu/jobs/278743999
>>
>> Initialization of device dpcd failed
On 25.09.2017 19:59, Eduardo Habkost wrote:
> On Mon, Sep 25, 2017 at 07:42:13PM +0200, Thomas Huth wrote:
>> On 25.09.2017 17:26, Peter Maydell wrote:
>>> On 25 September 2017 at 16:19, Thomas Huth wrote:
Not sure whether this works for the virtio-xxx-device devices,
though, since they
On 26 September 2017 at 03:59, Eduardo Habkost wrote:
> On Mon, Sep 25, 2017 at 07:05:26PM +0100, Peter Maydell wrote:
>> On 25 September 2017 at 18:59, Eduardo Habkost wrote:
>> If we just diff "list of devices marked hotplug before this patch"
>> against "list of devices marked hotplug after th
On 26.09.2017 07:26, Bharata B Rao wrote:
> On Fri, Sep 22, 2017 at 11:16:34AM +0200, Thomas Huth wrote:
>> Historically we've marked all devices as hotpluggable by default. However,
>> most devices are not hotpluggable, and you also need a HotplugHandler to
>> support these devices. So if the user
On Fri, Sep 22, 2017 at 11:16:34AM +0200, Thomas Huth wrote:
> Historically we've marked all devices as hotpluggable by default. However,
> most devices are not hotpluggable, and you also need a HotplugHandler to
> support these devices. So if the user tries to "device_add" or "device_del"
> such a
On 26.09.2017 04:59, Eduardo Habkost wrote:
> On Mon, Sep 25, 2017 at 07:05:26PM +0100, Peter Maydell wrote:
>> On 25 September 2017 at 18:59, Eduardo Habkost wrote:
>>> Finding the full list of devices that can be instantiated
>>> internally at hotplug-time sounds tricky.
>>
>> If we just diff "l
On Mon, Sep 25, 2017 at 07:05:26PM +0100, Peter Maydell wrote:
> On 25 September 2017 at 18:59, Eduardo Habkost wrote:
> > Finding the full list of devices that can be instantiated
> > internally at hotplug-time sounds tricky.
>
> If we just diff "list of devices marked hotplug before this patch"
On 25 September 2017 at 19:20, Eduardo Habkost wrote:
> On Mon, Sep 25, 2017 at 07:02:06PM +0100, Peter Maydell wrote:
>> On 25 September 2017 at 18:51, Eduardo Habkost wrote:
>> > On Mon, Sep 25, 2017 at 06:45:15PM +0100, Peter Maydell wrote:
>> >> You should be able to on the command line for x
On Mon, Sep 25, 2017 at 07:02:06PM +0100, Peter Maydell wrote:
> On 25 September 2017 at 18:51, Eduardo Habkost wrote:
> > On Mon, Sep 25, 2017 at 06:45:15PM +0100, Peter Maydell wrote:
> >> You should be able to on the command line for x86 do something
> >> like -device virtio-pci,... -device vir
On Mon, Sep 25, 2017 at 07:05:26PM +0100, Peter Maydell wrote:
> On 25 September 2017 at 18:59, Eduardo Habkost wrote:
> > Finding the full list of devices that can be instantiated
> > internally at hotplug-time sounds tricky.
>
> If we just diff "list of devices marked hotplug before this patch"
On 25 September 2017 at 18:59, Eduardo Habkost wrote:
> Finding the full list of devices that can be instantiated
> internally at hotplug-time sounds tricky.
If we just diff "list of devices marked hotplug before this patch"
against "list of devices marked hotplug after this patch" how
big is the
On 25 September 2017 at 18:51, Eduardo Habkost wrote:
> On Mon, Sep 25, 2017 at 06:45:15PM +0100, Peter Maydell wrote:
>> You should be able to on the command line for x86 do something
>> like -device virtio-pci,... -device virtio-foo-device,...
>> to manually create the pci transport and the back
On Mon, Sep 25, 2017 at 07:42:13PM +0200, Thomas Huth wrote:
> On 25.09.2017 17:26, Peter Maydell wrote:
> > On 25 September 2017 at 16:19, Thomas Huth wrote:
> >> Not sure whether this works for the virtio-xxx-device devices,
> >> though, since they are marked as user_creatable = true currently..
On Mon, Sep 25, 2017 at 06:45:15PM +0100, Peter Maydell wrote:
> On 25 September 2017 at 18:42, Thomas Huth wrote:
> > On 25.09.2017 17:26, Peter Maydell wrote:
> >> On 25 September 2017 at 16:19, Thomas Huth wrote:
> >>> Not sure whether this works for the virtio-xxx-device devices,
> >>> though
On Mon, Sep 25, 2017 at 04:26:44PM +0100, Peter Maydell wrote:
> On 25 September 2017 at 16:19, Thomas Huth wrote:
> > Not sure whether this works for the virtio-xxx-device devices,
> > though, since they are marked as user_creatable = true currently...
>
> That's deliberate -- for the arm boards
On 25 September 2017 at 18:42, Thomas Huth wrote:
> On 25.09.2017 17:26, Peter Maydell wrote:
>> On 25 September 2017 at 16:19, Thomas Huth wrote:
>>> Not sure whether this works for the virtio-xxx-device devices,
>>> though, since they are marked as user_creatable = true currently...
>>
>> That'
On 25.09.2017 17:26, Peter Maydell wrote:
> On 25 September 2017 at 16:19, Thomas Huth wrote:
>> Not sure whether this works for the virtio-xxx-device devices,
>> though, since they are marked as user_creatable = true currently...
>
> That's deliberate -- for the arm boards with virtio-mmio
> the
On 25 September 2017 at 16:19, Thomas Huth wrote:
> Not sure whether this works for the virtio-xxx-device devices,
> though, since they are marked as user_creatable = true currently...
That's deliberate -- for the arm boards with virtio-mmio
the board creates a bunch of virtio-mmio transports and
On 25.09.2017 16:34, Eduardo Habkost wrote:
> On Mon, Sep 25, 2017 at 03:46:47PM +0200, Igor Mammedov wrote:
>> On Mon, 25 Sep 2017 10:31:53 -0300
>> Eduardo Habkost wrote:
>>
>>> On Mon, Sep 25, 2017 at 01:53:16PM +0200, Cornelia Huck wrote:
On Fri, 22 Sep 2017 11:16:34 +0200
Thomas Hut
On Mon, Sep 25, 2017 at 03:46:47PM +0200, Igor Mammedov wrote:
> On Mon, 25 Sep 2017 10:31:53 -0300
> Eduardo Habkost wrote:
>
> > On Mon, Sep 25, 2017 at 01:53:16PM +0200, Cornelia Huck wrote:
> > > On Fri, 22 Sep 2017 11:16:34 +0200
> > > Thomas Huth wrote:
> > >
> > > > Historically we've
On Mon, 25 Sep 2017 10:31:53 -0300
Eduardo Habkost wrote:
> On Mon, Sep 25, 2017 at 01:53:16PM +0200, Cornelia Huck wrote:
> > On Fri, 22 Sep 2017 11:16:34 +0200
> > Thomas Huth wrote:
> >
> > > Historically we've marked all devices as hotpluggable by default. However,
> > > most devices are
On Mon, Sep 25, 2017 at 01:53:16PM +0200, Cornelia Huck wrote:
> On Fri, 22 Sep 2017 11:16:34 +0200
> Thomas Huth wrote:
>
> > Historically we've marked all devices as hotpluggable by default. However,
> > most devices are not hotpluggable, and you also need a HotplugHandler to
> > support these
On Fri, 22 Sep 2017 11:16:34 +0200
Thomas Huth wrote:
> Historically we've marked all devices as hotpluggable by default. However,
> most devices are not hotpluggable, and you also need a HotplugHandler to
> support these devices. So if the user tries to "device_add" or "device_del"
> such a non-
On 22/09/2017 12:16, Thomas Huth wrote:
Historically we've marked all devices as hotpluggable by default. However,
most devices are not hotpluggable, and you also need a HotplugHandler to
support these devices. So if the user tries to "device_add" or "device_del"
such a non-hotpluggable device du
On Fri, Sep 22, 2017 at 11:16:34AM +0200, Thomas Huth wrote:
> Historically we've marked all devices as hotpluggable by default. However,
> most devices are not hotpluggable, and you also need a HotplugHandler to
> support these devices. So if the user tries to "device_add" or "device_del"
> such a
Historically we've marked all devices as hotpluggable by default. However,
most devices are not hotpluggable, and you also need a HotplugHandler to
support these devices. So if the user tries to "device_add" or "device_del"
such a non-hotpluggable device during runtime, either nothing really usable
26 matches
Mail list logo
