Define PARAM so that we have two versions of the "desc_codec
and family" structs. Add a property called "mixer" whose default
value depends on whether CONFIG_MIXEMU is defined or not which
will help us call the appropriate instance init functions.
Signed-off-by: Bandan Da
Move common defines and structs to a header file.
We will then include these twice in hda-codec.c -
a version with mixer enabled and another with not enabled.
Signed-off-by: Bandan Das
---
hw/audio/hda-codec-common.h | 427
hw/audio/hda-codec.c
" although this
is not part of this change.
Bandan Das (2):
hda-codec: refactor common definitions into a header file
hda-codec: make mixemu selectable at runtime
hw/audio/hda-codec-common.h | 433
hw/audio/hda-
Markus Armbruster writes:
> Bandan Das writes:
>
>> Currently, hda-codec mixer emulation can only be enabled by using the
>> "--enable-mixemu" option to configure at compile time. These patches add
>> the option to make it configurable at runtime as well.
Paolo Bonzini writes:
> Il 08/06/2014 12:46, Michael S. Tsirkin ha scritto:
>> Tested-by: Michael S. Tsirkin
>
> You probably tested the reversal, actually. :)
>
> Actually, there is a reason for it. "Unassembling" the device
> (unparent) should come after "powering it down" (unrealize).
Yes,
Andreas Färber writes:
> Am 09.06.2014 19:02, schrieb Bandan Das:
>> Paolo Bonzini writes:
>>
>>> Il 08/06/2014 12:46, Michael S. Tsirkin ha scritto:
>>>> Tested-by: Michael S. Tsirkin
>>>
>>> You probably tested the reversal, a
commit 4b9430294ed added an option in vfio to blacklist
roms that are known to be unstable. Add a similar mechanism
for pci-assign as well. The default behavior is to disable
loading but can be overriden by specifying rombar or romfile
Signed-off-by: Bandan Das
---
Note: ignored checkpatch
Alex Williamson writes:
> On Fri, 2014-04-04 at 18:49 -0400, Bandan Das wrote:
>> commit 4b9430294ed added an option in vfio to blacklist
>> roms that are known to be unstable. Add a similar mechanism
>> for pci-assign as well. The default behavior is to disable
>> l
table
behavior
Signed-off-by: Bandan Das
---
hw/misc/vfio.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index e5b2826..c500067 100644
--- a/hw/misc/vfio.c
+++ b/hw/misc/vfio.c
@@ -191,6 +191,7 @@ typedef struct VFIODevice {
bool ha
Minor changes to print a message on the monitor
console in case of a rom read failure. Please see individual
patches for more details.
Bandan Das (2):
vfio: warn if host device rom can't be read
vfio: Do not reattempt a failed rom read
hw/misc/vfio.c | 12 +++-
in
ilure or option rom loading has been disabled from the device
boot menu (among other reasons).
Signed-off-by: Bandan Das
---
hw/misc/vfio.c | 7 +++
include/qemu/error-report.h | 20
2 files changed, 27 insertions(+)
diff --git a/hw/misc/vfio.c b/hw/misc/v
Ccing Markus for the *_once macros
Alex Williamson writes:
> On Tue, 2014-01-14 at 21:45 +0530, Bandan Das wrote:
>> If the device rom can't be read, report an error to the
>> user. The guest might try to read the rom contents more than
>> once, so introduce macros
avior
Signed-off-by: Bandan Das
---
v2: Check for vdev->rom first followed by the rom_read_failed flag
hw/misc/vfio.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index d2e68e2..5ed9cbe 100644
--- a/hw/misc/vfio.c
+++ b/hw/misc/vfio.c
@@ -191,
If the device rom can't be read, report an error to the
user. This alerts the user that the device has a bad
state that is causing rom read failure or option rom
loading has been disabled from the device boot menu
(among other reasons).
Signed-off-by: Bandan Das
---
v2: Removed the macr
Minor changes to print a message on the monitor
console in case of a rom read failure. Please see individual
patches for more details.
Bandan Das (2):
vfio: warn if host device rom can't be read
vfio: Do not reattempt a failed rom read
hw/misc/vfio.c | 13 +
1 file change
rtain cases such as a firmware upgrade, the user might
want to override this blacklisting behavior and can do so
by running with rombar = 1. Same reasoning applies to running with
romfile.
Signed-off-by: Bandan Das
---
hw/misc/vfio.c | 63 ++
h
Alex Williamson writes:
> On Wed, 2014-02-19 at 11:12 -0500, Bandan Das wrote:
>> Certain cards such as the Broadcom BCM57810 have rom quirks
>> that exhibit unstable system behavior duing device assignment. In
>> the particular case of 57810, rom execution hangs and if
Alex Williamson writes:
> On Wed, 2014-02-19 at 13:58 -0500, Bandan Das wrote:
>> Alex Williamson writes:
>>
>> > On Wed, 2014-02-19 at 11:12 -0500, Bandan Das wrote:
>> >> Certain cards such as the Broadcom BCM57810 have rom quirks
>> >> th
vfio_pci_size_rom()
Bandan Das (2):
pci: change default value of rom_bar to 2
vfio: blacklist loading of unstable roms
hw/misc/vfio.c | 58 ++
hw/pci/pci.c | 7 ++-
2 files changed, 64 insertions(+), 1 deletion(-)
--
1.8.3.1
rom for such cards
unless the user specifies a romfile or rombar=1 on the cmd line
Signed-off-by: Bandan Das
---
hw/misc/vfio.c | 58 ++
1 file changed, 58 insertions(+)
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index 8db182f..58f348e
The following patch depends on the value of rom_bar to
determine rom blacklist behavior. Existing code shouldn't
be affected by changing the default value of rom_bar since
all relevant decisions only rely on whether rom_bar is zero
or non-zero.
Signed-off-by: Bandan Das
---
hw/pci/pci.
Alex Williamson writes:
> On Wed, 2014-02-19 at 15:20 -0500, Bandan Das wrote:
>> The following patch depends on the value of rom_bar to
>> determine rom blacklist behavior. Existing code shouldn't
>> be affected by changing the default value of rom_bar since
>>
"Michael S. Tsirkin" writes:
> On Wed, Feb 19, 2014 at 03:20:54PM -0500, Bandan Das wrote:
>> The following patch depends on the value of rom_bar to
>> determine rom blacklist behavior. Existing code shouldn't
>> be affected by changing the default va
Alex Williamson writes:
> On Wed, 2014-02-19 at 15:20 -0500, Bandan Das wrote:
>> Certain cards such as the Broadcom BCM57810 have rom quirks
>> that exhibit unstable system behavior duing device assignment. In
>> the particular case of 57810, rom execution hangs and if
at 10:12 +0200, Michael S. Tsirkin wrote:
>> > > > On Wed, Feb 19, 2014 at 03:20:54PM -0500, Bandan Das wrote:
>> > > > > The following patch depends on the value of rom_bar to
>> > > > > determine rom blacklist behavior. Existing code shouldn'
Setting opts before the realize property is set allows the
following patch to make decisions based on whether the user
specified "rombar". This also avoids having to create a new
tristate property especially for this purpose
Signed-off-by: Bandan Das
---
qdev-monitor.c | 4 +++-
1 fi
infrastructural changes
2. Change vendor_id and device_id type to uint16_t
3. Rename struct for blacklisted devid and vendorid to more meaningful names
4. Remove unnecessary rom_quirk variable and just call vfio_blacklist_opt_rom()
in vfio_pci_size_rom()
Bandan Das (2):
qdev-monitor: set DeviceSt
cards unless the user
specifies a romfile or rombar=1 on the cmd line
Signed-off-by: Bandan Das
---
hw/misc/vfio.c | 60 ++
1 file changed, 60 insertions(+)
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index 8db182f..df3ceee 100644
--- a/hw
Alex Williamson writes:
> On Mon, 2014-02-24 at 23:34 -0500, Bandan Das wrote:
>> Certain cards such as the Broadcom BCM57810 have rom quirks
>> that exhibit unstable system behavior duing device assignment. In
>> the particular case of 57810, rom execution hangs and if
endor_id and device_id type to uint16_t
3. Rename struct for blacklisted devid and vendorid to more meaningful names
4. Remove unnecessary rom_quirk variable and just call vfio_blacklist_opt_rom()
in vfio_pci_size_rom()
Bandan Das (2):
qdev-monitor: set DeviceState opts before calling realize
vfio:
cards unless the user
specifies a romfile or rombar=1 on the cmd line
Signed-off-by: Bandan Das
---
hw/misc/vfio.c | 73 ++
1 file changed, 73 insertions(+)
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index 8db182f..3a854f9 100644
--- a/hw
Setting opts before the realize property is set allows the
following patch to make decisions based on whether the user
specified "rombar". This also avoids having to create a new
tristate property especially for this purpose
Reviewed-by: Andreas Färber
Signed-off-by: Bandan Das
Based on the trace in the attachment, the sequence of config space
accesses leading up to the hang -
vfio: vfio_pci_write_config(:03:00.0, @0x78, 0x1, len=0x4)
vfio: vfio_pci_write_config(:03:00.0, @0x80, 0x9430, len=0x4)
vfio: vfio_pci_write_config(:03:00.0, @0x78, 0xa30c, len=0x4)
vf
Public bug reported:
With a Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet
card, device assignment does not work. The guest hangs during option rom
execution. Moreover, if an attempt is made to quit qemu when the guest
is in the hung state, the card gets into an inoperable state. O
It has been suggested to blacklist loading of rom for this card (and for any
other similar card that exhibit such issues) by default, a patch has been
posted upstream and is going several iterations based on reviews. The most
uptodate series is
[PATCH 0/2 v3] vfio: blacklist loading of unstable
Comments from Alex Williamson :
> The sequence leading up to this is quite short. We do standard PCI BAR
> sizing and setup, read the ROM, then do:
>
> vfio: vfio_pci_write_config(:03:00.0, @0x78, 0x1, len=0x4)
> vfio: vfio_pci_write_config(:03:00.0, @0x80, 0x9430, len=0x4)
> vfio: vfio_p
The vfio code has logic that checks if a FLR is possible and attempts it
before and after device assignment. Replacing the FLR with a bus reset
succeeds past the stuck option rom loading phase and we are able to boot
into the guest successfully which means that the first initialization
(by the hard
commit e638073c569e801ce9de added a flag to track whether
a previous rom read had failed. Accidentally, the code
ended up adding vfio_load_option_rom twice. (Thanks to Alex
for spotting it)
Signed-off-by: Bandan Das
---
hw/misc/vfio.c | 5 +
1 file changed, 1 insertion(+), 4 deletions
Change to VFIO_DEBUG in vfio_msi_interrupt() for debug
messages to get printed
Signed-off-by: Bandan Das
---
hw/misc/vfio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index 9aecaa8..a87078c 100644
--- a/hw/misc/vfio.c
+++ b/hw/misc
Paolo Bonzini writes:
> Resetting should be done in post-order, not pre-order. However,
> qdev_walk_children and qbus_walk_children do not allow this. Fix
> it by adding two extra arguments to the functions.
> Signed-off-by: Paolo Bonzini
> ---
> hw/core/qdev.c | 45
Paolo Bonzini writes:
> Il 07/12/2013 00:27, Bandan Das ha scritto:
>> Paolo Bonzini writes:
>>
>>> Resetting should be done in post-order, not pre-order. However,
>>> qdev_walk_children and qbus_walk_children do not allow this. Fix
>>> it by a
Paolo Bonzini writes:
> Il 09/12/2013 18:56, Bandan Das ha scritto:
>>> > This is a generic walk function.
>>> > For reset you want post-order, but in other cases pre-order may make
>>> > more sense, for example realize.
>> Sorry, not sure
Bandan Das writes:
> These patches add realize and unrealize interfaces to BusState just
> like we have for DeviceState. 1/3 and 2/3 implement the interface and
> attempt to integrate it to the existing DeviceState call path.
> 3/3 is an example user of the interface, pci in this
PCIBus registers a vmstate during init. Unregister it upon
removal/unplug.
Signed-off-by: Bandan Das
---
Note that I didn't add a instance_init to register vmstate (yet)
due to concerns expressed by Andreas that we shouldn't be registering
global state there.
hw/pci/pci.c | 8 +
; +} else {
> +vdev->pdev.config[PCI_HEADER_TYPE] &=
> ~PCI_HEADER_TYPE_MULTI_FUNCTION;
> +}
> +
> /*
> * Clear host resource mapping info. If we choose not to register a
> * BAR, such as might be the case with the option ROM, we can get
Reviewed-by: Bandan Das
Andreas Färber writes:
> Am 06.11.2013 23:52, schrieb Bandan Das:
>>
>> PCIBus registers a vmstate during init. Unregister it upon
>> removal/unplug.
>>
>> Signed-off-by: Bandan Das
>
> Michael, this patch looks good for 1.7 to me, are you plannin
Andreas Färber writes:
> Am 19.11.2013 18:03, schrieb Bandan Das:
>> Andreas Färber writes:
>>
>>> Am 06.11.2013 23:52, schrieb Bandan Das:
>>>>
>>>> PCIBus registers a vmstate during init. Unregister it upon
>>>> removal/unplug.
>
ectors; i++) {
> +if (vdev->msi_vectors[i].use) {
> +vfio_msix_vector_release(&vdev->pdev, i);
> +}
> +}
> +
> if (vdev->nr_vectors) {
> vfio_disable_irqindex(vdev, VFIO_PCI_MSIX_IRQ_INDEX);
> }
Reviewed-by: Bandan Das
Add simple set/get functions for bus. The setter also checks if it has
children devices and sets "realize" accordingly.
Signed-off-by: Bandan Das
---
hw/core/qdev.c | 67 ++
include/hw/qdev-core.h | 7 ++
2 files c
more details.
Bandan Das (3):
qdev: add realize/unrealize interfaces for BusState
qdev: Integrate the bus realized property to get
called when device realized property changes
pci: move vmstate_pcibus registration/unregistration to realize
and unrealize interfaces
hw/core/qdev.c
recent value of the "realized" property so that an event
can be sent when the device is being removed. Third, it reorders code
in device_unparent so that unrealize can be recursively called for
its children
Signed-off-by: Bandan Das
---
hw/core/qdev.c
Relocate some stuff to avoid forward declarations and use the
realize and unrealize hooks to call into register and unregister vmstate_pcibus
respectively
Signed-off-by: Bandan Das
---
hw/pci/pci.c | 49 -
1 file changed, 28 insertions(+), 21
Hi Cole,
Cole Robinson writes:
> The following commit introduced a migration incompatibility:
>
> commit 568f0690fd9aa4d39d84b04c1a5dbb53a915c3fe
> Author: David Gibson
> Date: Thu Jun 6 18:48:49 2013 +1000
>
> pci: Replace pci_find_domain() with more general pci_root_bus_path()
>
> The i
le format for 1.7+, and <= 1.5.
>
> Tested with migration from qemu 1.5, qemu 1.6, and qemu.git.
>
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Cole Robinson
> ---
Reviewed-by: Bandan Das
> v2:
> Drop needless 1.7 compat bits
>
> hw/pci-host/piix.c|
Gerd Hoffmann writes:
> On Mo, 2015-03-16 at 14:16 -0400, Bandan Das wrote:
>> Jan Kiszka writes:
>>
>> > Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
>> >> On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
>> >>> Hi,
>> >>>
[Ccing netdev and Stefan]
Bandan Das writes:
> jacob jacob writes:
>
>> On Mon, Mar 16, 2015 at 2:12 PM, Bandan Das wrote:
>>> jacob jacob writes:
>>>
>>>> I also see the following in dmesg in the VM.
>>>>
>>>> [
[Ccing qemu-devel and kvm]
"Boylan, Ross" writes:
> Running a Windows 7 VM under KVM, with virtio drivers, the networking was so
> slow as to be non-functional.
> As suggested in comment 11 of
> https://bugzilla.redhat.com/show_bug.cgi?id=855640, I did ethtool -K eth1 gro
> off and speeds go
Hi Andrey,
Andrey Korolyov writes:
> On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov wrote:
>> For now, it looks like bug have a mixed Murphy-Heisenberg nature, as
>> it appearance is very rare (compared to the number of actual launches)
>> and most probably bounded to the physical characteri
Radim Krčmář writes:
> 2015-03-26 21:24+0300, Andrey Korolyov:
>> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote:
>> > 2015-03-26 20:08+0300, Andrey Korolyov:
>> >> KVM internal error. Suberror: 2
>> >> extra data[0]: 80ef
>> >> extra data[1]: 8b0d
>> >
>> > Btw. does this part ever
Andrey Korolyov writes:
...
> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz
>
> Something a bit more interesting, but the mess is happening just
> *after* NMI firing.
What happens if NMI is turned off on the host ?
Bandan Das writes:
> Andrey Korolyov writes:
> ...
>> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz
>>
>> Something a bit more interesting, but the mess is happening just
>> *after* NMI firing.
>
> What happens if NMI i
Markus Armbruster writes:
> Bandan Das writes:
>
...
>> -static void user_async_cmd_handler(Monitor *mon, const mon_cmd_t *cmd,
>> +static int user_async_cmd_handler(Monitor *mon, const mon_cmd_t *cmd,
>> const QDict *param
v2:
Split up the command name and arguments parsing into
separate functions. [1/2]
Skip checking for failures with commands that use the .cmd_new
interface or the async interface since they are scheduled
for removal [2/2]
Bandan Das (2):
monitor: cleanup parsing of cmd name and cmd arguments
s and return a
QDict.
Suggested-by: Markus Armbruster
Signed-off-by: Bandan Das
---
monitor.c | 84 ++-
1 file changed, 51 insertions(+), 33 deletions(-)
diff --git a/monitor.c b/monitor.c
index b2561e1..f0c1a8c 100644
--- a/monitor.c
dd: string expected
Try "help drive_add" for more information
Signed-off-by: Bandan Das
---
monitor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/monitor.c b/monitor.c
index f0c1a8c..af73195 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4138,6 +4138,8 @@ static void handle_user_command
s and return a
QDict. Also, pass a pointer to the cmdline to track current
parser location.
Suggested-by: Markus Armbruster
Signed-off-by: Bandan Das
---
monitor.c | 90 +--
1 file changed, 53 insertions(+), 37 deletions(-)
diff --git a/moni
ecking for failures with commands that use the .cmd_new
interface or the async interface since they are scheduled
for removal [2/2]
Bandan Das (2):
monitor: cleanup parsing of cmd name and cmd arguments
When a command fails due to incorrect syntax or input, suggest
using the "help"
Before:
(qemu) drive_add usb_flash_drive
drive_add: string expected
After:
(qemu) drive_add usb_flash_drive
drive_add: string expected
Try "help drive_add" for more information
Reviewed-by: Markus Armbruster
Signed-off-by: Bandan Das
---
monitor.c | 2 ++
1 file changed, 2 insertion
Markus Armbruster writes:
> Bandan Das writes:
>
>> There's too much going on in monitor_parse_command().
>> Split up the arguments parsing bits into a separate function
>> monitor_parse_arguments(). Let the original function check for
>> command validity and
Eric Blake writes:
> On 05/28/2015 12:48 PM, Bandan Das wrote:
>> Markus Armbruster writes:
>>
>>> Bandan Das writes:
>>>
>>>> There's too much going on in monitor_parse_command().
>>>> Split up the arguments parsing bits in
Andrey Korolyov writes:
> On Fri, Mar 6, 2015 at 1:14 AM, Andrey Korolyov wrote:
>> Hello,
>>
>> recently I`ve got a couple of shiny new Intel 2620v2s for future
>> replacement of the E5-2620v1, but I experienced relatively many events
>> with emulation errors, all traces looks simular to the on
Paolo Bonzini writes:
> On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
>> I'm seeing something similar; it's very intermittent and generally
>> happening right at boot of the guest; I'm running this on qemu
>> head+my postcopy world (but it's happening right at boot before postcopy
>> gets
"Dr. David Alan Gilbert" writes:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
>>
>>
>> On 10/03/2015 19:21, Bandan Das wrote:
>> > Paolo Bonzini writes:
>> >
>> >> On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
>> >
"Kevin O'Connor" writes:
...
>
> Something is very odd here. When I run the above command (on an older
> AMD machine) I get:
>
> Found 128 cpu(s) max supported 128 cpu(s)
>
> That first value (1 vs 128) comes from QEMU (via cmos index 0x5f).
> That is, during smp init, SeaBIOS expects QEMU to tel
"Kevin O'Connor" writes:
> On Wed, Mar 11, 2015 at 01:09:42PM -0400, Bandan Das wrote:
>> "Kevin O'Connor" writes:
>> ...
>> >
>> > Something is very odd here. When I run the above command (on an older
>> > AMD machine) I
"Dr. David Alan Gilbert" writes:
> * Kevin O'Connor (ke...@koconnor.net) wrote:
>> On Wed, Mar 11, 2015 at 04:52:03PM +, Dr. David Alan Gilbert wrote:
>> > * Kevin O'Connor (ke...@koconnor.net) wrote:
>> > > So, I couldn't get this to fail on my older AMD machine at all with
>> > > the defaul
"Dr. David Alan Gilbert" writes:
> * Kevin O'Connor (ke...@koconnor.net) wrote:
>> On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote:
>> > On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote:
>> > > For what it's worth, I can't seem to trigger the problem if I move the
>>
jacob jacob writes:
> Hi,
>
> Seeing failures when trying to do PCI passthrough of Intel XL710 40G
> interface to KVM vm.
> 0a:00.1 Ethernet controller: Intel Corporation Ethernet
> Controller XL710 for 40GbE QSFP+ (rev 01)
You are assigning the PF right ? Does assigning VFs work or it's
jacob jacob writes:
> On Thu, Mar 12, 2015 at 3:07 PM, Bandan Das wrote:
>> jacob jacob writes:
>>
>>> Hi,
>>>
>>> Seeing failures when trying to do PCI passthrough of Intel XL710 40G
>>> interface to KVM vm.
>>> 0a:00.1 Et
and VF passthrough i see issues. It
>> is always pointing to some issue with packet transmission. Receive
>> seems to work ok.
>>
>>
>> On Thu, Mar 12, 2015 at 8:02 PM, Bandan Das wrote:
>>> jacob jacob writes:
>>>
>>>> On Thu, Mar 12, 2015
Jan Kiszka writes:
> Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
>> On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
>>> Hi,
>>>
>>> apparently since the latest QEMU updates I'm getting this once in a
>>> while:
>>
>> http://www.seabios.org/pipermail/seabios/2015-March/008897.html
>
> OK...
jacob jacob writes:
> On Mon, Mar 16, 2015 at 2:12 PM, Bandan Das wrote:
>> jacob jacob writes:
>>
>>> I also see the following in dmesg in the VM.
>>>
>>> [0.095758] ACPI: PCI Root Bridge [PCI0] (domain [bus 00-ff])
>>> [0.0960
Paolo Bonzini writes:
> CS.RPL is not equal to the CPL in the few instructions between
> setting CR0.PE and reloading CS. We get this right in the common
> case, because writes to CR0 do not modify the CPL, but it would
> not be enough if an SMI comes exactly during that brief period.
> Were thi
Paolo Bonzini writes:
> With the next patch, these need to be correct or VM86 tasks
> have the wrong CPL. The flags are basically what the Intel VMX
> documentation say is mandatory for entry into a VM86 guest.
Are you referring to 26.3.1.2 ? Just a nit, I guess it helps
to add a pointer in th
Michael Tokarev writes:
> 02.06.2014 17:30, Alex Williamson wrote:
>> On Mon, 2014-06-02 at 14:32 +0400, Michael Tokarev wrote:
>>> 01.06.2014 20:25, Alex Williamson wrote:
The latest Nvidia driver (337.88) specifically checks for KVM as the
hypervisor and reports Code 43 for the driver
Alex Williamson writes:
> The latest Nvidia driver (337.88) specifically checks for KVM as the
> hypervisor and reports Code 43 for the driver in a Windows guest when
> found. Removing or changing the KVM signature is sufficient for the
> driver to load and work. This patch adds an option to ea
Jidong Xiao writes:
> On Wed, Jun 4, 2014 at 3:09 AM, Paolo Bonzini wrote:
>> Il 04/06/2014 03:10, Jidong Xiao ha scritto:
>>
>>> diff --git a/qemu-2.0.0/target-i386/kvm.c.orig
>>> b/qemu-2.0.0/target-i386/kvm.c
>>> index 4389959..b8b282d 100644
>>> --- a/qemu-2.0.0/target-i386/kvm.c.orig
>>> ++
Jidong Xiao writes:
..
>>
> Hi, Bandan,
>
> Thanks for the advice. I think Paolo has incorporated this patch into
> his patch sets, and he sent the revised version in a separate email
> earlier today with the subject "[PULL 11/11] kvm: Fix eax for cpuid
> leaf 0x4000".
Oops! Sorry, must have
supports it.
Bandan Das (3):
usb-mtp: use a list for keeping track of children
usb-mtp: Add support for inotify based file monitoring
usb-mtp: add support for basic mtp events
hw/usb/dev-mtp.c | 339 +++
trace-events | 4 +
2 files
To support adding/removal of objects, we will need to update
the object cache hierarchy we have built internally. Convert
to using a Qlist for easier management.
Signed-off-by: Bandan Das
---
hw/usb/dev-mtp.c | 67 +---
trace-events | 1
For now, we use inotify watches to track only a small number of
events, namely, add, delete and modify. Note that for delete, the kernel
already deactivates the watch for us and we just need to
take care of modifying our internal state.
Suggested-by: Gerd Hoffman
Signed-off-by: Bandan Das
When the host polls for events, we check our
events qlist and send one event at a time. Also, note
that the event packet needs to be sent in one go, so
I increased the max packet size to 64.
Tested with a linux guest.
Signed-off-by: Bandan Das
---
hw/usb/dev-mtp.c | 44
Gerd Hoffmann writes:
>> static void usb_mtp_object_free(MTPState *s, MTPObject *o)
>> {
>> -int i;
>> +MTPObject *iter;
>> +
>> +if (o) {
>> +trace_usb_mtp_object_free(s->dev.addr, o->handle, o->path);
>
> That also makes usb_mtp_object_free callable with o == NULL. Makes
Gerd Hoffmann writes:
>> +#include
>
> What happens on non-linux systems?
>
> I guess we need some #ifdefs to not break the build there, or enable mtp
> only for CONFIG_LINUX=y instead of CONFIG_POSIX=y.
Oh, I had the ifdefs but somehow I confused myself by thinking CONFIG_POSIX
is enough not t
Gerd Hoffmann writes:
> On Di, 2015-11-03 at 19:00 -0500, Bandan Das wrote:
>> -.wMaxPacketSize= 8,
>> +.wMaxPacketSize= 64,
>
> This is a guest-visible change, so strictly speaking this needs be tied
> to the machine type. I thin
Gerd Hoffmann writes:
> On Di, 2015-11-03 at 19:00 -0500, Bandan Das wrote:
>> +/* Add a new watch asap so as to not lose events
>> */
>
> This comment sounds like there is a race ("asap"). There isn't one,
> correct ordering (adding
Gerd Hoffmann writes:
> On Di, 2015-11-03 at 19:00 -0500, Bandan Das wrote:
>> +case IN_DELETE:
>> +/*
>> + * The kernel issues a IN_IGNORED event
>> + * when a dir containing a watchpoint is
>
Bandan Das writes:
> Gerd Hoffmann writes:
>
>> On Di, 2015-11-03 at 19:00 -0500, Bandan Das wrote:
>>> +/* Add a new watch asap so as to not lose events
>>> */
>>
>> This comment sounds like there is a race ("asap"). Th
to compile
mtp support for linux only but that seems a bit restrictive.
Change behavior for "failed events" Instead of bailing out immediately,
check if there's still some left that we can process.
4/4: No change
Bandan Das (4):
usb-mtp: use a list for keeping track of
On a reset, call usb_mtp_object_free on all objects and their children
Signed-off-by: Bandan Das
---
hw/usb/dev-mtp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index eea2dad..c39b81a 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -907,6
1 - 100 of 375 matches
Mail list logo
