Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 31 May 2018 23:30:35 -0600 "Jan Beulich" wrote: >>>> Alexey G 05/31/18 7:15 AM >>> >>On Wed, 30 May 2018 02:12:37 -0600 "Jan Beulich" wrote: >>>>>> On 29.05.18 at 20:47, wrote: >>>> On Wed, 30 May 20

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 30 May 2018 02:12:37 -0600 "Jan Beulich" wrote: >>>> On 29.05.18 at 20:47, wrote: >> On Wed, 30 May 2018 03:56:07 +1000 >> Alexey G wrote: >>>On Tue, 29 May 2018 08:23:51 -0600 >>>"Jan Beulich" wrote: >>>&g

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 30 May 2018 02:13:30 -0600 "Jan Beulich" wrote: >>>> On 30.05.18 at 06:32, wrote: >>> On Wed, 30 May 2018 03:56:07 +1000 >>>Alexey G wrote: >>> >>>>On Tue, 29 May 2018 08:23:51 -0600 >>>

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

>On Wed, 30 May 2018 03:56:07 +1000 >Alexey G wrote: > >>On Tue, 29 May 2018 08:23:51 -0600 >>"Jan Beulich" wrote: >> >>>>>> On 12.03.18 at 19:33, wrote: >>>> --- a/tools/firmware/hvmloader/config.h >>>>

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 30 May 2018 03:56:07 +1000 Alexey G wrote: >On Tue, 29 May 2018 08:23:51 -0600 >"Jan Beulich" wrote: > >>>>> On 12.03.18 at 19:33, wrote: >>> --- a/tools/firmware/hvmloader/config.h >>> +++ b/tools/firmware/hvmloader/config.h &

Re: [Xen-devel] [RFC PATCH 10/12] libacpi: build ACPI MCFG table if requested

On Tue, 29 May 2018 08:36:49 -0600 "Jan Beulich" wrote: On 12.03.18 at 19:33, wrote: >> --- a/tools/libacpi/acpi2_0.h >> +++ b/tools/libacpi/acpi2_0.h >> @@ -422,6 +422,25 @@ struct acpi_20_slit { >> }; >> >> /* >> + * PCI Express Memory Mapped Configuration Description Table >> + */

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Tue, 29 May 2018 08:23:51 -0600 "Jan Beulich" wrote: On 12.03.18 at 19:33, wrote: >> --- a/tools/firmware/hvmloader/config.h >> +++ b/tools/firmware/hvmloader/config.h >> @@ -53,10 +53,14 @@ extern uint8_t ioapic_version; >> #define PCI_ISA_DEVFN 0x08/* dev 1, fn 0 */ >>

Re: [Xen-devel] [RFC PATCH 11/12] hvmloader: use libacpi to build MCFG table

On Tue, 29 May 2018 08:46:13 -0600 "Jan Beulich" wrote: On 12.03.18 at 19:33, wrote: >> --- a/tools/firmware/hvmloader/util.c >> +++ b/tools/firmware/hvmloader/util.c >> @@ -782,6 +782,69 @@ int get_pc_machine_type(void) >> return machine_type; >> } >> >> +#define

Re: [Xen-devel] Community call: PCI Emulation - Future Direction (Wed, May 2nd, UTC 16:00-17:00 / BST 17:00-18:00) - Minutes

On Fri, 4 May 2018 15:38:49 + Lars Kurth wrote: [...] >Julien: where would the reset code live then? >Christopher: would want to avoid Dom0 having access to the config space. The >VM hosting >the toolstack will need to exercise control over access to the config space.

