On 03/19/15 01:18, Gabriel L. Somlo wrote:
> Exit with an error (instead of simply logging a trace event)
> whenever the same fw_cfg file name is added multiple times via
> one of the fw_cfg_add_file[_callback]() host-side API calls.
>
> Signed-off-by: Gabriel Somlo
> ---
> hw/nvram/fw_cfg.c | 1
On Fri, Mar 20, 2015 at 05:04:01PM +1100, David Gibson wrote:
>On Tue, Mar 17, 2015 at 03:31:24AM +1100, Gavin Shan wrote:
>> The PCI device MSIx table is cleaned out in hardware after EEH PE
>> reset. However, we still hold the stale MSIx entries in QEMU, which
>> should be cleared accordingly. Ot
We don't validate the backend queue numbers against bus limitation,
this will easily crash qemu if it exceeds the limitation which will
hit the abort() in virtio_del_queue(). An example is trying to
starting a virtio-net device with 256 queues. E.g:
./qemu-system-x86_64 -netdev tap,id=hn0,queues=2
On Tue, Mar 17, 2015 at 03:31:24AM +1100, Gavin Shan wrote:
> The PCI device MSIx table is cleaned out in hardware after EEH PE
> reset. However, we still hold the stale MSIx entries in QEMU, which
> should be cleared accordingly. Otherwise, we will run into another
> (recursive) EEH error and the
On Fri, Mar 20, 2015 at 1:53 PM, Jason Wang wrote:
On Thu, Mar 19, 2015 at 6:12 PM, Michael S. Tsirkin
wrote:
On Thu, Mar 19, 2015 at 03:05:52PM +0800, Jason Wang wrote:
Virtqueue were indexed from zero, so don't delete virtqueue whose
index is n->max_queues * 2 + 1.
But what's the c
On Fri, Mar 20, 2015 at 03:01:43PM +1100, Gavin Shan wrote:
>On Wed, Mar 18, 2015 at 03:54:09PM +1100, Gavin Shan wrote:
>>On Tue, Mar 17, 2015 at 03:16:46PM -0600, Alex Williamson wrote:
>>>On Tue, 2015-03-17 at 03:31 +1100, Gavin Shan wrote:
When Linux guest recovers from EEH error on the fo
On Thu, Mar 19, 2015 at 6:12 PM, Michael S. Tsirkin
wrote:
On Thu, Mar 19, 2015 at 03:05:52PM +0800, Jason Wang wrote:
Virtqueue were indexed from zero, so don't delete virtqueue whose
index is n->max_queues * 2 + 1.
But what's the current behaviour?
Can it lead to aborts? virtio_del_qu
On Thu, Mar 19, 2015 at 6:10 PM, Michael S. Tsirkin
wrote:
On Thu, Mar 19, 2015 at 03:05:51PM +0800, Jason Wang wrote:
We don't validate the backend queue numbers against bus limitation,
this will easily crash qemu if it exceeds the limitation. Fixing
this
by doing the validation and fa
On Thu, Mar 19, 2015 at 6:09 PM, Michael S. Tsirkin
wrote:
On Thu, Mar 19, 2015 at 01:19:23PM +0800, Jason Wang wrote:
On Wed, Mar 18, 2015 at 8:52 PM, Michael S. Tsirkin
wrote:
>On Wed, Mar 18, 2015 at 05:35:08PM +0800, Jason Wang wrote:
>> This patch let msix_init_exclusive_bar()
On Thu, Mar 19, 2015 at 6:02 PM, Michael S. Tsirkin
wrote:
On Thu, Mar 19, 2015 at 01:23:56PM +0800, Jason Wang wrote:
On Wed, Mar 18, 2015 at 8:57 PM, Michael S. Tsirkin
wrote:
>On Wed, Mar 18, 2015 at 05:35:09PM +0800, Jason Wang wrote:
>> Currently we don't support more than 128
On Thu, Mar 19, 2015 at 6:01 PM, Michael S. Tsirkin
wrote:
On Thu, Mar 19, 2015 at 01:23:12PM +0800, Jason Wang wrote:
On Wed, Mar 18, 2015 at 8:57 PM, Michael S. Tsirkin
wrote:
>On Wed, Mar 18, 2015 at 05:35:09PM +0800, Jason Wang wrote:
>> Currently we don't support more than 128
> > >> The command takes a list of key-value pairs. Looks like this
> > >> (example stolen from your patch to qmp-commands.hx):
> > >>
> > >> { "execute": "migrate-set-parameters",
> > >> "arguments": { "parameters":
> > >> [ { "parameter": "compress-level", "value":
On Thu, Mar 19, 2015 at 5:23 PM, Michael S. Tsirkin
wrote:
On Thu, Mar 19, 2015 at 03:42:56PM +0800, Jason Wang wrote:
On Thu, Mar 19, 2015 at 3:32 PM, Michael S. Tsirkin
wrote:
>On Thu, Mar 19, 2015 at 01:24:53PM +0800, Jason Wang wrote:
>> On Wed, Mar 18, 2015 at 8:58 PM, Mich
On Thu, 19 Mar 2015 10:50:49 +0100
"Michael S. Tsirkin" wrote:
> On Wed, Mar 11, 2015 at 04:35:41PM +1100, David Gibson wrote:
> > > > > So it boils down to the fact that windows thinks it's RAM,
> > > > It thinks it's PCI Standard RAM Controller not RAM itself.
> > > >
> > > > > so it binds a g
showing a memory device whose memdev is removed leads an assert:
(qemu) object_add memory-backend-ram,id=ram0,size=128M
(qemu) device_add pc-dimm,id=d0,memdev=ram0
(qemu) object_del ram0
(qemu) info memory-devices
**
ERROR:qom/object.c:1274:object_get_canonical_path_component:\
On Wed, Mar 18, 2015 at 03:54:09PM +1100, Gavin Shan wrote:
>On Tue, Mar 17, 2015 at 03:16:46PM -0600, Alex Williamson wrote:
>>On Tue, 2015-03-17 at 03:31 +1100, Gavin Shan wrote:
>>> When Linux guest recovers from EEH error on the following Emulex
>>> adapter, the MSIx interrupts are disabled and
The IO operations for the i6300esb watchdog timer are marked as
DEVICE_NATIVE_ENDIAN. This is not correct, and - as a PCI device - should
be DEVICE_LITTLE_ENDIAN.
This allows i6300esb to work on ppc targets (yes, using an Intel ICH
derived device on ppc is a bit odd, but the driver exists on the
If the guest programs a sufficiently large timeout value an integer
overflow can occur in i6300esb_restart_timer(). e.g. if the maximum
possible timer preload value of 0xf is programmed then we end up with
the calculation:
timeout = get_ticks_per_sec() * (0xf << 15) / 3300;
get_ticks
This series fixes two bugs in the i6300esb watchdog timer device. The
first only affects big-endian targets (including targets like ppc
which support both endians, but are considered big-endian by default).
The second affects all targets, but only when the guest uses unusually
large timeout values
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Thursday, March 19, 2015 8:57 PM
> To: Xu, Quan
> Cc: ke...@koconnor.net; stef...@linux.vnet.ibm.com; xen-de...@lists.xen.org;
> qemu-devel@nongnu.org; stefano.stabell...@eu.citrix.com
> Subject: Re: [Xen-d
"Michael S. Tsirkin" writes:
> On Mon, Mar 16, 2015 at 01:44:22PM +1030, Rusty Russell wrote:
>> diff --git a/content.tex b/content.tex
>> index 6ba079d..2c946a5 100644
>> --- a/content.tex
>> +++ b/content.tex
>> @@ -600,10 +600,19 @@ them: it is only written to by the device, and read by
>> the
On 2015/3/19 20:08, Jan Kiszka wrote:
> Probably a copy&paste bug. Fixing it helps identifying the device model
> behind port 0x61.
>
> Signed-off-by: Jan Kiszka
> ---
> hw/audio/pcspk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Gonglei
> diff --git a/hw/audio/pc
On 2015/3/19 18:44, Ian Campbell wrote:
On Thu, 2015-03-19 at 10:07 +0800, Chen, Tiejun wrote:
This duplicates the code from above. I think this would be best done as:
static int libxl__detect_gfx_passthru_kind(libxl__gc *gc, guest_config)
{
if (b_info->u.hvm.gfx_passthru_kind != LIBXL_
This does not bother DMA, because DMA generally transfers
the entire SGList in one shot if it can.
PIO, on the other hand, tries to transfer just one sector
at a time, and will make multiple visits to the sglist
to fetch memory addresses.
Fix the memory address calculaton when we have an offset
b
Two issues were unearthed from ahci-test on ppc64:
(1) The ahci_populate_sglist function had endian issues,
which is only likely to impact PIO transfers for buffers
greater than one sector, and
(2) multiple-sector PIO which I attempted to repair in
36334faf has been broken for years.
My pattern was cyclical every 256 bytes, so it missed a fairly obvious
failure case. Add some rand() pepper into the test pattern, and for large
patterns that exceed 256 sectors, start writing an ID per-sector so that
we never generate identical sector patterns.
Signed-off-by: John Snow
---
test
We need to adjust the sector being written to
prior to calling ide_transfer_start, otherwise
we'll write to the same sector again.
Signed-off-by: John Snow
---
hw/ide/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index ef52f35..0e9da64 1
Similar to the cmd_write_pio fix, update the nsector count and
ide sector before we invoke ide_transfer_start.
Signed-off-by: John Snow
---
hw/ide/core.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 0e9da64..a895fd8 100644
--- a/
On Fri, Mar 20, 2015 at 2:23 AM, Andreas Färber wrote:
> increate -> increase
>
> Signed-off-by: Andreas Färber
Reviewed-by: Alistair Francis
Thanks,
Alistair
> ---
> scripts/checkrom.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/checkrom.py b/scripts/c
On Thu, Mar 19, 2015 at 5:53 PM, jacob jacob wrote:
> On Thu, Mar 19, 2015 at 5:42 PM, Shannon Nelson
> wrote:
>> On Thu, Mar 19, 2015 at 2:04 PM, jacob jacob wrote:
>>> I have updated to latest firmware and still no luck.
>>
>> [...]
>>
>>> [ 61.554132] i40e :00:06.0 eth2: the driver fail
On 03/19/2015 04:38 PM, Alberto Garcia wrote:
>> And for this particular event, which is not tied to block jobs but
>> to generic block operation, isn't it possible that we could be
>> reporting a corrupted backing chain where we have neither a device
>> name (it is not the active layer) nor a nod
On Thu, Mar 19, 2015 at 04:15:49PM -0600, Eric Blake wrote:
> >>> -# @device: device name
> >>> +# @device: device name, or node name if not present
> >>
> >> I think just adding a @node-name field and keeping @device as it
> >> is should be good enough here.
> >
> > I was doing the same that we
On 03/03/2015 01:13 PM, Max Reitz wrote:
> When bdrv_close_all() is called, instead of force-closing all root
> BlockDriverStates, it is better to just drop the reference from all
> BlockBackends and let them be closed automatically. This prevents BDS
> from getting closed that are still referenced
On 03/19/2015 03:42 PM, Alberto Garcia wrote:
> (I forgot to Cc Eric in this series, doing it now)
>
> On Thu, Mar 19, 2015 at 03:42:35PM -0400, Max Reitz wrote:
>>> # Emitted when a corruption has been detected in a disk image
>>> #
>>> -# @device: device name
>>> +# @device: device name, or no
On Thu, Mar 19, 2015 at 05:52:52PM -0400, Max Reitz wrote:
> So in this case here I don't really see a benefit of reusing @device
> instead of just adding @node-name, whereas adding @node-name will
> have the benefit of not affecting anybody and (in my opinion) being
> more explicit. However, if o
On Thu, Mar 19, 2015 at 5:42 PM, Shannon Nelson
wrote:
> On Thu, Mar 19, 2015 at 2:04 PM, jacob jacob wrote:
>> I have updated to latest firmware and still no luck.
>
> [...]
>
>> [ 61.554132] i40e :00:06.0 eth2: the driver failed to link
>> because an unqualified module was detected. <
On 2015-03-19 at 17:42, Alberto Garcia wrote:
(I forgot to Cc Eric in this series, doing it now)
On Thu, Mar 19, 2015 at 03:42:35PM -0400, Max Reitz wrote:
# Emitted when a corruption has been detected in a disk image
#
-# @device: device name
+# @device: device name, or node name if not pr
On Thu, Mar 19, 2015 at 03:37:13PM -0400, Max Reitz wrote:
> > This series adds a new function bdrv_get_device_or_node_name(),
> > that returns the node name if there is no device name for that
> > node. Since both the device and the node name live in the same
> > namespace, there's no ambiguity.
On 19/03/2015 19:52, Marcel Apfelbaum wrote:
> hw/pci-host/piix.c | 128 -
> hw/pci-host/ppce500.c | 1 +
> hw/pci-host/q35.c | 5 +
> hw/pci-host/uninorth.c | 1 +
> hw/pci/Makefile.objs| 2 +-
> hw/pc
On 16/03/2015 05:57, Michael S. Tsirkin wrote:
> >1. add 'x-aer' for user to off aer capability.
>
> User-exposed properties should not start with x- - by convention
> that's for internal properties.
Wrong, x- is for properties that we don't guarantee to remain there in
the future. It look
On Thu, Mar 19, 2015 at 2:04 PM, jacob jacob wrote:
> I have updated to latest firmware and still no luck.
[...]
> [ 61.554132] i40e :00:06.0 eth2: the driver failed to link
> because an unqualified module was detected.
> [ 61.555331] IPv6: ADDRCONF(NETDEV_UP): e
(I forgot to Cc Eric in this series, doing it now)
On Thu, Mar 19, 2015 at 03:42:35PM -0400, Max Reitz wrote:
> > # Emitted when a corruption has been detected in a disk image
> > #
> >-# @device: device name
> >+# @device: device name, or node name if not present
>
> Normally, if a field in QM
On 18/03/2015 20:05, Alex Williamson wrote:
> > OK, so maybe it's a feature that users should have control over.
> > But tying it to machine types makes no sense.
>
> If we were to change the default, where else would you tie it? Machine
> types are the only finger hold we have to maintain VM st
I have updated to latest firmware and still no luck.
]# ethtool -i eth1
driver: i40e
version: 1.2.37
firmware-version: f4.33.31377 a1.2 n4.42 e1930
bus-info: :00:05.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
On 03/19/2015 01:03 PM, Max Reitz wrote:
> This flag is set if write accesses to BDSs managed by the respective
> driver may lead to writes beyond the end of the underlying file BDS,
> expecting it to increase its size accordingly.
>
> This behavior, however, is only supported by protocol BDSs hav
On 03/19/2015 01:03 PM, Max Reitz wrote:
> This flag is set if the BDS's size can be increased by writing beyond
> its end.
>
> Signed-off-by: Max Reitz
> ---
> block.c | 4
> block/blkdebug.c | 2 ++
> block/blkverify.c | 2 ++
> block/iscsi.c
On 2015-03-19 at 11:43, Alberto Garcia wrote:
Since this event can occur in nodes that don't have a device name
associated, use the node name as fallback in those cases.
Signed-off-by: Alberto Garcia
---
block/qcow2.c | 5 +++--
docs/qmp/qmp-events.txt | 2 +-
qapi/block-core.json
With the Intel microcode update that removed HLE and RTM, there will be
different kinds of Haswell and Broadwell CPUs out there: some that still
have the HLE and RTM features, and some that don't have the HLE and RTM
features. On both cases people may be willing to use the pc-*-2.3
machine-types.
This reverts commit 13704e4c455770d500d6b87b117e32f0d01252c9.
With the Intel microcode update that removed HLE and RTM, there will be
different kinds of Haswell and Broadwell CPUs out there: some that still
have the HLE and RTM features, and some that don't have the HLE and RTM
features. On both c
The following changes since commit 3e5f6234b4f45a11b7c357dde2d6da36641bc6f6:
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
(2015-03-19 17:47:08 +)
are available in the git repository at:
https://github.com/ehabkost/qemu.git tags/x86-pull-request
for you to
On 2015-03-19 at 11:43, Alberto Garcia wrote:
We have several cases of error messages related to BlockDriverState that expect
it to have a device name.
However many of those can happen in nodes that don't have a device name
associated so the generated error messages are not very meaningful.
T
On 2015-03-19 at 11:43, Alberto Garcia wrote:
There are several error messages that identify a BlockDriverState by
its device name. However those errors can be produced in nodes that
don't have a device name associated.
In those cases we should use bdrv_get_device_or_node_name() to fall
back to
PCI root buses can be attached to a specific NUMA node.
PCI buses are not attached be default to a NUMA node.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pci_bus.c | 7 +++
include/hw/pci/pci_bus.h | 6 ++
include/sysemu/sysemu.h | 1 +
3 files changed, 14 insertions(+)
diff --g
On 19 March 2015 at 19:00, Peter Maydell wrote:
> (I'm currently running the merge through the usual tests
> before pushing it out.)
...the tests seem to be OK. However there are at least 3
commits here which don't have your signed-off-by as
the submaintainer. Please can you respin?
(I recommend
From: Igor Mammedov
Since commit
dd0247e0 pc: acpi: mark all possible CPUs as enabled in SRAT
Linux kernel actually tries to use CPU to Node mapping from
QEMU provided SRAT table instead of discarding it, and that
in some cases breaks build_sched_domains() which expects
sane mapping where core
We need all possible CPUs (including hotplug ones) to be present in the
SRAT when QEMU starts. QEMU already does that correctly today, the only
problem is that when a CPU is omitted from the NUMA configuration, it is
silently assigned to node 0.
Check if all CPUs up to max_cpus are present in the
Each CPU can appear in only one NUMA node on the NUMA config. Reject
configuration if a CPU appears in multiple nodes.
Reviewed-by: Igor Mammedov
Signed-off-by: Eduardo Habkost
---
numa.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/numa.c b/numa.c
The following changes since commit 3e5f6234b4f45a11b7c357dde2d6da36641bc6f6:
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
(2015-03-19 17:47:08 +)
are available in the git repository at:
https://github.com/ehabkost/qemu.git tags/work/numa-verify-cpus-pull-r
From: Igor Mammedov
Current default round-robin way of distributing VCPUs among
NUMA nodes might be wrong in case on multi-core/threads
CPUs. Making guests confused wrt topology where cores from
the same socket are on different nodes.
Allow a machine to override default mapping by providing
Mac
CPU index is always less than max_cpus, as documented at sysemu.h:
> The following shall be true for all CPUs:
> cpu->cpu_index < max_cpus <= MAX_CPUMASK_BITS
Reject configuration which uses invalid CPU indexes.
Reviewed-by: Igor Mammedov
Signed-off-by: Eduardo Habkost
---
numa.c | 8 +-
Fix the CPU index check to ensure we don't go beyond the size of the
node_cpu bitmap.
CPU index is always less than MAX_CPUMASK_BITS, as documented at
sysemu.h:
> The following shall be true for all CPUs:
> cpu->cpu_index < max_cpus <= MAX_CPUMASK_BITS
Reviewed-by: Igor Mammedov
Signed-off-by
On 2015-03-19 at 11:43, Alberto Garcia wrote:
This function gets the device name associated with a BlockDriverState,
or its node name if the device name is empty.
Signed-off-by: Alberto Garcia
---
block.c | 5 +
block/quorum.c| 5 +
include/block/block.h | 1 +
On 03/19/2015 01:03 PM, Max Reitz wrote:
> iotests 072 and 089 create a nested qcow2-in-qcow2 image. This should be
> opened read-only, for one because it is indeed read only, and also
> because writing to it would probably turn out bad (the outer qcow2 image
> cannot grow on demand, so no clusters
We need all possible CPUs (including hotplug ones) to be present in the
SRAT when QEMU starts. QEMU already does that correctly today, the only
problem is that when a CPU is omitted from the NUMA configuration, it is
silently assigned to node 0.
Check if all CPUs up to max_cpus are present in the
This adds extra checks to the NUMA code to make sure the CPU configuration is
consistent. This needs to be applied on top of my numa patch queue:
https://github.com/ehabkost/qemu.git numa
Changes v1 -> v2:
* (none, v1 was tagged by accident and never sent to qemu-devel)
Changes v2 -> v3:
* F
On 03/03/2015 01:13 PM, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> block.c| 2 ++
> blockdev.c | 18 ++
> include/block/block_int.h | 4
> stubs/Makefile.objs| 1 +
> stub
On 03/03/2015 01:13 PM, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> block.c | 10 ++
> include/block/block_int.h | 2 ++
> 2 files changed, 12 insertions(+)
>
Might be nice to mention in the commit message why it is useful. But
the code looked good enough for
iotests 072 and 089 create a nested qcow2-in-qcow2 image. This should be
opened read-only, for one because it is indeed read only, and also
because writing to it would probably turn out bad (the outer qcow2 image
cannot grow on demand, so no clusters can be allocated for the inner
one).
Signed-off
This flag is set if write accesses to BDSs managed by the respective
driver may lead to writes beyond the end of the underlying file BDS,
expecting it to increase its size accordingly.
This behavior, however, is only supported by protocol BDSs having the
BDS.growing flag set. If they do not, emit
QEMU does not compile cleanly under clang 3.5.0. These patches eliminate the
avalanche of warnings and make the build usable.
v3:
- Drop tricore patch, it's already being worked on elsewhere.
- Factor out flag check test.
v2:
- Stole the series from Stefan
- No changes to the -nopie patch, whi
Test if ccache is interfering with our life, and
disable its habit of trying to compile already pre-processed
versions of code if so.
In particular, clang has different semantic warnings based on
if the warning arose from a macro or not. By trying to build
preprocessed versions of code, we get mor
Some image formats (e.g. qcow2) require the underlying file to grow on
write accesses, but this is in fact not supported by all protocols (e.g.
nbd does not). If such a format requiring file growth is used
non-read-only over a protocol which does not support this, a warning
should be issued.
This
Signed-off-by: Marcel Apfelbaum
---
docs/pci_expander_bridge.txt | 52
1 file changed, 52 insertions(+)
create mode 100644 docs/pci_expander_bridge.txt
diff --git a/docs/pci_expander_bridge.txt b/docs/pci_expander_bridge.txt
new file mode 100644
inde
From: Stefan Hajnoczi
gcc 4.9.2 treats -nopie as an error:
cc: error: unrecognized command line option ‘-nopie’
clang 3.5.0 treats -nopie as a warning:
clang: warning: argument unused during compilation: '-nopie'
The causes ./configure to fail with clang:
ERROR: configure test passed w
Factor out the function that checks if a compiler
flag is supported or not.
Signed-off-by: John Snow
---
configure | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/configure b/configure
index 062df84..9a0e4ef 100755
--- a/configure
+++ b/
The pxb can be attach to and existing numa node by specifying
numa_node option that equals the desired numa nodeid.
Signed-off-by: Marcel Apfelbaum
---
hw/i386/acpi-build.c| 6 ++
hw/pci-bridge/pci_expander_bridge.c | 17 +
2 files changed, 23 insertions(+)
The glib headers use GCC attributes. Unfortunately the __GNUC__ and
__GNUC_MINOR__ version macros are also defined by clang, but clang
doesn't support the same attributes as GCC.
clang 3.5.0 does not support the __alloc_size__ attribute:
https://github.com/llvm-mirror/clang/commit/c047507a9a7
On 19 March 2015 at 14:50, Gerd Hoffmann wrote:
> Oh, right, forgot to mention in the cover letter: One of the patches
> introduces a new config option (CONFIG_USB), and because of that you
> have to do a full rebuild to make sure the new option is picked up for
> the targets which need usb.
I t
Save the IO/mem/bus numbers ranges assigned to the extra root busses
to be removed from the root bus 0 range.
Signed-off-by: Marcel Apfelbaum
---
hw/i386/acpi-build.c | 138 +++
1 file changed, 138 insertions(+)
diff --git a/hw/i386/acpi-build.c b
From: Marcel Apfelbaum
PXB is a "light-weight" host bridge whose purpose is to enable
the main host bridge to support multiple PCI root buses
for pc machines.
As oposed to PCI-2-PCI bridge's secondary bus, PXB's bus
is a primary bus and can be associated with a NUMA node
(different from the main
From: Marcel Apfelbaum
Use the newer pci_bus_num to correctly get the root bus number.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 3570431..59369ab 100644
--- a/hw/pci/pci.c
+++ b/hw/pc
From: Marcel Apfelbaum
This is a marker interface used to differentiate the
"default" host bridge on a system with multiple host bridges.
This differentiation is required only for pc machines for now
by the ACPI subsystem.
Signed-off-by: Marcel Apfelbaum
---
hw/i386/acpi-build.c | 9 +
This flag is set if the BDS's size can be increased by writing beyond
its end.
Signed-off-by: Max Reitz
---
block.c | 4
block/blkdebug.c | 2 ++
block/blkverify.c | 2 ++
block/iscsi.c | 2 ++
block/nbd.c | 2 ++
block/qcow2.c
From: Marcel Apfelbaum
Refactoring it as a method of PCIBusClass will allow
different implementations for subclasses.
Signed-off-by: Marcel Apfelbaum
---
hw/i386/kvm/pci-assign.c | 1 +
hw/pci/pci.c | 7 ---
hw/pci/pci_bus.c | 10 ++
hw/scsi/megasas.c|
PXB does not work with unsupported bioses, but should
not interfere with normal OS operation.
We don't ship them anymore, but it's reasonable
to keep the work-around until we update the bios in qemu.
Fix this by not adding PXB mem/IO chunks to _CRS
if they weren't configured by BIOS.
Signed-off-b
This refactoring moves all the code needed (recursively)
to register TYPE_PCI_BUS type to a new file hw/pci/pci_bus.c .
This allows to properly add new functionality to the pci bus class.
Signed-off-by: Marcel Apfelbaum
---
arch_init.c | 1 +
hw/alpha/typhoon.c | 1 +
hw/m
The PIIX holds a list of snooping host bridges that is populated
by a registration function that shall be used by any host bridge
that needs to use PIIX configuration space to complete their
configuration cycles.
PIIX monitors acceses to configuration registers and passes them
to the corresponding
From: Marcel Apfelbaum
The bios looks for 'etc/extra-pci-roots' to decide if
is going to scan further buses after bus 0 tree.
Signed-off-by: Marcel Apfelbaum
---
hw/i386/pc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 79eaad5..7a8c6dd 1
The bios does not index the pxb slot number when
it computes the IRQ because it resides on bus 0
and not on the current bus.
However Qemu routes the irq through bus 0 and adds
the pxb slot to the IRQ computation of the PXB device.
Synchronize between bios and Qemu by canceling
pxb's effect.
Signe
Add encoding for ACPI DefShiftLeft Opcode.
Reviewed-by: Igor Mammedov
Signed-off-by: Marcel Apfelbaum
---
hw/acpi/aml-build.c | 10 ++
include/hw/acpi/aml-build.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index ad8c04d..428
TYPE_PCI_HOST_BRIDGE_SNOOPED is a special case of host bridge
whose configuration registers are snooped by other host bridges
to complete their configuration cycles.
The interface exposes a list of snooping host bridges that
shall be used by the hosts implementing this interface
in order to emulat
If multiple root busses are used, root bus 0 cannot use all the
pci holes ranges. Remove the IO/mem ranges used by the other
primary busses.
Signed-off-by: Marcel Apfelbaum
---
hw/i386/acpi-build.c | 90
1 file changed, 77 insertions(+), 13 de
Signed-off-by: Marcel Apfelbaum
---
hw/i386/acpi-build.c | 81
1 file changed, 81 insertions(+)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index ecd5684..4964d6b 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -65
Add encoding for ACPI DefLLess Opcode.
Reviewed-by: Shannon Zhao
Reviewed-by: Igor Mammedov
Signed-off-by: Marcel Apfelbaum
---
hw/acpi/aml-build.c | 9 +
include/hw/acpi/aml-build.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.
If the machine has extra root busses that are snooping to
the i440fx host bridge, we need to add them to
acpi in order to be properly detected by guests.
Signed-off-by: Marcel Apfelbaum
---
hw/i386/acpi-build.c | 30 --
hw/pci-host/piix.c | 4 ++--
include/hw/i386/
Add encoding for ACPI DefShiftRight Opcode.
Reviewed-by: Igor Mammedov
Signed-off-by: Marcel Apfelbaum
---
hw/acpi/aml-build.c | 10 ++
include/hw/acpi/aml-build.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 428ea47..64
Add encoding for ACPI DefWhile Opcode.
Reviewed-by: Shannon Zhao
Reviewed-by: Igor Mammedov
Signed-off-by: Marcel Apfelbaum
---
hw/acpi/aml-build.c | 8
include/hw/acpi/aml-build.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
The BDRV_O_PROTOCOL flag should have an impact only if no driver is
specified explicitly. Therefore, if bdrv_open() is called with an
explicit block driver argument (either through the options QDict or
through the drv parameter) and that block driver is a protocol block
driver, BDRV_O_PROTOCOL shou
From: Marcel Apfelbaum
Refactoring it as a method of PCIBusClass will allow
different implementations for subclasses.
Removed the assumption that the root bus does not
have a parent device because is specific only
to the default class implementation.
Signed-off-by: Marcel Apfelbaum
---
hw/pci
Add encoding for ACPI DefOr Opcode.
Reviewed-by: Shannon Zhao
Reviewed-by: Igor Mammedov
Signed-off-by: Marcel Apfelbaum
---
hw/acpi/aml-build.c | 10 ++
include/hw/acpi/aml-build.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.
1 - 100 of 294 matches
Mail list logo
