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 switch to it early in the
>boot
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 tell, we have people in the
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:
>>
>>
>> >may work. For me Mon,
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
---
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 memory present on the h
On Thu, 3 May 2018 12:15:18 +0100
Roger Pau Monné 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 wrote:
>>
>> >When running as PVH Dom0 the native memory map is used in order to
>&
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 necessitates mapping BDFs to PCIDev
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 so necessitates mapping BDF
On Thu, 3 May 2018 15:02:36 +0100
Roger Pau Monné 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é wrote:
>>
>> >On Thu, May 03, 2018 at 08:55:14PM +1000, Alexey G wrote:
>>
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.
>Roger: Another option w
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 i440) at the moment, namely
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 QEMU emulated machine
On Mon, 12 Mar 2018 16:32:27 -0400
Konrad Rzeszutek Wilk 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 wrote:
>>
>> >On Tue, Mar 13, 2018 at 04:33:46AM +1000, Alexey Gerasimenko
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 changes that affect mu
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:
>>
>> - MACHINE_TYPE_I440
>> - MACHINE_TYPE_Q3
On Mon, 12 Mar 2018 18:44:02 -0300
Eduardo Habkost 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 wrote:
>>
>> >On Tue, Mar 13, 2018 at 04:34:01AM +1000, Alexey Gerasimenko
>> >
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 rename xen_cmn_* to xen_hv
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 build MCFG table for it
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 can
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 the moment, namely:
>>
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 += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
>>
>> A
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 qemu-traditional
>> (w
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 multiplying machine types, us
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:
>>
>> - MACHINE_TYPE_I440
>> - MACHINE
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 it manually.
>>
>> The
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 running on Q35), obtain
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
>> ACPI_HAS_MCFG flag was specifi
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" - i440 emulation (defaul
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 class_specific_pci_device_setup function
On Mon, 19 Mar 2018 13:01:58 +
Roger Pau Monné wrote:
>On Tue, Mar 13, 2018 at 04:33:49AM +1000, Alexey Gerasimenko wrote:
>> In order to turn on ACPI for OS, we need to write a chipset-specific
>> value to SMI_CMD register (sort of imitation of the APM->ACPI switch
>> on real systems). Modif
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
>> (i440/q35).
>>
>> As we are bo
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:
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firm
On Tue, 20 Mar 2018 09:03:56 +
Roger Pau Monné 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é wrote:
>>
>> >On Tue, Mar 13, 2018 at 04:33:55AM +1000, Alexey Gerasimenko
>> >
On Tue, 20 Mar 2018 09:20:01 +
Roger Pau Monné 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é wrote:
>>
>> >On Tue, Mar 13, 2018 at 04:33:51AM +1000, Alexey Gerasimenko
>> &g
On Tue, 20 Mar 2018 08:50:48 +
Roger Pau Monné 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é wrote:
>>
>> >On Tue, Mar 13, 2018 at 04:33:52AM +1000, Alexey Gerasimenko
>>
On Wed, 21 Mar 2018 09:09:11 +
Roger Pau Monné 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 model. It looks like
>> for thi
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 not acceptable even in th
On Wed, 21 Mar 2018 15:20:17 +
Roger Pau Monné 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 (+corresponding dmop) so QEMU can tell
>
On Wed, 21 Mar 2018 14:54:16 +
Paul Durrant wrote:
>> -Original Message-
>> From: Alexey G [mailto:x19...@gmail.com]
>> Sent: 21 March 2018 14:26
>> To: Roger Pau Monne
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Ian Jackson ;
>&g
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
>> (MMIO ones) or as tran
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 to tell Xen new
>> MMCONFIG
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 will
be overcomplicated a bit for _PCI_CONFIG ioreqs. Here
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 avoid is the reconstruction o
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 the MCFG area. And this is e
On Thu, 22 Mar 2018 10:06:09 +
Paul Durrant wrote:
>> -Original Message-
>> From: Alexey G [mailto:x19...@gmail.com]
>> Sent: 22 March 2018 09:55
>> To: Jan Beulich
>> Cc: Andrew Cooper ; Anthony Perard
>> ; Ian Jackson ;
>> Paul Durran
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
>> a real system or emu
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 map_io_range_to_ioreq_server(). No se
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 understand why some people have that fear of
emulated MMCONFIG -- it'
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 2018 06:09:44 -0600
"Jan Beulich" wrote:
On 22.03
On Thu, 22 Mar 2018 12:44:02 +
Roger Pau Monné 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é wrote:
>> [...]
>> >> Yes, and it is still needed as we have two distinct (and not
&g
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 emulates the machine so it
On Mon, 26 Mar 2018 10:24:38 +0100
Roger Pau Monné 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's
>> relatively e
On Tue, 27 Mar 2018 09:45:30 +0100
Roger Pau Monné 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é wrote:
>>
>> >On Sat, Mar 24, 2018 at 08:32:44AM +1000, Alexey G wrote:
>>
On Wed, 28 Mar 2018 10:30:32 +0100
Roger Pau Monné 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é wrote:
>>
>> >On Tue, Mar 27, 2018 at 05:42:11AM +1000, Alexey G wrote:
>> &
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 wrong, I don't know why opin
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 PCIEXBAR_ADDR_MA
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 */
>> #d
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
>> + */
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
&
>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
>>>>
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
>>>>"Jan Beulich
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
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
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 initialization
>sequence in
On Tue, 6 Feb 2018 14:21:12 +
Andrew Cooper 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 emulation, it has to intercept port 6
On Tue, 6 Feb 2018 17:21:19 +
Igor Druzhinin 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 was a
>> periodic SMI.
>>
>> If the
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 sur
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, no-watchdog is what we currently
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 is enough to push the system
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
>> be somewhat rare. The th
On Thu, 8 Feb 2018 15:00:33 +
Andrew Cooper wrote:
>On 08/02/18 14:37, Alexey G wrote:
>> 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&#
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 */
>read_fw_blob_addr32_edi(FW_CFG_INITRD) (ramdisk about 3
memory_rw() with larger chunks of data thus reducing the
number of emulator calls.
>2018-02-16 3:08 GMT+01:00 Alexey G :
>
>> On Thu, 15 Feb 2018 17:02:35 +0100
>> Yessine Daoud wrote:
>>
>> > Hello,
>> >
>> >I tried to debug the issue and
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 SMP initialization
>sequence i
On Mon, 19 Feb 2018 14:48:37 +
Andrew Cooper wrote:
>On 19/02/18 14:23, Igor Druzhinin wrote:
>> We're noticing a reproducible system boot hang on certain
>> post-Skylake platforms where the BIOS is configured in
>
>These are Skylake, not post-Skylake.
Well, strictly speaking, any platform
75 matches
Mail list logo
