ys(kernel_filename, KERNEL_LOAD_ADDR,
KERNEL_MAX_SIZE);
Hi,
The patch looks good to me.
Reviewed-by: Marcel Apfelbaum
Thanks,
Marcel
On 03/30/2017 07:34 PM, Suramya Shah wrote:
Hi,
Much better now, only a nit..
Running QEMU with qemu-system-unicore32 without the kernel parameter results in
an assertion error.Assert should not be used to check user provided parameters.
Report an error and exit instead
You should break the
On 03/30/2017 07:17 PM, Suramya Shah wrote:
Signed-off-by: Suramya Shah
Hi,
Running QEMU with qemu-system-unicore32 without the kernel parameter results in
an assertion error.
Assert should not be used to check user provided parameters. Report an error
and exit instead
Put the "Signed-
On 03/30/2017 06:44 PM, Suramya Shah wrote:
Hi,
Signed-off-by: Suramya Shah
Please add the SOB after the description.
Reviewed-by: Marcel Apfelbaum
Please do not add a reviewer to your patch
unless he approved /added his signature by himself.
Running QEMU with qemu-system-unicore32
On 03/30/2017 05:57 PM, Suramya Shah wrote:
Signed-off-by: Suramya Shah
Hi,
Thank you for contributing to QEMU project.
I suggest to avoid details in the subject, use something like:
"hw/unicore32: remove wrong assertion in puv machine init"
---
Running QEMU with qemu-system-unicore32 w
driver in order to support peers on external hosts.
- Re-use the code for a virtio based device.
Any ideas, comments or suggestions would be highly appreciated.
Thanks,
Yuval Shaia & Marcel Apfelbaum
Signed-off-by: Yuval Shaia
(Mainly design, coding was done by Yuval)
Signed-off-by: Marcel
_CPU(first_cpu);
-
-lma = !!(first_x86_cpu->env.hflags & HF_LMA_MASK);
+lma = first_cpu && (first_x86_cpu->env.hflags & HF_LMA_MASK);
#endif
if (lma) {
Reviewed-by: Marcel Apfelbaum
Thanks,
Marcel
lma = !!(first_x86_cpu->env.hflags & HF_LMA_MASK);
Please run: ./scripts/checkpatch.pl on the patch before you
submit to ensure coding style.
You will see that we always use if { }; the patch has "DOS line endings".
You are welcome to submit the patch again.
In the
"bus master container", UINT64_MAX);
@@ -1005,7 +1006,6 @@ static PCIDevice *do_pci_register_device(PCIDevice
*pci_dev, PCIBus *bus,
if (qdev_hotplug) {
pci_init_bus_master(pci_dev);
}
-pstrcpy(pci_dev->name, sizeof(pci_dev->name), name);
pci_dev->i
On 03/23/2017 05:43 PM, Thomas Huth wrote:
On 22.03.2017 20:13, Eduardo Habkost wrote:
On Wed, Mar 22, 2017 at 01:00:49PM -0300, Eduardo Habkost wrote:
This series adds scripts/device-crashtest.py, that can be used to
crash-test -device with multiple machine/accel/device
combinations.
The scri
On 03/22/2017 10:46 PM, Laszlo Ersek wrote:
On 03/22/17 21:31, Eduardo Habkost wrote:
Hi,
I am investigating the current status of has_dynamic_sysbus and
sysbus device support on each of QEMU's machine types. The good
news is that almost all has_dynamic_sysbus=1 machines have their
own internal
On 03/20/2017 05:43 PM, Michael S. Tsirkin wrote:
On Mon, Mar 20, 2017 at 05:21:22PM +0200, Marcel Apfelbaum wrote:
On 03/17/2017 11:57 PM, James Hogan wrote:
Hi,
I've bisected the following failure of the virtio_net linux v4.10 driver
to probe in QEMU v2.9.0-rc1 emulating a MIPS
On 03/20/2017 05:43 PM, Michael S. Tsirkin wrote:
On Mon, Mar 20, 2017 at 05:21:22PM +0200, Marcel Apfelbaum wrote:
On 03/17/2017 11:57 PM, James Hogan wrote:
Hi,
I've bisected the following failure of the virtio_net linux v4.10 driver
to probe in QEMU v2.9.0-rc1 emulating a MIPS
On 03/17/2017 11:57 PM, James Hogan wrote:
Hi,
I've bisected the following failure of the virtio_net linux v4.10 driver
to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine:
virtio_net virtio0: virtio: device uses modern interface but does not have
VIRTIO_F_VERSION_1
virtio_net: probe of
On 03/02/2017 08:25 AM, Marcel Apfelbaum wrote:
On 02/20/2017 10:43 PM, Marcel Apfelbaum wrote:
v1 -> v2:
- Added compat properties (Michael S. Tsirkin)
- Rebased on latest master
- Regarding the patch 1/4, we don't need to init the PCI "standard"
config capabiliti
On 03/13/2017 11:52 AM, Paolo Bonzini wrote:
On 13/03/2017 10:38, Marcel Apfelbaum wrote:
On 03/13/2017 05:29 AM, Jason Wang wrote:
96a8821d2141 ("virtio: unbreak virtio-pci with IOMMU after caching ring
translations") tries to make IOMMU works with virtio memory region
cac
On 03/13/2017 05:29 AM, Jason Wang wrote:
96a8821d2141 ("virtio: unbreak virtio-pci with IOMMU after caching ring
translations") tries to make IOMMU works with virtio memory region
cache, but it requires IOMMU to be created before any virtio
devices. This is sub optimal, fixing this by introduce
On 03/09/2017 01:13 PM, Paolo Bonzini wrote:
On 09/03/2017 00:59, Michael S. Tsirkin wrote:
Allow forcing a specific order of initialization on
devices created with -device.
Helpful e.g. for built-in devices such as IOMMUs which must
exist before all other devices.
Signed-off-by: Michael S. T
On 03/08/2017 12:08 PM, Jason Wang wrote:
On 2017年03月08日 16:35, Paolo Bonzini wrote:
- Original Message -
From: "Marcel Apfelbaum"
To: "Michael S. Tsirkin" , "Peter Xu"
Cc: qemu-devel@nongnu.org, "Paolo Bonzini" , "yi l liu"
On 03/08/2017 11:16 AM, Peter Xu wrote:
On Wed, Mar 08, 2017 at 05:09:45PM +0800, Peter Xu wrote:
On Wed, Mar 08, 2017 at 10:17:09AM +0200, Marcel Apfelbaum wrote:
[...]
I am sorry I was not clear enough:
If a device is added after the system is up (hotplug), we cannot depend on the
On 03/08/2017 04:43 AM, Peter Xu wrote:
On Tue, Mar 07, 2017 at 02:47:30PM +0200, Marcel Apfelbaum wrote:
On 03/07/2017 11:09 AM, Jason Wang wrote:
After commit 96a8821d2141 ("virtio: unbreak virtio-pci with IOMMU
after caching ring translations"), IOMMU was required to be created
On 03/08/2017 05:15 AM, Jason Wang wrote:
On 2017年03月08日 10:43, Peter Xu wrote:
On Tue, Mar 07, 2017 at 02:47:30PM +0200, Marcel Apfelbaum wrote:
On 03/07/2017 11:09 AM, Jason Wang wrote:
After commit 96a8821d2141 ("virtio: unbreak virtio-pci with IOMMU
after caching ring transla
On 03/07/2017 11:09 AM, Jason Wang wrote:
After commit 96a8821d2141 ("virtio: unbreak virtio-pci with IOMMU
after caching ring translations"), IOMMU was required to be created in
advance. This is because we can only get the correct dma_as after pci
IOMMU (e.g intel_iommu) was initialized. This is
On 03/02/2017 07:13 AM, Michael S. Tsirkin wrote:
On Thu, Mar 02, 2017 at 11:32:18AM +0800, Peter Xu wrote:
Intel vIOMMU devices are created with "-device" parameter, while here
actually we need to make sure the dmar device be created before other
PCI devices (like vfio-pci, virtio-pci ones) so
On 02/20/2017 10:43 PM, Marcel Apfelbaum wrote:
v1 -> v2:
- Added compat properties (Michael S. Tsirkin)
- Rebased on latest master
- Regarding the patch 1/4, we don't need to init the PCI "standard"
config capabilities to 0 since they are "protected" b
On 03/01/2017 11:59 AM, Peter Xu wrote:
On Wed, Mar 01, 2017 at 11:29:47AM +0200, Marcel Apfelbaum wrote:
On 03/01/2017 11:18 AM, Peter Xu wrote:
On Wed, Mar 01, 2017 at 09:03:47AM +0200, Marcel Apfelbaum wrote:
On 03/01/2017 06:14 AM, Jason Wang wrote:
[...]
Hi Jason,
I am not saying we
On 03/01/2017 11:18 AM, Peter Xu wrote:
On Wed, Mar 01, 2017 at 09:03:47AM +0200, Marcel Apfelbaum wrote:
On 03/01/2017 06:14 AM, Jason Wang wrote:
[...]
Hi Jason,
I am not saying we don't need to create the IOMMU before some other device,
I just don't think that the command
On 03/01/2017 10:43 AM, Jason Wang wrote:
On 2017年03月01日 15:03, Marcel Apfelbaum wrote:
On 03/01/2017 06:14 AM, Jason Wang wrote:
On 2017年03月01日 11:23, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2017 at 10:36:35AM +0800, Peter Xu wrote:
On Tue, Feb 28, 2017 at 04:42:25PM +0200, Marcel
On 03/01/2017 06:14 AM, Jason Wang wrote:
On 2017年03月01日 11:23, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2017 at 10:36:35AM +0800, Peter Xu wrote:
On Tue, Feb 28, 2017 at 04:42:25PM +0200, Marcel Apfelbaum wrote:
On 02/24/2017 06:29 AM, Peter Xu wrote:
Intel vIOMMU devices are created
On 02/23/2017 05:35 PM, Alex Williamson wrote:
On Thu, 23 Feb 2017 14:02:07 +0200
Marcel Apfelbaum wrote:
On 02/23/2017 10:16 AM, Peter Xu wrote:
On Thu, Feb 23, 2017 at 10:10:57AM +0200, Marcel Apfelbaum wrote:
On 02/23/2017 05:06 AM, Peter Xu wrote:
On Wed, Feb 22, 2017 at 10:30:47AM
On 02/24/2017 06:29 AM, Peter Xu wrote:
Intel vIOMMU devices are created with "-device" parameter, while here
actually we need to make sure the dmar device be created before other
PCI devices (like vfio-pci) so that we know iommu_fn will be setup
correctly before realizations of those PCI devices
negotiate control of the features described in the Control Field in
the same way for all host bridges.
Reviewed-by: Igor Mammedov
Signed-off-by: Marcel Apfelbaum
---
dtc | 2 +-
hw/i386/acpi-build.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/dtc
From: "Michael S. Tsirkin"
Our _OSC method has a bunch of unused code loading data
into external CTRL and SUPP fields which are then never
used. Drop this in favor of a single local variable.
Signed-off-by: Michael S. Tsirkin
---
hw/i386/acpi-build.c | 5 +
1 file changed, 1 insertion(+),
them that way,
maybe is some kind of documentation contract.
Add the missing osc method for pxb-pcie devices as APCI spec recommends
Thanks,
Marcel
Marcel Apfelbaum (1):
hw/pxb-pcie: fix PCI Express hotplug support
Michael S. Tsirkin (1):
acpi: simplify _OSC
dtc | 2 +-
machine_init(MachineClass *mc)
Reviewed-by: Marcel Apfelbaum
Thanks,
Marcel
On 02/27/2017 10:57 PM, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2017 at 03:12:26PM +0200, Marcel Apfelbaum wrote:
Add the missing osc method for pxb-pcie devices as APCI spec recommends,
see 6.2.10.3 OSC Implementation Example for PCI Host Bridge Devices, ACPI 5.0:
It is recommended that
On 02/27/2017 01:43 PM, Thomas Huth wrote:
On 25.01.2017 09:40, Thomas Huth wrote:
We can have basic support for the "-kernel" parameter quite easily
by using the generic loader device. This should be enough for most
boards which do not need special machine-specific magic for loading
a kernel (a
negotiate control of the features described in the Control Field in
the same way for all host bridges.
Reviewed-by: Igor Mammedov
Signed-off-by: Marcel Apfelbaum
---
Note to maintainer:
Please update ACPI test files.
V2 -> V3:
- Modified comment (Igor)
V1 -> V2:
Add
negotiate control of the features described in the Control Field in
the same way for all host bridges.
Signed-off-by: Marcel Apfelbaum
---
Note to maintainer:
Please update ACPI test files.
V1 -> V2:
Addressed Michael S. Tsirkin's comments:
- Added documentation to
On 02/23/2017 10:16 AM, Peter Xu wrote:
On Thu, Feb 23, 2017 at 10:10:57AM +0200, Marcel Apfelbaum wrote:
On 02/23/2017 05:06 AM, Peter Xu wrote:
On Wed, Feb 22, 2017 at 10:30:47AM -0700, Alex Williamson wrote:
On Wed, 22 Feb 2017 13:49:25 +0800
Peter Xu wrote:
Intel vIOMMU devices are
On 02/23/2017 05:06 AM, Peter Xu wrote:
On Wed, Feb 22, 2017 at 10:30:47AM -0700, Alex Williamson wrote:
On Wed, 22 Feb 2017 13:49:25 +0800
Peter Xu wrote:
Intel vIOMMU devices are created with "-device" parameter, while here
actually we need to make sure this device will be created before so
Make Power Management State flag writable to conform
with the PCI Express spec.
Signed-off-by: Marcel Apfelbaum
---
hw/virtio/virtio-pci.c | 11 +++
hw/virtio/virtio-pci.h | 4
include/hw/compat.h| 4
include/hw/pci/pcie.h | 2 ++
4 files changed, 21 insertions
When the virtio devices are PCI Express, make error-enabling flags
writable to respect the PCIe spec.
Signed-off-by: Marcel Apfelbaum
---
hw/virtio/virtio-pci.c | 12
hw/virtio/virtio-pci.h | 4
include/hw/compat.h| 4
3 files changed, 20 insertions(+)
diff --git a
Make several Link Control Register flags writable to conform
with the PCI Express spec.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pcie.c | 14 ++
hw/virtio/virtio-pci.c | 8
hw/virtio/virtio-pci.h | 4
include/hw/compat.h| 4
include/hw/pci/pcie.h
figuration Space as read-only to achieve the same
behaviour.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pci.c | 2 ++
hw/pci/pcie.c| 6 ++
include/hw/compat.h | 4
include/hw/pci/pci.h | 2 ++
4 files changed, 14 insertions(+)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
ind
t be 3h after a supported D3 transition.
Thanks,
Marcel
Marcel Apfelbaum (4):
hw/pcie: fix Extended Configuration Space for devices with no Extended
Capabilities
hw/virtio: fix error enabling flags in Device Control register
hw/virtio: fix Link Control Register for PCI Express virtio de
On 02/16/2017 05:28 AM, David Gibson wrote:
On Thu, Feb 16, 2017 at 01:48:42PM +1100, David Gibson wrote:
On Wed, Feb 15, 2017 at 04:59:33PM +0200, Marcel Apfelbaum wrote:
On 02/15/2017 03:45 AM, David Gibson wrote:
On Tue, Feb 14, 2017 at 02:53:08PM +0200, Marcel Apfelbaum wrote:
On 02/14
On 02/16/2017 04:48 AM, David Gibson wrote:
On Wed, Feb 15, 2017 at 04:59:33PM +0200, Marcel Apfelbaum wrote:
[...]
I did float the idea of having the pseries PCI bus remain plain PCI
but with a special flag to allow PCIe devices to be attached to it
anyway. It wasn't greeted with
On 02/16/2017 01:19 PM, Marc-André Lureau wrote:
Hi
- Original Message -
On 02/16/2017 12:58 PM, Marc-André Lureau wrote:
This will allow the function to be used outside of QOM properties.
Hi Mark-Andre,
I am not sure cutil.h is the right header for the function, because is too
PCI
On 02/16/2017 12:58 PM, Marc-André Lureau wrote:
This will allow the function to be used outside of QOM properties.
Hi Mark-Andre,
I am not sure cutil.h is the right header for the function, because is too PCI
related for a utility library.
Also, maybe we can post the patch together with the
On 02/15/2017 03:45 AM, David Gibson wrote:
On Tue, Feb 14, 2017 at 02:53:08PM +0200, Marcel Apfelbaum wrote:
On 02/14/2017 06:15 AM, David Gibson wrote:
On Mon, Feb 13, 2017 at 12:14:23PM +0200, Marcel Apfelbaum wrote:
On 02/13/2017 06:33 AM, David Gibson wrote:
On Sun, Feb 12, 2017 at 09
On 02/14/2017 09:51 AM, Peter Xu wrote:
When we add PCIe extended capabilities, we should be following the rule
that we add the head extended cap (at offset 0x100) first, then the rest
of them. Meanwhile, we are always adding new capability bits at the end
of the list. Here the "next" looks meani
On 02/14/2017 06:15 AM, David Gibson wrote:
On Mon, Feb 13, 2017 at 12:14:23PM +0200, Marcel Apfelbaum wrote:
On 02/13/2017 06:33 AM, David Gibson wrote:
On Sun, Feb 12, 2017 at 09:05:46PM +0200, Marcel Apfelbaum wrote:
On 02/10/2017 02:37 AM, David Gibson wrote:
On Thu, Feb 09, 2017 at 10
_DEVICE_ID_REDHAT_PCIE_RP 0x000c
+#define PCI_DEVICE_ID_REDHAT_XHCI0x000d
#define PCI_DEVICE_ID_REDHAT_QXL 0x0100
#define FMT_PCIBUS PRIx64
Reviewed-by: Marcel Apfelbaum
Thanks,
Marcel
On 02/13/2017 06:33 AM, David Gibson wrote:
On Sun, Feb 12, 2017 at 09:05:46PM +0200, Marcel Apfelbaum wrote:
On 02/10/2017 02:37 AM, David Gibson wrote:
On Thu, Feb 09, 2017 at 10:04:47AM +0100, Laszlo Ersek wrote:
On 02/09/17 05:16, David Gibson wrote:
On Wed, Feb 08, 2017 at 11:40:50AM
On 02/06/2017 06:31 PM, Michael S. Tsirkin wrote:
On Sun, Feb 05, 2017 at 01:12:03AM -0800, b...@skyportsystems.com wrote:
From: Ben Warren
This allows pc_i440fx-based machines to add new devices such as
VM Generation ID directly to the sysbus.
Signed-off-by: Ben Warren
Hi,
Only point
On 02/10/2017 02:37 AM, David Gibson wrote:
On Thu, Feb 09, 2017 at 10:04:47AM +0100, Laszlo Ersek wrote:
On 02/09/17 05:16, David Gibson wrote:
On Wed, Feb 08, 2017 at 11:40:50AM +0100, Laszlo Ersek wrote:
On 02/08/17 07:16, David Gibson wrote:
Marcel,
Your original patch adding PCIe suppor
uest's serial console and the QEMU monitor
+# to the host's stdio; use 'Ctrl+A h' to learn how to
+# switch between the two and more.
+
+
+# Machine options
+# =
+#
+# We use the q35 machine type and enable KVM acceleration
+# for better performance.
+#
+# Using less than 1 GiB of memory is probably not going to
+# yield good performance in the guest, and might even lead
+# to obscure boot issues in some cases.
+
+[machine]
+ type = "q35"
+ accel = "kvm"
+
+[memory]
+ size = "1024"
+
+
+# PCI bridge (PCI Express Root Ports)
+# =
+#
+# We create eight PCI Express Root Ports, and we plug them
+# all into separate functions of the same slot. Some of
+# them will be used by devices, the rest will remain
+# available for hotplug.
+
+[device "pcie.1"]
+ driver = "pcie-root-port"
+ bus = "pcie.0"
+ addr = "1c.0"
+ port = "1"
+ chassis = "1"
+ multifunction = "on"
+
+[device "pcie.2"]
+ driver = "pcie-root-port"
+ bus = "pcie.0"
+ addr = "1c.1"
+ port = "2"
+ chassis = "2"
+
+[device "pcie.3"]
+ driver = "pcie-root-port"
+ bus = "pcie.0"
+ addr = "1c.2"
+ port = "3"
+ chassis = "3"
+
+[device "pcie.4"]
+ driver = "pcie-root-port"
+ bus = "pcie.0"
+ addr = "1c.3"
+ port = "4"
+ chassis = "4"
+
+[device "pcie.5"]
+ driver = "pcie-root-port"
+ bus = "pcie.0"
+ addr = "1c.4"
+ port = "5"
+ chassis = "5"
+
+[device "pcie.6"]
+ driver = "pcie-root-port"
+ bus = "pcie.0"
+ addr = "1c.5"
+ port = "6"
+ chassis = "6"
+
+[device "pcie.7"]
+ driver = "pcie-root-port"
+ bus = "pcie.0"
+ addr = "1c.6"
+ port = "7"
+ chassis = "7"
+
+[device "pcie.8"]
+ driver = "pcie-root-port"
+ bus = "pcie.0"
+ addr = "1c.7"
+ port = "8"
+ chassis = "8"
+
+
+# SCSI storage controller (and storage)
+# =
+#
+# We use virtio-scsi here so that we can (hot)plug a large
+# number of disks without running into issues; a SCSI disk,
+# backed by a qcow2 disk image on the host's filesystem, is
+# attached to it.
+#
+# We also create an optical disk, mostly for installation
+# purposes: once the guest OS has been succesfully
+# installed, the guest will no longer boot from optical
+# media. If you don't want, or no longer want, to have an
+# optical disk in the guest you can safely comment out
+# all relevant sections below.
+
+[device "scsi"]
+ driver = "virtio-scsi-pci"
+ bus = "pcie.1"
+ addr = "00.0"
+
+[device "scsi-disk"]
+ driver = "scsi-hd"
+ bus = "scsi.0"
+ drive = "disk"
+ bootindex = "1"
+
+[drive "disk"]
+ file = "guest.qcow2" # CHANGE ME
+ format = "qcow2"
+ if = "none"
+
+[device "scsi-optical-disk"]
+ driver = "scsi-cd"
+ bus = "scsi.0"
+ drive = "optical-disk"
+ bootindex = "2"
+
+[drive "optical-disk"]
+ file = "install.iso" # CHANGE ME
+ format = "raw"
+ if = "none"
+
+
+# Ethernet controller
+# =
+#
+# We use virtio-net for improved performance over emulated
+# hardware; on the host side, we take advantage of user
+# networking so that the QEMU process doesn't require any
+# additional privileges.
+
+[netdev "hostnet"]
+ type = "user"
+
+[device "net"]
+ driver = "virtio-net-pci"
+ netdev = "hostnet"
+ bus = "pcie.2"
+ addr = "00.0"
Hi Andrea,
Your work is much appreciated.
Reviewed-by: Marcel Apfelbaum
Thanks,
Marcel
On 02/03/2017 12:34 AM, Michael S. Tsirkin wrote:
On Fri, Feb 03, 2017 at 12:05:52AM +0200, Marcel Apfelbaum wrote:
Add the missing osc method for pxb-pcie devices
Signed-off-by: Marcel Apfelbaum
---
Note: The patch is based on the fact that Q35's osc method is quite generic.
Thanks,
M
On 02/03/2017 12:13 AM, Gerd Hoffmann wrote:
On Do, 2017-02-02 at 16:20 +0100, Andrea Bolognani wrote:
On Thu, 2017-02-02 at 16:42 +0200, Marcel Apfelbaum wrote:
[...]
I personally don't use them because every time I try, I
find something with no config support
Is that so? Ca
Add the missing osc method for pxb-pcie devices
Signed-off-by: Marcel Apfelbaum
---
Note: The patch is based on the fact that Q35's osc method is quite generic.
Thanks,
Marcel
hw/i386/acpi-build.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/i386/acpi-build.c b/hw/i386
On 02/02/2017 05:20 PM, Andrea Bolognani wrote:
On Thu, 2017-02-02 at 16:42 +0200, Marcel Apfelbaum wrote:
[...]
+[device "ich9-pcie-port-1"]
I would use the new generic root port.
This sample configuration (q35-emulated.cfg) is supposed to
match physical hardware as closely as po
On 02/01/2017 07:20 PM, Andrea Bolognani wrote:
Instead of having a single sample configuration file,
we now have several:
* q35-emulated.cfg documents the default devices QEMU
adds to a q35 guest and the additional devices that
are pretty much guaranteed to be present in a
physica
On 01/10/2017 05:13 AM, Michael S. Tsirkin wrote:
On Wed, Jan 04, 2017 at 09:57:15PM +0200, Marcel Apfelbaum wrote:
Absence of any Extended Capabilities is required to be
indicated by an Extended Capability header with a Capability ID of
h, a Capability Version of 0h, and a Next Capability
On 01/10/2017 05:07 AM, Michael S. Tsirkin wrote:
On Wed, Jan 04, 2017 at 09:57:16PM +0200, Marcel Apfelbaum wrote:
When the virtio devices are PCI Express, make error-enabling flags
writable to respect the PCIe spec.
Signed-off-by: Marcel Apfelbaum
If guest writes there, it won't be
On 01/25/2017 09:15 PM, Michael S. Tsirkin wrote:
On Wed, Jan 25, 2017 at 09:03:55PM +0200, Marcel Apfelbaum wrote:
v3 -> v4:
- Rebased on master.
No need for this. Pls check that my pci branch is ok.
I see hw/pci-bridge/gen_pcie_root_port.c still uses the macro
VMSTATE_PCIE_DEV
Preserve only Intel specific details.
Tested-by: Andrea Bolognani
Signed-off-by: Marcel Apfelbaum
---
hw/pci-bridge/ioh3420.c | 121 ++--
1 file changed, 15 insertions(+), 106 deletions(-)
diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420
ities)
- something that obviously cannot be done
on a known device.
Tested-by: Andrea Bolognani
Signed-off-by: Marcel Apfelbaum
---
hw/pci-bridge/Makefile.objs| 2 +-
hw/pci-bridge/gen_pcie_root_port.c | 88 ++
include/hw/pci/
The 'base' PCI Express Root Port includes
the common code to be re-used for all
Root Ports implementations. Most of the code
was taken from the current implementation
of Intel's IOH 3420 Root Port.
Tested-by: Andrea Bolognani
Signed-off-by: Marcel Apfelbaum
---
default-configs/
3: Derives the IOH3420 from the new base class
Patch 3/3: Introduces the generic Root Port.
Tested with Linux and Windows guests only on x86 hosts.
Marcel Apfelbaum (3):
hw/pcie: Introduce a base class for PCI Express Root Ports
hw/ioh3420: derive from PCI Express Root Port base class
hw/pcie: Int
On 01/25/2017 08:08 PM, Peter Maydell wrote:
On 25 January 2017 at 18:02, Marcel Apfelbaum
wrote:
Strange, I re-based in the same day I posted and compiled just fine...
However, I get the same error using today's master.
I'll fix and re-post the series.
mst has done a rebase o
On 01/25/2017 06:36 PM, Peter Maydell wrote:
On 24 January 2017 at 22:36, Michael S. Tsirkin wrote:
The following changes since commit a9e404600a9bd1e6a26431fc89e5069092e67f14:
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20170124' into
staging (2017-01-24 17:26:26 +)
are av
On 01/24/2017 06:30 PM, Michael S. Tsirkin wrote:
On Tue, Jan 24, 2017 at 06:23:49PM +0200, Marcel Apfelbaum wrote:
On 01/11/2017 01:46 PM, Marcel Apfelbaum wrote:
The shpc component is optional while ACPI hotplug is used
for hot-plugging PCI devices into a PCI-PCI bridge.
Disabling the shpc
reasons.
Signed-off-by: Marcel Apfelbaum
---
v2 -> v3:
- Rebased on master (Michael)
v1 -> v2:
- Moved the compat property to HW_COMPAT_2_8
hw/pci-bridge/pci_bridge_dev.c | 2 +-
include/hw/compat.h| 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/pci-
On 01/11/2017 01:46 PM, Marcel Apfelbaum wrote:
The shpc component is optional while ACPI hotplug is used
for hot-plugging PCI devices into a PCI-PCI bridge.
Disabling the shpc by default will make slot 0 usable at boot time
and not only for hot-plug, without loosing any functionality.
Older
On 01/24/2017 05:52 PM, Andrea Bolognani wrote:
On Mon, 2017-01-23 at 21:20 +0200, Marcel Apfelbaum wrote:
v2 -> v3:
- Keep only the root port base class code in pcie_root_port.c (Michael)
- Use msix for the generic root port implementation (Michael and Gerd)
- The task required s
Preserve only Intel specific details.
Signed-off-by: Marcel Apfelbaum
---
hw/pci-bridge/ioh3420.c | 121 ++--
1 file changed, 15 insertions(+), 106 deletions(-)
diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
index 84b7946..571ffe5
ities)
- something that obviously cannot be done
on a known device.
Signed-off-by: Marcel Apfelbaum
---
hw/pci-bridge/Makefile.objs| 2 +-
hw/pci-bridge/gen_pcie_root_port.c | 88 ++
include/hw/pci/pci.h | 1 +
3 files change
The 'base' PCI Express Root Port includes
the common code to be re-used for all
Root Ports implementations. Most of the code
was taken from the current implementation
of Intel's IOH 3420 Root Port.
Signed-off-by: Marcel Apfelbaum
---
default-configs/arm-softmmu.mak| 1 +
ass
Patch 3/3: Introduces the generic Root Port.
Tested with Linux and Windows guests only on x86 hosts.
Marcel Apfelbaum (3):
hw/pcie: Introduce a base class for PCI Express Root Ports
hw/ioh3420: derive from PCI Express Root Port base class
hw/pcie: Introduce Generic PCI Express Root Por
r_ram(&pdev->rom, &pdev->qdev);
ptr = memory_region_get_ram_ptr(&pdev->rom);
load_image(path, ptr);
Reviewed-by: Marcel Apfelbaum
Thanks,
Marcel
NERS
+++ b/MAINTAINERS
@@ -813,6 +813,7 @@ M: Eduardo Habkost
M: Marcel Apfelbaum
S: Supported
F: hw/core/machine.c
+F: hw/core/null-machine.c
F: include/hw/boards.h
Xtensa Machines
Reviewed-by: Marcel Apfelbaum
Thanks,
Marcel
On 01/16/2017 06:46 PM, Andrea Bolognani wrote:
On Wed, 2017-01-11 at 14:18 +0200, Marcel Apfelbaum wrote:
v1 -> v2:
- Rebased on master.
The Generic Root Port behaves the same as the
Intel's IOH device with id 3420, without having
Intel specific attributes.
The device has two
On 01/12/2017 07:53 PM, Laine Stump wrote:
On 01/12/2017 11:35 AM, Michael Roth wrote:
Quoting Laine Stump (2017-01-12 08:52:10)
[...]
Yeah you're right, I'm probably remembering the wrong problem and wrong reason
for the problem. I just remember there was *some* issue about hotplugging n
On 01/13/2017 10:35 AM, Gerd Hoffmann wrote:
Hi,
Sure, thanks for the pointers!
I suppose I can change later to msi-x in a follow up patch
to avoid introducing new bugs from the beginning :)
I'd use msi-x right from start to avoid any backward compatibility
issues.
Hi Gerd, Michael
I'll
On 01/12/2017 06:20 PM, Michael S. Tsirkin wrote:
On Thu, Jan 12, 2017 at 06:05:20PM +0200, Marcel Apfelbaum wrote:
On 01/12/2017 05:56 PM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2017 at 02:18:53PM +0200, Marcel Apfelbaum wrote:
v1 -> v2:
- Rebased on master.
The Generic Root P
On 01/12/2017 05:56 PM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2017 at 02:18:53PM +0200, Marcel Apfelbaum wrote:
v1 -> v2:
- Rebased on master.
The Generic Root Port behaves the same as the
Intel's IOH device with id 3420, without having
Intel specific attributes.
The device
On 01/12/2017 05:36 PM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2017 at 02:18:54PM +0200, Marcel Apfelbaum wrote:
The 'base' PCI Express Root Port includes
the common code to be re-used for all
Root Ports implementations. Most of the code
was taken from the current implementation
The 'base' PCI Express Root Port includes
the common code to be re-used for all
Root Ports implementations. Most of the code
was taken from the current implementation
of Intel's IOH 3420 Root Port.
Signed-off-by: Marcel Apfelbaum
---
default-configs/arm-softmmu.mak| 1 +
ities)
- something that obviously cannot be done
on a known device.
Signed-off-by: Marcel Apfelbaum
---
hw/pci-bridge/pcie_root_port.c | 34 ++
include/hw/pci/pci.h | 1 +
2 files changed, 35 insertions(+)
diff --git a/hw/pci-bridge/pcie_root_port.c
Preserve only Intel specific details.
Signed-off-by: Marcel Apfelbaum
---
hw/pci-bridge/ioh3420.c | 152 +++-
1 file changed, 7 insertions(+), 145 deletions(-)
diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
index 84b7946..431266c
uces the generic Root Port.
Tested with Linux and Windows guests only on x86 hosts.
Marcel Apfelbaum (3):
hw/pcie: Introduce a base class for PCI Express Root Ports
hw/ioh3420: derive from PCI Express Root Port base class
hw/pcie: Introduce Generic PCI Express Root Port
default-con
reasons.
Signed-off-by: Marcel Apfelbaum
---
v1 -> v2:
- Moved the compat property to HW_COMPAT_2_8
hw/pci-bridge/pci_bridge_dev.c | 2 +-
include/hw/compat.h| 6 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bri
On 01/06/2017 09:41 PM, Michael S. Tsirkin wrote:
On Fri, Jan 06, 2017 at 08:13:11AM +0200, Marcel Apfelbaum wrote:
On 01/06/2017 07:04 AM, David Gibson wrote:
The PCI Expander Bridge (PXB) device is essentially a hack to allow
different PCIe devices to be assigned to different NUMA nodes on
On 01/06/2017 08:13 AM, Marcel Apfelbaum wrote:
On 01/06/2017 07:04 AM, David Gibson wrote:
The PCI Expander Bridge (PXB) device is essentially a hack to allow
different PCIe devices to be assigned to different NUMA nodes on x86. Each
PXB is sort-of a separate PCI host bridge, except that its
s sense
Reviewed-by: Marcel Apfelbaum
Thanks,
Marcel
Signed-off-by: David Gibson
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/pci-bridge/Makefile.objs| 2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/default-configs/i386-s
Make several Link Control Register flags writable to conform
with the PCI Express spec.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pcie.c | 14 ++
hw/virtio/virtio-pci.c | 3 +++
include/hw/pci/pcie.h | 3 +++
3 files changed, 20 insertions(+)
diff --git a/hw/pci/pcie.c
When the virtio devices are PCI Express, make error-enabling flags
writable to respect the PCIe spec.
Signed-off-by: Marcel Apfelbaum
---
hw/virtio/virtio-pci.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 21c2b9d..da2124f
Make Power Management State flag writable to conform
with the PCI Express spec.
Signed-off-by: Marcel Apfelbaum
---
hw/virtio/virtio-pci.c | 5 +
include/hw/pci/pcie.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 66a5bf3
figuration Space as read-only to achieve the same
behaviour.
Signed-off-by: Marcel Apfelbaum
---
hw/pci/pcie.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 99cfb45..62c1def 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -109,6 +109,9 @@ int pci
901 - 1000 of 2768 matches
Mail list logo
