On 14-06-25 11:52 PM, Peter Crosthwaite wrote:
> On Thu, Jun 26, 2014 at 4:58 AM, Paolo Bonzini wrote:
>> Il 25/06/2014 19:53, Etienne Martineau ha scritto:
>>
>>>
>>> It seems to me that there is a scale issue O(n) in
>>> memory_region_transaction_commit
On 14-06-26 04:18 AM, Avi Kivity wrote:
>
> On 06/25/2014 08:53 PM, Etienne Martineau wrote:
>> Hi,
>>
>> It seems to me that there is a scale issue O(n) in
>> memory_region_transaction_commit().
>
> It's actually O(n^3). Flatview is kept sorted bu
On 14-06-25 02:58 PM, Paolo Bonzini wrote:
> Il 25/06/2014 19:53, Etienne Martineau ha scritto:
>>
>> It seems to me that there is a scale issue O(n) in
>> memory_region_transaction_commit().
>>
>> Basically the time it takes to rebuild the memory
Hi,
It seems to me that there is a scale issue O(n) in
memory_region_transaction_commit().
Basically the time it takes to rebuild the memory view during device assignment
pci_bridge_update_mappings() increase linearly with respect to the number of
device already assigned to the guest.
I'm run
Hi Marcel, thanks for your reply.
On 14-05-28 05:10 AM, Marcel Apfelbaum wrote:
> This is correct since now you are using a Root Complex Port.
> If you don't want to use a config file use:
>
> [...] -device ioh3420,bus=pcie.0,id=ich9-pcie-port-1,slot=3
You're right I could have done it on the c
ultifunction = "on"
bus = "pcie.0"
B) Upon disk unplug QEMU is crashing. This is with recent qemu.git. The
following patch
solve the issue.
Signed-off-by: Etienne Martineau
---
hw/pci/pcie.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --
Hi,
When using virtio disk plug/unplug with Q35 machine I see two problems.
Note that when using the same sequence with default 440FX I see no issues.
A) 'pcie.0' does not support hotplugging'
I can workaround this problem if I manually specify "-readconfig
/usr/share/qemu-153/Q35-chipset.cf
On Wed, 17 Nov 2010, Isaku Yamahata wrote:
> > Because of such it seems like the only way to maintain consistency between
> > the assigned device and it's corresponding driver is to perform the error
> > detection/recovery phase in lockstep with the host?
>
> Maybe. At least at the first imple
On Tue, 2010-11-16 at 17:26 +0900, Isaku Yamahata wrote:
> add aer support.
>
> Signed-off-by: Isaku Yamahata
I'm actually working on a scheme to provide support to handle PCI
errors related to assigned devices. The goal is to notify the
coresponding driver so that all his I/O access are stop
Hi all,
My current understanding of Qemu-kvm is such that whenever Guest VM
establish a passthrough to a pci devices, the following happens:
Setup:
- vt-d setup
- Host mmap the device's BAR via /sysfs.
- Host maintain a 'ptr' to that mmap'ed area.
- Host create a mmio slot for the Guest.
- The mm
10 matches
Mail list logo
