On 2020-06-24 20:02, Souptick Joarder wrote:
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information. This is case 5 as per document [1].
[1] Documentation/core-api/pin_user_pages.rst
flight 151328 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065
flight 151330 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151330/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151308
test-armhf-armhf-libvirt-raw 13
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information. This is case 5 as per document [1].
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
Previously, if lock_pages() end up partially mapping pages, it used
to return -ERRNO due to which unlock_pages() have to go through
each pages[i] till *nr_pages* to validate them. This can be avoided
by passing correct number of partially mapped pages & -ERRNO separately,
while returning from
On Wed, Jun 24, 2020 at 1:57 PM Dr. David Alan Gilbert
wrote:
>
> * Jason Andryuk (jandr...@gmail.com) wrote:
> > Hi,
> >
> > At some point, QEMU changed to add a json VM description (vmdesc)
> > after the migration data. The vmdesc is not needed to restore the
> > migration data, but
On Wed, Jun 24, 2020 at 12:19 PM Ian Jackson wrote:
>
> Jan Beulich writes ("Re: use of "stat -""):
> > [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> > unless you have verified the sender and know the content is safe.
> > On 14.05.2020 13:02, Ian Jackson wrote:
> >
flight 151323 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151323/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
On 24/06/2020 17:13, Ian Jackson wrote:
> I think it would be a good idea to rename this branch name.
The tech industry does use some problematic terms, and I fully agree
with taking steps to reduce their use. However, I disagree that this is
a problematic context.
In the English language,
On 6/24/20 12:41 PM, Souptick Joarder wrote:
> On Wed, Jun 24, 2020 at 9:07 PM Boris Ostrovsky
> wrote:
>> On 6/23/20 9:36 PM, Souptick Joarder wrote:
>>> On Tue, Jun 23, 2020 at 11:11 PM Boris Ostrovsky
>>> wrote:
On 6/23/20 7:58 AM, Souptick Joarder wrote:
> In 2019, we introduced
On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote:
> On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote:
> > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng
On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> > > > Export xen_swiotlb for all platforms using xen swiotlb
> >
On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote:
> On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> > > Export xen_swiotlb for all platforms using xen swiotlb
> > >
> > > Use xen_swiotlb to determine when vring
flight 151318 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151318/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
flight 151320 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151320/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1a992030522622c42aa063788b3276789c56c1e1
baseline version:
ovmf
On Wed, 24 Jun 2020 18:53:05 +0200
Markus Armbruster wrote:
> Greg Kurz writes:
>
> > On Mon, 15 Jun 2020 07:21:03 +0200
> > Markus Armbruster wrote:
> >
> >> Greg Kurz writes:
> >>
> >> > On Tue, 17 Mar 2020 18:16:17 +0300
> >> > Vladimir Sementsov-Ogievskiy wrote:
> >> >
> >> >>
On Wed, 24 Jun 2020, Oleksandr Andrushchenko wrote:
> On 6/24/20 8:05 PM, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Oleksandr Andrushchenko wrote:
> >> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
> >>> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
> On Mon, 22 Jun 2020, Julien
On 6/24/20 8:05 PM, Stefano Stabellini wrote:
> On Wed, 24 Jun 2020, Oleksandr Andrushchenko wrote:
>> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
>>> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
On Mon, 22 Jun 2020, Julien Grall wrote:
For the first part
On Wed, Jun 24, 2020 at 10:39 AM Stefano Stabellini
wrote:
>
> On Wed, 24 Jun 2020, Ian Jackson wrote:
> > I think it would be a good idea to rename this branch name. This name
> > has unfortunate associations[1], even if it can be argued[2] that the
> > etymology is not as bad as in some uses
On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> > Export xen_swiotlb for all platforms using xen swiotlb
> >
> > Use xen_swiotlb to determine when vring should use dma APIs to map the
> > ring: when xen_swiotlb is enabled the dma API is
* Jason Andryuk (jandr...@gmail.com) wrote:
> Hi,
>
> At some point, QEMU changed to add a json VM description (vmdesc)
> after the migration data. The vmdesc is not needed to restore the
> migration data, but qemu_loadvm_state() will read and discard the
> vmdesc to clear the stream when
On Wed, 24 Jun 2020, Ian Jackson wrote:
> I think it would be a good idea to rename this branch name. This name
> has unfortunate associations[1], even if it can be argued[2] that the
> etymology is not as bad as in some uses of the word.
>
> This is relativity straightforward on a technical
On Wed, 24 Jun 2020, Bertrand Marquis wrote:
> > On 23 Jun 2020, at 21:50, CodeWiz2280 wrote:
> >
> > Is it possible to passthrough PCI devices to domU on the 32-bit arm
> > keystone? Any info is appreciated.
> >
> > I found some old information online that "gic-v2m" is required. I'm
> > not
On Wed, 24 Jun 2020, Oleksandr Andrushchenko wrote:
> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
> >
> > On 6/23/20 4:20 AM, Stefano Stabellini wrote:
> >> On Mon, 22 Jun 2020, Julien Grall wrote:
> >> For the first part (__XEN_INTERFACE_VERSION__) I think we can provide
> >> it
>
Greg Kurz writes:
> On Mon, 15 Jun 2020 07:21:03 +0200
> Markus Armbruster wrote:
>
>> Greg Kurz writes:
>>
>> > On Tue, 17 Mar 2020 18:16:17 +0300
>> > Vladimir Sementsov-Ogievskiy wrote:
>> >
>> >> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
>> >> functions with an
On Wed, Jun 24, 2020 at 9:07 PM Boris Ostrovsky
wrote:
>
> On 6/23/20 9:36 PM, Souptick Joarder wrote:
> > On Tue, Jun 23, 2020 at 11:11 PM Boris Ostrovsky
> > wrote:
> >> On 6/23/20 7:58 AM, Souptick Joarder wrote:
> >>> In 2019, we introduced pin_user_pages*() and now we are converting
> >>>
flight 151316 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 150176
Jan Beulich writes ("Re: use of "stat -""):
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
> On 14.05.2020 13:02, Ian Jackson wrote:
> > I've read this thread. Jan, I'm sorry that this causes you
> >
I think it would be a good idea to rename this branch name. This name
has unfortunate associations[1], even if it can be argued[2] that the
etymology is not as bad as in some uses of the word.
This is relativity straightforward on a technical level and will
involve a minimum of inconvenience.
On 18.05.2020 12:34, Jan Beulich wrote:
> On 14.05.2020 13:02, Ian Jackson wrote:
>> I've read this thread. Jan, I'm sorry that this causes you
>> inconvenience. I'm hoping it won't come down to a choice between
>> supporting people who want to ship a dom0 without perl, and people who
>> want a
On 6/23/20 9:36 PM, Souptick Joarder wrote:
> On Tue, Jun 23, 2020 at 11:11 PM Boris Ostrovsky
> wrote:
>> On 6/23/20 7:58 AM, Souptick Joarder wrote:
>>> In 2019, we introduced pin_user_pages*() and now we are converting
>>> get_user_pages*() to the new API as appropriate. [1] & [2] could
>>> be
(sorry, re-sending with To and Cc corrected)
On 22.06.2020 14:39, Andrew Cooper wrote:
> On 22/06/2020 13:09, Jan Beulich wrote:
>> Coverity validly complains that the new call from
>> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves
>> two fields uninitialized, yet they get
On 22.06.2020 14:39, Andrew Cooper wrote:
> On 22/06/2020 13:09, Jan Beulich wrote:
>> Coverity validly complains that the new call from
>> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves
>> two fields uninitialized, yet they get then consumed by
>> x86_cpuid_copy_to_buffer().
On 22.06.2020 10:49, Jan Beulich wrote:
> On 20.06.2020 00:00, Grzegorz Uriasz wrote:
>> @@ -490,8 +497,12 @@ static int __init acpi_parse_fadt(struct
>> acpi_table_header *table)
>> */
>> if (!pmtmr_ioport) {
>> pmtmr_ioport = fadt->pm_timer_block;
>> -
On 24.06.2020 15:41, Julien Grall wrote:
> On 24/06/2020 11:12, Jan Beulich wrote:
>> On 23.06.2020 19:26, Roger Pau Monné wrote:
>>> I'm confused. Couldn't we switch from uint64_aligned_t to plain
>>> uint64_t (like it's currently on the Linux headers), and then use the
>>> compat layer in Xen to
Hi Jan,
On 24/06/2020 11:12, Jan Beulich wrote:
On 23.06.2020 19:26, Roger Pau Monné wrote:
On Tue, Jun 23, 2020 at 06:18:52PM +0200, Jan Beulich wrote:
On 23.06.2020 17:56, Roger Pau Monné wrote:
On Tue, Jun 23, 2020 at 05:02:04PM +0200, Jan Beulich wrote:
On 23.06.2020 15:52, Roger Pau
Hi,
At some point, QEMU changed to add a json VM description (vmdesc)
after the migration data. The vmdesc is not needed to restore the
migration data, but qemu_loadvm_state() will read and discard the
vmdesc to clear the stream when should_send_vmdesc() is true.
xen-save-devices-state
On 24.06.2020 14:53, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 24 June 2020 13:52
>> To: Julien Grall
>> Cc: Roger Pau Monné ; xen-devel@lists.xenproject.org;
>> p...@xen.org; Andrew
>> Cooper ; George Dunlap
>> ; Ian Jackson
>> ; Stefano Stabellini ;
>>
> -Original Message-
> From: Jan Beulich
> Sent: 24 June 2020 13:52
> To: Julien Grall
> Cc: Roger Pau Monné ; xen-devel@lists.xenproject.org;
> p...@xen.org; Andrew
> Cooper ; George Dunlap ;
> Ian Jackson
> ; Stefano Stabellini ; Wei
> Liu
> Subject: Re: [PATCH for-4.14] mm: fix
On Wed, Jun 24, 2020 at 6:40 AM Andrew Cooper wrote:
>
> On 24/06/2020 11:03, Jan Beulich wrote:
> > On 23.06.2020 19:24, Andrew Cooper wrote:
> >> On 23/06/2020 09:51, Jan Beulich wrote:
> >>> On 23.06.2020 03:04, Michał Leszczyński wrote:
> - 22 cze 2020 o 18:16, Jan Beulich
On 24.06.2020 14:47, Julien Grall wrote:
> Hi,
>
> On 24/06/2020 13:08, Jan Beulich wrote:
>> On 24.06.2020 12:52, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 24/06/2020 11:05, Jan Beulich wrote:
On 23.06.2020 19:32, Roger Pau Monné wrote:
> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan
On Wed, Jun 24, 2020 at 8:30 AM Paul Durrant wrote:
>
> > -Original Message-
> > From: Jason Andryuk
> > Sent: 24 June 2020 13:20
> > To: Stefano Stabellini ; Anthony Perard
> > ; Paul
> > Durrant ; xen-devel@lists.xenproject.org
> > Cc: Jason Andryuk ; qemu-de...@nongnu.org
> >
Hi,
On 24/06/2020 13:08, Jan Beulich wrote:
On 24.06.2020 12:52, Julien Grall wrote:
Hi Jan,
On 24/06/2020 11:05, Jan Beulich wrote:
On 23.06.2020 19:32, Roger Pau Monné wrote:
On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote:
On 23.06.2020 15:52, Roger Pau Monne wrote:
flight 151311 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151311/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151290
On 17/06/2020 23:28, Richard Simpson wrote:
Hello Julien,
Hello Richard,
Apologies for the late answer.
I have just tried 4.14-rc2 and it seems to work fine.
Glad to hear that. Thank you for the testing!
I think that the most useful page regarding the board is the one for the
On 24/06/2020 11:03, Jan Beulich wrote:
> On 23.06.2020 19:24, Andrew Cooper wrote:
>> On 23/06/2020 09:51, Jan Beulich wrote:
>>> On 23.06.2020 03:04, Michał Leszczyński wrote:
- 22 cze 2020 o 18:16, Jan Beulich jbeul...@suse.com napisał(a):
> On 22.06.2020 18:02, Michał
> -Original Message-
> From: Jason Andryuk
> Sent: 24 June 2020 13:20
> To: Stefano Stabellini ; Anthony Perard
> ; Paul
> Durrant ; xen-devel@lists.xenproject.org
> Cc: Jason Andryuk ; qemu-de...@nongnu.org
> Subject: [PATCH] xen: Fix xen-legacy-backend qdev types
>
> xen-sysdev is a
- 23 cze 2020 o 19:24, Andrew Cooper andrew.coop...@citrix.com napisał(a):
> On 23/06/2020 09:51, Jan Beulich wrote:
>> I'd still like to see an explicit confirmation by him that this
>> use of memory is indeed what he has intended. There are much smaller
>> amounts of memory which we allocate
xen-sysdev is a TYPE_SYS_BUS_DEVICE. bus_type should not be changed so
that it can plug into the System bus. Otherwise this assert triggers:
qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion
`dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)'
failed.
From: Paul Durrant
The generic pc_machine_initfn() calls pc_system_flash_create() which creates
'system.flash0' and 'system.flash1' devices. These devices are then realized
by pc_system_flash_map() which is called from pc_system_firmware_init() which
itself is called via pc_memory_init(). The
From: Paul Durrant
'xen-sysdev' plugs into the 'System' bus type, not 'xen-sysbus. That bus type
is what 'xen-backend' plugs into.
'xen-sysdev' is drived form 'sys-bus-device' so the bus type need not be
overridden. 'xen-backend' is derived from 'device', which plugs into the
generic 'bus' type,
From: Paul Durrant
Paul Durrant (2):
xen: fix legacy 'xen-sysdev' and 'xen-backend' bus types
xen: cleanup unrealized flash devices
hw/i386/pc_piix.c | 9 ++---
hw/i386/pc_sysfw.c | 2 +-
hw/xen/xen-legacy-backend.c | 4 ++--
include/hw/i386/pc.h| 1 +
4
> -Original Message-
> From: Jason Andryuk
> Sent: 24 June 2020 13:15
> To: Paul Durrant
> Cc: Markus Armbruster ; Mark Cave-Ayland
> ; Anthony
> PERARD ; xen-devel
> ; QEMU de...@nongnu.org>
> Subject: Re: sysbus failed assert for xen_sysdev
>
> On Wed, Jun 24, 2020 at 6:29 AM Paul
On Wed, Jun 24, 2020 at 6:29 AM Paul Durrant wrote:
>
> > -Original Message-
> > From: Jason Andryuk
> > Sent: 24 June 2020 04:24
> > To: Paul Durrant
> > Cc: Markus Armbruster ; Mark Cave-Ayland
> > ; Anthony
> > PERARD ; xen-devel
> > ; QEMU > de...@nongnu.org>
> > Subject: Re:
On 24.06.2020 12:52, Julien Grall wrote:
> Hi Jan,
>
> On 24/06/2020 11:05, Jan Beulich wrote:
>> On 23.06.2020 19:32, Roger Pau Monné wrote:
>>> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote:
On 23.06.2020 15:52, Roger Pau Monne wrote:
> XENMEM_acquire_resource and it's
Julien Grall writes ("Re: [INPUT REQUESTED][PATCH v3 for-4.14] pvcalls:
Document correctly and explicitely the padding for all arches"):
> Gentle ping. It would be good to get this resolved for Xen 4.14.
Oh and I agree that this should be changed for 4.14.
Ian.
Julien Grall writes ("Re: [PATCH v3 for-4.14] pvcalls: Document correctly and
explicitely the padding for all arches"):
> (+ Committers)
...
> As Jan and you disagree on the approach, I would like to get more input.
>
> To summarize the discussion, the document for PV calls and the public
>
Hi
Gentle ping. It would be good to get this resolved for Xen 4.14.
On 18/06/2020 16:00, Julien Grall wrote:
(+ Committers)
On 18/06/2020 02:34, Stefano Stabellini wrote:
On Tue, 16 Jun 2020, Julien Grall wrote:
On Tue, 16 Jun 2020 at 21:57, Stefano Stabellini
wrote:
On Tue, 16 Jun 2020,
Hi Roger,
On 23/06/2020 17:16, Roger Pau Monné wrote:
On Tue, Jun 23, 2020 at 04:46:29PM +0100, Julien Grall wrote:
On 23/06/2020 16:15, Roger Pau Monné wrote:
On Tue, Jun 23, 2020 at 04:08:06PM +0100, Julien Grall wrote:
Hi Roger,
On 23/06/2020 15:50, Roger Pau Monne wrote:
diff --git
Hi Jan,
On 24/06/2020 11:05, Jan Beulich wrote:
On 23.06.2020 19:32, Roger Pau Monné wrote:
On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote:
On 23.06.2020 15:52, Roger Pau Monne wrote:
XENMEM_acquire_resource and it's related structure is currently inside
a __XEN__ or
Jan Beulich writes ("Re: [xen-4.11-testing test] 151295: regressions - FAIL"):
> On 23.06.2020 20:32, osstest service owner wrote:
> > flight 151295 xen-4.11-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/151295/
> >
> > Regressions :-(
> >
> > Tests which did not
> -Original Message-
> From: Jason Andryuk
> Sent: 24 June 2020 04:24
> To: Paul Durrant
> Cc: Markus Armbruster ; Mark Cave-Ayland
> ; Anthony
> PERARD ; xen-devel
> ; QEMU de...@nongnu.org>
> Subject: Re: sysbus failed assert for xen_sysdev
>
> On Tue, Jun 23, 2020 at 7:46 AM Paul
On 23.06.2020 19:26, Roger Pau Monné wrote:
> On Tue, Jun 23, 2020 at 06:18:52PM +0200, Jan Beulich wrote:
>> On 23.06.2020 17:56, Roger Pau Monné wrote:
>>> On Tue, Jun 23, 2020 at 05:02:04PM +0200, Jan Beulich wrote:
On 23.06.2020 15:52, Roger Pau Monne wrote:
> XENMEM_acquire_resource
On 23.06.2020 19:32, Roger Pau Monné wrote:
> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote:
>> On 23.06.2020 15:52, Roger Pau Monne wrote:
>>> XENMEM_acquire_resource and it's related structure is currently inside
>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to
On 23.06.2020 19:24, Andrew Cooper wrote:
> On 23/06/2020 09:51, Jan Beulich wrote:
>> On 23.06.2020 03:04, Michał Leszczyński wrote:
>>> - 22 cze 2020 o 18:16, Jan Beulich jbeul...@suse.com napisał(a):
>>>
On 22.06.2020 18:02, Michał Leszczyński wrote:
> - 22 cze 2020 o 17:22,
On 23.06.2020 20:32, osstest service owner wrote:
> flight 151295 xen-4.11-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/151295/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-prev
On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> Export xen_swiotlb for all platforms using xen swiotlb
>
> Use xen_swiotlb to determine when vring should use dma APIs to map the
> ring: when xen_swiotlb is enabled the dma API is required. When it is
> disabled, it is not required.
>
Export xen_swiotlb for all platforms using xen swiotlb
Use xen_swiotlb to determine when vring should use dma APIs to map the
ring: when xen_swiotlb is enabled the dma API is required. When it is
disabled, it is not required.
Signed-off-by: Peng Fan
---
V2:
This is a modified version from
> On 23 Jun 2020, at 21:50, CodeWiz2280 wrote:
>
> Is it possible to passthrough PCI devices to domU on the 32-bit arm
> keystone? Any info is appreciated.
>
> I found some old information online that "gic-v2m" is required. I'm
> not sure if the GIC-400 on the K2E supports "gic_v2m".
On 6/24/20 10:26 AM, Peng Fan wrote:
>> Subject: Re: UEFI support in ARM DomUs
>>
>>
>> On 6/24/20 10:07 AM, Peng Fan wrote:
Subject: Re: UEFI support in ARM DomUs
On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
>> On
> -Original Message-
> From: Xen-devel On Behalf Of Tamas K
> Lengyel
> Sent: 24 June 2020 05:31
> To: Xen-devel
> Subject: [TESTDAY] Test report 4.14-rc3
>
> * Hardware: i9-9900x
>
> * Guest operating systems: Ubuntu 20.04
>
> * Functionality tested: domain create/save/restore,
> Subject: Re: UEFI support in ARM DomUs
>
>
> On 6/24/20 10:07 AM, Peng Fan wrote:
> >> Subject: Re: UEFI support in ARM DomUs
> >>
> >>
> >> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
> >>> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
> On Mon, 22 Jun 2020, Julien Grall wrote:
>
On 6/24/20 10:07 AM, Peng Fan wrote:
>> Subject: Re: UEFI support in ARM DomUs
>>
>>
>> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
>>> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
On Mon, 22 Jun 2020, Julien Grall wrote:
For the first part (__XEN_INTERFACE_VERSION__) I
> Subject: Re: UEFI support in ARM DomUs
>
>
> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
> >
> > On 6/23/20 4:20 AM, Stefano Stabellini wrote:
> >> On Mon, 22 Jun 2020, Julien Grall wrote:
> >> For the first part (__XEN_INTERFACE_VERSION__) I think we can
> >> provide it via
>
On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
>
> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
>> On Mon, 22 Jun 2020, Julien Grall wrote:
>> For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it
>> via
>>
>> CFLAGS or something. This can also be done for
75 matches
Mail list logo