Re: [Xen-devel] [PATCH for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

On Thu, 3 May 2018 15:02:36 +0100 Roger Pau Monné <roger@citrix.com> wrote: >On Thu, May 03, 2018 at 10:02:47PM +1000, Alexey G wrote: >> On Thu, 3 May 2018 12:15:18 +0100 >> Roger Pau Monné <roger@citrix.com> wrote: >> >> >On Thu, May 03

Re: [Xen-devel] [Qemu-devel] [PATCH] xen-hvm: stop faking I/O to access PCI config space

On Thu, 3 May 2018 12:49:59 + Paul Durrant wrote: >> >This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG >> >reqyests are handled by faking PIO to 0xcf8 and 0xcfc and replaces >> >it with direct calls to pci_host_config_read/write_common(). >> >Doing

Re: [Xen-devel] [Qemu-devel] [PATCH] xen-hvm: stop faking I/O to access PCI config space

On Thu, 3 May 2018 12:18:40 +0100 Paul Durrant wrote: >This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG >reqyests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it >with direct calls to pci_host_config_read/write_common(). >Doing so

Re: [Xen-devel] [PATCH for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

On Thu, 3 May 2018 12:15:18 +0100 Roger Pau Monné <roger@citrix.com> wrote: >On Thu, May 03, 2018 at 08:55:14PM +1000, Alexey G wrote: >> On Thu, 3 May 2018 10:56:40 +0100 >> Roger Pau Monne <roger@citrix.com> wrote: >> >> >When running

Re: [Xen-devel] [PATCH for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

On Thu, 3 May 2018 10:56:40 +0100 Roger Pau Monne wrote: >When running as PVH Dom0 the native memory map is used in order to >craft a tailored memory map for Dom0 taking into account it's memory >limit. > >Dom0 memory is always going to be smaller than the total amount >of

[Xen-devel] Notes for upcoming PCI emulation call

I’ll try to summarize current issues/difficulties in extending the PCIe passthrough support and possible ways to resolve these problems which were discussed in the mailing list so far. Possible options to extend PCI passthrough/emulation capabilities

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

On Fri, 13 Apr 2018 11:01:49 +0100 Roger Pau Monné wrote: >On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote: >> >> >> On 12/04/2018, 17:41, "Roger Pau Monne" >> wrote: >> >> On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

On Thu, 12 Apr 2018 16:32:57 + Lars Kurth wrote: >Hi all, > >I had an action to set up a call on discussing the future direction of >PCI Emulation. I CC’ed everyone who raised an interest. I propose to >use Gotomeeting unless there are objections. > >As far as I can

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

On Sun, 8 Apr 2018 23:38:31 +0300 Razvan Cojocaru wrote: >I've noticed altp2m behaviour I can't explain yet - I'm not all that >familiar with all the ways the new views corellate with the previous >EPT-based "view 0". > >In short, if we create a new view and simply

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 28 Mar 2018 10:03:29 + Paul Durrant wrote: >> >IMO a single entity should be in control of the memory layout, and >> >that's the toolstack. >> > >> >Ideally we should not allow the firmware to change the layout at >> >all. >> >> This approach is terribly

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 28 Mar 2018 10:30:32 +0100 Roger Pau Monné <roger@citrix.com> wrote: >On Wed, Mar 28, 2018 at 01:37:29AM +1000, Alexey G wrote: >> On Tue, 27 Mar 2018 09:45:30 +0100 >> Roger Pau Monné <roger@citrix.com> wrote: >> >> >On Tue, Mar 27

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Tue, 27 Mar 2018 09:45:30 +0100 Roger Pau Monné <roger@citrix.com> wrote: >On Tue, Mar 27, 2018 at 05:42:11AM +1000, Alexey G wrote: >> On Mon, 26 Mar 2018 10:24:38 +0100 >> Roger Pau Monné <roger@citrix.com> wrote: >> >> >On Sat, Mar 24

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Mon, 26 Mar 2018 10:24:38 +0100 Roger Pau Monné <roger@citrix.com> wrote: >On Sat, Mar 24, 2018 at 08:32:44AM +1000, Alexey G wrote: [...] >> In fact, the emulated chipset (NB+SB combo without supplemental >> devices) itself is a small part of required emulation. It

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Fri, 23 Mar 2018 13:57:11 + Paul Durrant wrote: [...] >> Few related thoughts: >> >> 1. MMCONFIG address is chipset-specific. On Q35 it's a PCIEXBAR, on >> other x86 systems it may be HECBASE or else. So we can assume it is >> bound to the emulated machine > >Xen

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 12:44:02 + Roger Pau Monné <roger@citrix.com> wrote: >On Thu, Mar 22, 2018 at 10:29:22PM +1000, Alexey G wrote: >> On Thu, 22 Mar 2018 09:57:16 + >> Roger Pau Monné <roger@citrix.com> wrote: >> [...] >> >> Yes, a

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 08:42:09 -0600 "Jan Beulich" wrote: On 22.03.18 at 15:34, wrote: >> On Thu, 22 Mar 2018 07:20:00 -0600 >> "Jan Beulich" wrote: >> >> On 22.03.18 at 14:05, wrote: On Thu, 22 Mar

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 07:20:00 -0600 "Jan Beulich" wrote: On 22.03.18 at 14:05, wrote: >> On Thu, 22 Mar 2018 06:09:44 -0600 >> "Jan Beulich" wrote: >> >> On 22.03.18 at 12:56, wrote: I really don't

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 06:09:44 -0600 "Jan Beulich" wrote: On 22.03.18 at 12:56, wrote: >> I really don't understand why some people have that fear of emulated >> MMCONFIG -- it's really the same thing as any other MMIO range QEMU >> already emulates via

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 09:57:16 + Roger Pau Monné wrote: [...] >> Yes, and it is still needed as we have two distinct (and not equal) >> interfaces to PCI conf space. Apart from 0..FFh range overlapping >> they can be considered very different interfaces. And whether it is

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 10:06:09 + Paul Durrant <paul.durr...@citrix.com> wrote: >> -Original Message----- >> From: Alexey G [mailto:x19...@gmail.com] >> Sent: 22 March 2018 09:55 >> To: Jan Beulich <jbeul...@suse.com> >> Cc: Andrew Cooper &

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 10:09:16 + Paul Durrant wrote: [...] >> > I don't think we even want QEMU to have the freedom to say where >> > the MMCONFIG areas are located, do we? >> >> Sadly this how the chipset works. The PCIEXBAR register contains the >> position of

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 09:29:44 + Paul Durrant wrote: >> -Original Message- [...] >> >In both cases Xen would have to do the MCFG access decoding in order >> >to figure out which IOREQ server will handle the request. At which >> >point the only step that you

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 03:04:16 -0600 "Jan Beulich" wrote: On 22.03.18 at 01:31, wrote: >> On Wed, 21 Mar 2018 17:06:28 + >> Paul Durrant wrote: >> [...] Well, this might work actually. Although the overall scenario

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 21 Mar 2018 17:06:28 + Paul Durrant wrote: [...] >> Well, this might work actually. Although the overall scenario will be >> overcomplicated a bit for _PCI_CONFIG ioreqs. Here is how it will >> look: >> >> QEMU receives PCIEXBAR update -> calls the new dmop

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 21 Mar 2018 17:15:04 + Roger Pau Monné wrote: [...] >> Above scenario makes it obvious that at least for QEMU the MMIO->PCI >> conf translation is a redundant step. Why not to allow specifying >> for DM whether it prefers to receive MMCONFIG accesses as native >>

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 21 Mar 2018 14:54:16 + Paul Durrant <paul.durr...@citrix.com> wrote: >> -Original Message----- >> From: Alexey G [mailto:x19...@gmail.com] >> Sent: 21 March 2018 14:26 >> To: Roger Pau Monne <roger@citrix.com> >> Cc: xen

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 21 Mar 2018 15:20:17 + Roger Pau Monné <roger@citrix.com> wrote: >On Thu, Mar 22, 2018 at 12:25:40AM +1000, Alexey G wrote: >> Roger, Paul, >> >> Here is what you suggest, just to clarify: >> >> 1. Add to Xen a new hypercall (+correspond

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 21 Mar 2018 09:36:04 + Paul Durrant wrote: >> >> Although this is the most common scenario, it's not the only one >> supported by Xen. Your proposed solution breaks the usage of multiple >> IOREQ servers as PCI device emulators. > >Indeed it will, and that is

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Wed, 21 Mar 2018 09:09:11 + Roger Pau Monné <roger@citrix.com> wrote: >On Wed, Mar 21, 2018 at 10:58:40AM +1000, Alexey G wrote: [...] >> According to public slides for the feature, both PCI conf and MMIO >> accesses can be routed to the designated device

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Tue, 20 Mar 2018 08:50:48 + Roger Pau Monné <roger@citrix.com> wrote: >On Tue, Mar 20, 2018 at 05:49:22AM +1000, Alexey G wrote: >> On Mon, 19 Mar 2018 15:58:02 + >> Roger Pau Monné <roger@citrix.com> wrote: >> >> >On Tue, Mar 13, 20

Re: [Xen-devel] [RFC PATCH 06/12] hvmloader: add basic Q35 support

On Tue, 20 Mar 2018 09:20:01 + Roger Pau Monné <roger@citrix.com> wrote: >On Tue, Mar 20, 2018 at 09:44:33AM +1000, Alexey G wrote: >> On Mon, 19 Mar 2018 15:30:14 + >> Roger Pau Monné <roger@citrix.com> wrote: >> >> >On Tue, Mar 13, 20

Re: [Xen-devel] [RFC PATCH 10/12] libacpi: build ACPI MCFG table if requested

On Tue, 20 Mar 2018 09:03:56 + Roger Pau Monné <roger@citrix.com> wrote: >On Tue, Mar 20, 2018 at 07:46:04AM +1000, Alexey G wrote: >> On Mon, 19 Mar 2018 17:33:34 + >> Roger Pau Monné <roger@citrix.com> wrote: >> >> >On Tue, Mar 13, 20

Re: [Xen-devel] [RFC PATCH 11/12] hvmloader: use libacpi to build MCFG table

On Tue, 20 Mar 2018 03:36:57 -0600 "Jan Beulich" wrote: On 19.03.18 at 22:20, wrote: >> On Mon, 19 Mar 2018 17:49:09 + >> Roger Pau Monné wrote: >>>On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote:

Re: [Xen-devel] [RFC PATCH 05/12] hvmloader: add Q35 DSDT table loading

On Mon, 19 Mar 2018 14:45:29 + Roger Pau Monné wrote: >On Tue, Mar 13, 2018 at 04:33:50AM +1000, Alexey Gerasimenko wrote: >> Allows to select Q35 DSDT table in hvmloader_acpi_build_tables(). >> Function get_pc_machine_type() is used to select a proper table >>

Re: [Xen-devel] [RFC PATCH 06/12] hvmloader: add basic Q35 support

On Mon, 19 Mar 2018 15:30:14 + Roger Pau Monné wrote: >On Tue, Mar 13, 2018 at 04:33:51AM +1000, Alexey Gerasimenko wrote: >> This patch does following: >> >> 1. Move PCI-device specific initialization out of pci_setup function >> to the newly created

Re: [Xen-devel] [RFC PATCH 08/12] libxl: Q35 support (new option device_model_machine)

On Mon, 19 Mar 2018 17:01:18 + Roger Pau Monné wrote: >On Tue, Mar 13, 2018 at 04:33:53AM +1000, Alexey Gerasimenko wrote: >> Provide a new domain config option to select the emulated machine >> type, device_model_machine. It has following possible values: >> - "i440" -

Re: [Xen-devel] [RFC PATCH 10/12] libacpi: build ACPI MCFG table if requested

On Mon, 19 Mar 2018 17:33:34 + Roger Pau Monné wrote: >On Tue, Mar 13, 2018 at 04:33:55AM +1000, Alexey Gerasimenko wrote: >> This adds construct_mcfg() function to libacpi which allows to build >> MCFG table for a given mmconfig_addr/mmconfig_len pair if the >>

Re: [Xen-devel] [RFC PATCH 11/12] hvmloader: use libacpi to build MCFG table

On Mon, 19 Mar 2018 17:49:09 + Roger Pau Monné wrote: >On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote: >> This patch extends hvmloader_acpi_build_tables() with code which >> detects if MMCONFIG is available -- i.e. initialized and enabled >> (+we're

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Mon, 19 Mar 2018 15:58:02 + Roger Pau Monné wrote: >On Tue, Mar 13, 2018 at 04:33:52AM +1000, Alexey Gerasimenko wrote: >> Much like normal PCI BARs or other chipset-specific memory-mapped >> resources, MMCONFIG area needs space in MMIO hole, so we must >> allocate

Re: [Xen-devel] [RFC PATCH 03/12] hvmloader: add function to query an emulated machine type (i440/Q35)

On Mon, 19 Mar 2018 12:56:51 + Roger Pau Monné wrote: >On Tue, Mar 13, 2018 at 04:33:48AM +1000, Alexey Gerasimenko wrote: >> This adds a new function get_pc_machine_type() which allows to >> determine the emulated chipset type. Supported return values: >> >> -

Re: [Xen-devel] [RFC PATCH 09/12] libxl: Xen Platform device support for Q35

On Tue, 13 Mar 2018 04:33:54 +1000 Alexey Gerasimenko wrote: >Current Xen/QEMU method to control Xen Platform device is a bit odd -- >changing 'xen_platform_device' option value actually modifies QEMU >emulated machine type, namely xenfv <--> pc. > >In order to avoid

Re: [Xen-devel] [RFC PATCH 02/12] Makefile: build and use new DSDT table for Q35

On Mon, 19 Mar 2018 12:46:05 + Roger Pau Monné wrote: >On Tue, Mar 13, 2018 at 04:33:47AM +1000, Alexey Gerasimenko wrote: >> Provide building for newly added dsdt_q35.asl file, in a way similar >> to dsdt.asl. >> >> Note that '15cpu' ACPI tables are only applicable to

Re: [Xen-devel] [RFC PATCH 02/12] Makefile: build and use new DSDT table for Q35

On Mon, 19 Mar 2018 07:07:34 -0600 "Jan Beulich" wrote: On 12.03.18 at 19:33, wrote: >> --- a/tools/firmware/hvmloader/Makefile >> +++ b/tools/firmware/hvmloader/Makefile >> @@ -75,7 +75,7 @@ rombios.o: roms.inc >> smbios.o: CFLAGS +=

Re: [Xen-devel] [RFC PATCH 01/12] libacpi: new DSDT ACPI table for Q35

On Mon, 19 Mar 2018 12:43:05 + Roger Pau Monné wrote: >On Tue, Mar 13, 2018 at 04:33:46AM +1000, Alexey Gerasimenko wrote: >> This patch adds the DSDT table for Q35 (new >> tools/libacpi/dsdt_q35.asl file). There are not many differences >> with dsdt.asl (for i440) at

Re: [Xen-devel] [RFC PATCH 00/30] Xen Q35 Bringup patches + support for PCIe Extended Capabilities for passed through devices

A gentle RFC-ping. Any thoughts on this? Regarding the feature as a whole. So far there were responses mostly targeting individual patches, while I'd like to hear about chosen approaches in general, whether the overall direction is correct (or not), etc. It's just RFC after all, not v11. :) I

Re: [Xen-devel] [RFC PATCH 11/12] hvmloader: use libacpi to build MCFG table

On Tue, 13 Mar 2018 04:33:56 +1000 Alexey Gerasimenko wrote: >This patch extends hvmloader_acpi_build_tables() with code which >detects if MMCONFIG is available -- i.e. initialized and enabled >(+we're running on Q35), obtains its base address and size and asks >libacpi to

Re: [Xen-devel] [RFC PATCH 13/30] pc/xen: Xen Q35 support: provide IRQ handling for PCI devices

On Wed, 14 Mar 2018 11:48:46 +0100 Paolo Bonzini wrote: >On 12/03/2018 19:33, Alexey Gerasimenko wrote: >> xen_pci_slot_get_pirq --> xen_cmn_pci_slot_get_pirq >> xen_piix3_set_irq --> xen_cmn_set_irq > >Don't abbrvt names, xen_hvm_ is a better prefix. Agree, will

Re: [Xen-devel] [RFC PATCH 16/30] q35/xen: Add Xen platform device support for Q35

On Mon, 12 Mar 2018 18:44:02 -0300 Eduardo Habkost <ehabk...@redhat.com> wrote: >On Tue, Mar 13, 2018 at 06:56:37AM +1000, Alexey G wrote: >> On Mon, 12 Mar 2018 16:44:06 -0300 >> Eduardo Habkost <ehabk...@redhat.com> wrote: >> >> >On Tue, Mar 13, 20

Re: [Xen-devel] [RFC PATCH 03/12] hvmloader: add function to query an emulated machine type (i440/Q35)

On Tue, 13 Mar 2018 17:26:04 + Wei Liu wrote: >On Tue, Mar 13, 2018 at 04:33:48AM +1000, Alexey Gerasimenko wrote: >> This adds a new function get_pc_machine_type() which allows to >> determine the emulated chipset type. Supported return values: >> >> -

Re: [Xen-devel] [Qemu-devel] [RFC PATCH 00/30] Xen Q35 Bringup patches + support for PCIe Extended Capabilities for passed through devices

On Tue, 13 Mar 2018 09:21:54 + Daniel P. Berrangé wrote: >The subject line says to expect 30 patches, but you've only sent 18 to >the list here. I eventually figured out that the first 12 patches were >in Xen code and so not sent to qemu-devel. > >For future if you have

Re: [Xen-devel] [RFC PATCH 01/12] libacpi: new DSDT ACPI table for Q35

On Mon, 12 Mar 2018 16:32:27 -0400 Konrad Rzeszutek Wilk <konrad.w...@oracle.com> wrote: >On Tue, Mar 13, 2018 at 06:10:35AM +1000, Alexey G wrote: >> On Mon, 12 Mar 2018 15:38:03 -0400 >> Konrad Rzeszutek Wilk <konrad.w...@oracle.com> wrote: >> >> &g

Re: [Xen-devel] [RFC PATCH 16/30] q35/xen: Add Xen platform device support for Q35

On Mon, 12 Mar 2018 16:44:06 -0300 Eduardo Habkost wrote: >On Tue, Mar 13, 2018 at 04:34:01AM +1000, Alexey Gerasimenko wrote: >> Current Xen/QEMU method to control Xen Platform device on i440 is a >> bit odd -- enabling/disabling Xen platform device actually modifies >> the

Re: [Xen-devel] [RFC PATCH 01/12] libacpi: new DSDT ACPI table for Q35

On Mon, 12 Mar 2018 15:38:03 -0400 Konrad Rzeszutek Wilk wrote: >On Tue, Mar 13, 2018 at 04:33:46AM +1000, Alexey Gerasimenko wrote: >> This patch adds the DSDT table for Q35 (new >> tools/libacpi/dsdt_q35.asl file). There are not many differences >> with dsdt.asl (for

Re: [Xen-devel] [PATCH v2] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

On Fri, 16 Feb 2018 17:46:48 + Igor Druzhinin wrote: >We're noticing a reproducible system boot hang on certain >post-Skylake platforms where the BIOS is configured in >legacy boot mode with x2APIC disabled. The system stalls >immediately after writing the first

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

h larger chunks of data thus reducing the number of emulator calls. >2018-02-16 3:08 GMT+01:00 Alexey G <x19...@gmail.com>: > >> On Thu, 15 Feb 2018 17:02:35 +0100 >> Yessine Daoud <da.yess...@gmail.com> wrote: >> >> > Hello, >> > >> >

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

On Thu, 15 Feb 2018 17:02:35 +0100 Yessine Daoud wrote: > Hello, > >I tried to debug the issue and this what I found: >the HVM boot takes some time at the following section >(qemu/pc-bios/optionrom/linuxboot.S) >/* Load kernel and initrd */

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On Thu, 8 Feb 2018 15:00:33 + Andrew Cooper <andrew.coop...@citrix.com> wrote: >On 08/02/18 14:37, Alexey G wrote: >> On Thu, 8 Feb 2018 12:40:41 + >> Andrew Cooper <andrew.coop...@citrix.com> wrote: >>> - Perf/Oprofile.  This is currently m

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On Thu, 8 Feb 2018 12:40:41 + Andrew Cooper wrote: >- Perf/Oprofile.  This is currently mutually exclusive with Xen using >the watchdog, but needn't be and hopefully won't be in the future. > >> >> Most of the time we deal with watchdog NMIs, while all others should

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On Thu, 8 Feb 2018 10:47:45 + Igor Druzhinin wrote: >I've done this measurement before. So what we are seeing exactly is >that the time we are spending in SMI is spiking (sometimes up to >200ms) at the moment we go through INIT-SIPI-SIPI sequence. Looks like >this

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On Wed, 7 Feb 2018 13:01:08 + Igor Druzhinin wrote: >So far the issue confirmed: >Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one >that it was tested on), Intel S2600XX, etc. > >Also see: >https://bugs.xenserver.org/browse/XSO-774 > >Well,

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

If the actual SMI source is not related to some place in the NMI handler code but was eg. due to some SMI timer, lowering NMI watchdog frequency might not fix the issue completely, but lower its reproducibility (perhaps to some very rare occurrences). So it's better be

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On Tue, 6 Feb 2018 17:21:19 + Igor Druzhinin <igor.druzhi...@citrix.com> wrote: >On 06/02/18 17:08, Alexey G wrote: >> The major concern here is the possiblity of SMI being triggered _not_ >> by some specific I/O port access. Primarily, if it actually

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On Tue, 6 Feb 2018 14:21:12 + Andrew Cooper <andrew.coop...@citrix.com> wrote: >On 06/02/18 03:10, Alexey G wrote: >> I/O port 61h normally is not emulated by SMI legacy kbd handling code >> in BIOS, only ports like 60h, 64h, etc. >> Contrary to USB legacy emulatio

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On Mon, 5 Feb 2018 21:18:42 + Igor Druzhinin wrote: >We're noticing a reproducible system boot hang on certain >post-Skylake platforms where the BIOS is configured in >legacy boot mode with x2APIC disabled. The system stalls >immediately after writing the first SMP