flight 140072 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140072/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698
Tests which are faili
I've had a tinker with the patch - I don't have a Fedora build system
atm - so I just edited the file on the Dom0 and removed the pyc/pyo
files. Same issue:
pyGRUB version 0.6
┌┐
│ Fedora (5.2.6-200.fc30.x86_64) 30 (Th
flight 140061 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are fail
On Tue, 2019-08-13 at 14:14 -0700, Stefano Stabellini wrote:
> On Tue, 13 Aug 2019, Dario Faggioli wrote:
> >
> > I am attaching an updated debug patch, with an additional printk
> > when
> > we reach the point, within the null scheduler, when the vcpu would
> > wake
> > up (to check whether the p
flight 140068 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140068/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 073f2cede820782e37e31bd6664aa53b79bbade4
baseline version:
ovmf ecc32c90ee4ad557205cb
flight 140081 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140081/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 140048 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140048/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail REGR. vs. 139876
test-armhf-armhf-x
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190813'
into staging
ppc patch queue 2019-08-13 (last minute qemu-4.1 fixes)
Here's a very, very last minute pull request for qemu-4.1. This fixes
two nasty bugs with the XIVE interrupt cont
On 13/08/2019 23:05, Andrew Cooper wrote:
> On 13/08/2019 22:03, Sander Eikelenboom wrote:
>> On 13/08/2019 15:31, Andrew Cooper wrote:
>>> On 13/08/2019 12:51, Sander Eikelenboom wrote:
On 13/08/2019 13:21, Andrew Cooper wrote:
> On 09/08/2019 00:28, Sander Eikelenboom wrote:
>> On 09
On Tue, 13 Aug 2019, 23:39 Dario Faggioli, wrote:
> On Tue, 2019-08-13 at 19:43 +0100, Julien Grall wrote:
> > On 8/13/19 6:34 PM, Dario Faggioli wrote:
> > > On Tue, 2019-08-13 at 17:52 +0100, Julien Grall wrote:
> > > >
> > > So, unless the flag gets cleared again, or something else happens
> >
On Tue, 2019-08-13 at 19:43 +0100, Julien Grall wrote:
> On 8/13/19 6:34 PM, Dario Faggioli wrote:
> > On Tue, 2019-08-13 at 17:52 +0100, Julien Grall wrote:
> > >
> > So, unless the flag gets cleared again, or something else happens
> > that
> > makes the vCPU(s) fail the vcpu_runnable() check in
Hi,
On 8/13/19 7:43 PM, Julien Grall wrote:
>
>
> On 8/13/19 6:34 PM, Dario Faggioli wrote:
>> On Tue, 2019-08-13 at 17:52 +0100, Julien Grall wrote:
>>> Hi Dario,
>>>
>> Hello!
>>
>>> On 8/13/19 4:27 PM, Dario Faggioli wrote:
On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:
>>>
On Tue, 13 Aug 2019, Andrew Cooper wrote:
> On 13/08/2019 22:02, YOUNG, MICHAEL A. wrote:
>> I have been looking at the pygrub code to see if it is possible to cope
>> with grub files with BLSCFG and spotted this minor issue in GrubConf.py
>> where the code intends to replace ${saved_entry} and ${
The binding for the dom0less module does not match Xen implementation.
Any module should contain the compatible "multiboot,module" to be
recognized.
This was clearly an oversight as other examples with Xen code base
provide the compatible "multiboot,module".
So fix the binding and the example ass
On Tue, 13 Aug 2019, Dario Faggioli wrote:
> On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:
> > On Fri, 9 Aug 2019, Dario Faggioli wrote:
> > > Can you help me with this, e.g., by providing some more info and,
> > > if
> > > possible, logs?
> >
> > I am attaching the logs.
> >
> Tha
On 13/08/2019 22:02, YOUNG, MICHAEL A. wrote:
> I have been looking at the pygrub code to see if it is possible to cope
> with grub files with BLSCFG and spotted this minor issue in GrubConf.py
> where the code intends to replace ${saved_entry} and ${next_entry} with 0
> but doesn't succeed.
>
>
On 13/08/2019 22:03, Sander Eikelenboom wrote:
> On 13/08/2019 15:31, Andrew Cooper wrote:
>> On 13/08/2019 12:51, Sander Eikelenboom wrote:
>>> On 13/08/2019 13:21, Andrew Cooper wrote:
On 09/08/2019 00:28, Sander Eikelenboom wrote:
> On 09/08/2019 00:44, Andrew Cooper wrote:
>> On 08
flight 140071 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140071/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
I have been looking at the pygrub code to see if it is possible to cope
with grub files with BLSCFG and spotted this minor issue in GrubConf.py
where the code intends to replace ${saved_entry} and ${next_entry} with 0
but doesn't succeed.
Signed-off-by: Michael Young
From a08eff9b1b881dc61f94
On 13/08/2019 15:31, Andrew Cooper wrote:
> On 13/08/2019 12:51, Sander Eikelenboom wrote:
>> On 13/08/2019 13:21, Andrew Cooper wrote:
>>> On 09/08/2019 00:28, Sander Eikelenboom wrote:
On 09/08/2019 00:44, Andrew Cooper wrote:
> On 08/08/2019 23:34, Sander Eikelenboom wrote:
>> On 08
On 8/13/19 1:43 AM, George Dunlap wrote:
On Aug 13, 2019, at 3:59 AM, Sarah Newman wrote:
On 8/12/19 8:01 AM, Andrew Cooper wrote:
On 12/08/2019 15:53, George Dunlap wrote:
On 8/8/19 10:13 AM, Julien Grall wrote:
Hi Jan,
On 08/08/2019 10:04, Jan Beulich wrote:
On 08.08.2019 10:43, Andre
Hi Roger,
sorry for the delay -- I hope you will understand that I actually had
a good reason. See below:
On Mon, Aug 12, 2019 at 1:57 AM Roger Pau Monné wrote:
>
> Ping?
>
> I know I've posted this quite recently, but have you been able to test
> the two proposed patches?
>
> ie: the one here a
On Tue, Aug 13, 2019 at 11:53:52AM +0100, Andrew Cooper wrote:
> This functionality is obsolete. It was introduced by c/s 41296317a31 into
> Xend, but was never exposed in libxl.
>
> Nothing limits this to PV guests, but it makes no sense for HVM guests.
>
> Looking through the XenServer templat
On Tue, Aug 13, 2019 at 11:53:51AM +0100, Andrew Cooper wrote:
> This functionality is obsolete. It was introduced by c/s 39407bed9c0 into
> Xend, but never exposed in libxl.
>
> While not explicitly limited to PV guests, this is PV-only by virtue of its
> position in the pagefault handler.
>
>
On 8/13/19 6:34 PM, Dario Faggioli wrote:
On Tue, 2019-08-13 at 17:52 +0100, Julien Grall wrote:
Hi Dario,
Hello!
On 8/13/19 4:27 PM, Dario Faggioli wrote:
On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:
In my (x86 and "dom0full") testbox, this seems to come from
domain_un
dtb_load() can be called by other domain than dom0. To avoid confusion
in the log, print the correct domain.
Signed-off-by: Julien Grall
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_buil
flight 140038 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140038/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-xl-
On 24/01/2019 22:10, Andrew Cooper wrote:
> On 24/01/2019 21:42, Julien Grall wrote:
>> Hi Andrew,
>>
>> On 12/21/18 1:46 PM, Andrew Cooper wrote:
>>> All of this code lives inside CONFIG_PV which means gfn == mfn, and the
>>> fill_ro_mpt() calls clearly show that the value is used untranslated.
>>
flight 140040 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140040/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698
Tests which did not s
On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
> Instead of having a full blown scheduler running for the free cpus
> add a very minimalistic scheduler for that purpose only ever
> scheduling
> the related idle vcpu. This has the big advantage of not needing any
> per-cpu, per-domain or pe
On Tue, 2019-08-13 at 17:52 +0100, Julien Grall wrote:
> Hi Dario,
>
Hello!
> On 8/13/19 4:27 PM, Dario Faggioli wrote:
> > On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:
> > >
> > In my (x86 and "dom0full") testbox, this seems to come from
> > domain_unpause_by_systemcontroller(do
Hi,
On 8/12/19 11:28 PM, Stefano Stabellini wrote:
Change the signature of process_memory_node to match
device_tree_node_func. Thanks to this change, the next patch will be
able to use device_tree_for_each_node to call process_memory_node on all
the children of a provided node.
Return error if
Hi,
On 8/13/19 5:05 PM, Oleksandr wrote:
On 13.08.19 16:49, Julien Grall wrote:
On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
Hmm, I was thinking how to end up with only one callback re-used
(add_device), really didn't want to add a new one (of_xlate). But, I
didn't take into the account tha
Hi,
On 8/12/19 11:28 PM, Stefano Stabellini wrote:
Add a new parameter to device_tree_for_each_node: node, the node to
start the search from. Passing 0 triggers the old behavior.
Set min_depth to depth of the current node + 1 and replace the for
loop with a do/while loop to avoid scanning sibli
On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
> Today a cpu which is removed from the system is taken directly from
> Pool0 to the offline state. This will conflict with the new idle
> scheduler, so remove it from Pool0 first. Additionally accept
> removing
> a free cpu instead of requiri
Hi Dario,
On 8/13/19 4:27 PM, Dario Faggioli wrote:
On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:
On Fri, 9 Aug 2019, Dario Faggioli wrote:
Can you help me with this, e.g., by providing some more info and,
if
possible, logs?
I am attaching the logs.
Thanks!
Interestingly,
flight 140047 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140047/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ecc32c90ee4ad557205cb2725619a3cc2f45ebd0
baseline version:
ovmf a0792697bc54e5472e212
On Tue, Aug 13, 2019 at 04:47:23PM +0100, Andrew Cooper wrote:
> Error between user and terminal. :)
>
> I'd sync'd xl and libxl.so, but not libxlu.so
I actually made the same mistake first time I tried.
> Ok, so that is working now. I think 'cmdline+=" dom0=pvh
> dom0-iommu=none"' is slightly
On 13.08.19 16:40, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
One more comment :).
On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
+int iommu_fwspec_init(struct device *dev, struct device *iommu_dev)
+{
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+ if ( fwspec )
On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
> With core or socket scheduling we need to know the number of siblings
> per scheduling unit before we can setup the scheduler properly. In
> order to prepare that do cpupool0 population only after all cpus are
> up.
>
> With that in place t
On 13.08.19 18:28, Julien Grall wrote:
Hi,
Hi Julien
On 8/13/19 4:17 PM, Oleksandr wrote:
On 13.08.19 15:39, Julien Grall wrote:
xfree is able to deal with NULL pointer, so the check is not necessary.
Yes, the reason I left this check is to not perform an extra
operation (dev_iommu_
On 13.08.19 16:49, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds new iommu_add_dt_device API for adding DT device
to the IOMMU using generic IOMMU DT binding [1] and previously
added "iommu_fwspec" s
On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
> These three patches have been carved out from my core scheduling
> series
> as they are sufficiently independent to be applied even without the
> big
> series.
>
> Without this little series there are messages like the following to
> be
> s
On 13/08/2019 16:30, Anthony PERARD wrote:
> On Tue, Aug 13, 2019 at 04:06:33PM +0100, Andrew Cooper wrote:
>> On 13/08/2019 15:48, Anthony PERARD wrote:
>>> Handle += of both strings and lists.
>>>
>>> If += is used for config options expected to be numbers, then a
>>> warning is printed and the c
On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:
> On Fri, 9 Aug 2019, Dario Faggioli wrote:
> > Can you help me with this, e.g., by providing some more info and,
> > if
> > possible, logs?
>
> I am attaching the logs.
>
Thanks!
> Interestingly, I get a bunch of:
>
> (XEN) *** LOADI
Julien Grall writes:
> Hi,
>
> On 8/13/19 4:14 PM, Volodymyr Babchuk wrote:
>> Julien Grall writes:
>>> On 8/13/19 3:23 PM, Volodymyr Babchuk wrote:
Stefano Stabellini writes:
>{
>device_tree_get_reg(&cell, address_cells, size_cells, &start,
> &size);
>>
On Tue, Aug 13, 2019 at 04:06:33PM +0100, Andrew Cooper wrote:
> On 13/08/2019 15:48, Anthony PERARD wrote:
> > Handle += of both strings and lists.
> >
> > If += is used for config options expected to be numbers, then a
> > warning is printed and the config option ignored (because xl ignores
> > c
Hi,
On 8/13/19 4:17 PM, Oleksandr wrote:
On 13.08.19 15:39, Julien Grall wrote:
xfree is able to deal with NULL pointer, so the check is not necessary.
Yes, the reason I left this check is to not perform an extra operation
(dev_iommu_fwspec_set). Shall I drop this check anyway?
I can't s
On 13.08.19 15:39, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to have some abstract way to add new device to the IOMMU
based on the generic IOMMU DT binding [1] which can be used for
both DT (right now)
Hi,
On 8/13/19 4:14 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
On 8/13/19 3:23 PM, Volodymyr Babchuk wrote:
Stefano Stabellini writes:
{
device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
if ( !size )
continue;
-bo
Hi Julien,
Julien Grall writes:
> Hi,
>
> On 8/13/19 3:23 PM, Volodymyr Babchuk wrote:
>>
>> Stefano Stabellini writes:
>>
>>> As we parse the device tree in Xen, keep track of the reserved-memory
>>> regions as they need special treatment (follow-up patches will make use
>>> of the stored infor
On 13/08/2019 15:48, Anthony PERARD wrote:
> Handle += of both strings and lists.
>
> If += is used for config options expected to be numbers, then a
> warning is printed and the config option ignored (because xl ignores
> config options with errors).
>
> This is to be used for development purposes
Hi,
On 8/13/19 3:34 PM, Volodymyr Babchuk wrote:
Stefano Stabellini writes:
Don't allow reserved-memory regions to be remapped into any unprivileged
guests, until reserved-memory regions are properly supported in Xen. For
now, do not call iomem_permit_access on them, because giving
iomem_perm
On Thu, 2019-08-08 at 17:07 +0300, Andrii Anisov wrote:
> On 06.08.19 16:09, Andrii Anisov wrote:
> > p.p.s. I'm looking through freertos as well to get wider look on
> > the available approaches
>
> OK, basically Free-RTOS does not account the IRQ time separately. Yet
> its scheduling is very imp
Handle += of both strings and lists.
If += is used for config options expected to be numbers, then a
warning is printed and the config option ignored (because xl ignores
config options with errors).
This is to be used for development purposes, where modifying config
option can be done on the `xl
Hi,
On 8/13/19 3:28 PM, Volodymyr Babchuk wrote:
Stefano Stabellini writes:
Improve early_print_info to also print the banks saved in
bootinfo.reserved_mem. Print them right after RESVD, increasing the same
index.
Since we are at it, also switch the existing RESVD print to use unsigned
int.
Hi,
On 8/13/19 3:23 PM, Volodymyr Babchuk wrote:
Stefano Stabellini writes:
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Reuse process_memory_node to add reserved-memo
Stefano Stabellini writes:
> Don't allow reserved-memory regions to be remapped into any unprivileged
> guests, until reserved-memory regions are properly supported in Xen. For
> now, do not call iomem_permit_access on them, because giving
> iomem_permit_access to dom0 means that the toolstack wi
Perfect: I updated this also in the google doc. I will leave the review open
for a week or two (we do have summer holidays after all) and let people
comment. I can then send a proper proposal, followed by a vote
Lars
On 12/08/2019, 15:35, "George Dunlap" wrote:
On 8/12/19 3:27 PM, Lars Ku
Stefano Stabellini writes:
> Improve early_print_info to also print the banks saved in
> bootinfo.reserved_mem. Print them right after RESVD, increasing the same
> index.
>
> Since we are at it, also switch the existing RESVD print to use unsigned
> int.
>
> Signed-off-by: Stefano Stabellini
Rev
Stefano Stabellini writes:
> As we parse the device tree in Xen, keep track of the reserved-memory
> regions as they need special treatment (follow-up patches will make use
> of the stored information.)
>
> Reuse process_memory_node to add reserved-memory regions to the
> bootinfo.reserved_mem ar
When compiling xenstat with -Werror, Clang complains:
src/xenstat.c:134:34: error: unused function 'parse'
[-Werror,-Wunused-function]
static inline unsigned long long parse(char *s, char *match)
^
1 error generated.
Drop the function. It really is unuse
Hi Stefano,
Stefano Stabellini writes:
> Change the signature of process_memory_node to match
> device_tree_node_func. Thanks to this change, the next patch will be
> able to use device_tree_for_each_node to call process_memory_node on all
> the children of a provided node.
>
> Return error if t
Building with GCC 8.3 on Buster identifies:
src/xenstat_linux.c: In function 'xenstat_collect_networks':
src/xenstat_linux.c:307:32: warning: 'snprintf' output may be truncated before
the last format character [-Wformat-truncation=]
snprintf(devNoBridge, 16, "p%s", devBridge);
Hi Oleksandr,
On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds new iommu_add_dt_device API for adding DT device
to the IOMMU using generic IOMMU DT binding [1] and previously
added "iommu_fwspec" support.
New function parses the DT binding, prepares "d
Hi Stefano,
Stefano Stabellini writes:
> Add a new parameter to device_tree_for_each_node: node, the node to
> start the search from. Passing 0 triggers the old behavior.
>
> Set min_depth to depth of the current node + 1 and replace the for
> loop with a do/while loop to avoid scanning siblings
Hi Oleksandr,
One more comment :).
On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
+int iommu_fwspec_init(struct device *dev, struct device *iommu_dev)
+{
+struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+if ( fwspec )
I would actually check the iommu_dev passed in parameter
On 13/08/2019 12:51, Sander Eikelenboom wrote:
> On 13/08/2019 13:21, Andrew Cooper wrote:
>> On 09/08/2019 00:28, Sander Eikelenboom wrote:
>>> On 09/08/2019 00:44, Andrew Cooper wrote:
On 08/08/2019 23:34, Sander Eikelenboom wrote:
> On 08/08/2019 23:14, Andrew Cooper wrote:
>> On 08
Hi Oleksandr,
On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to have some abstract way to add new device to the IOMMU
based on the generic IOMMU DT binding [1] which can be used for
both DT (right now) and ACPI (in future).
For that reason we can borrow the
On 12.08.19 22:46, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 8/12/19 1:01 PM, Oleksandr wrote:
On 12.08.19 14:11, Julien Grall wrote:
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
t
flight 140017 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140017/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are fail
Clang-3.5 from Debian Jessie fails with:
smpboot.c:829:29: error: statement expression not allowed at file scope
BUILD_BUG_ON(sizeof(this_cpu(tss_page)) != PAGE_SIZE);
^
/local/xen.git/xen/include/asm/percpu.h:14:7: note: expanded from macro
't
When the Xen PVH entry point has been used, hvmloader hasn't run and
hasn't prepared an E820 table. The only way left to get an E820 table
is to ask Xen via an hypercall. We keep the result cached to avoid
making a second hypercall which would give the same result.
Ref: https://bugzilla.tianocore
The XenPlatformPei needs to make hypercalls, but the XenHypercallLib was
initialised before the HyperPage was ready. Now that XenPlatformPei has
initialised the HyperPage, reinitialise the XenHypercallLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Revi
The informations to make a XENMEM_memory_map hypercall is copied over
from the public header of the Xen Project, with the type name modified
to build on OVMF.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v3:
- e
XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
Grant Tables.
The call is only done if it is necessary, we simply detect if the
guest is PVH, as in this case there is currently no PCI bus, and no
PCI Xen platform device which would start the XenIoPciDxe and allocate
the space f
PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
implementation. It will also be used by XenTimerDxe. Override
PcdFSBClock to match Xen vLAPIC timer frequency.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v
"OvmfPkg/8254TimerDxe" is replaced with a Xen-specific
EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
8259InterruptControllerDxe as it is not used anymore.
This Timer uses the local APIC timer as time source as it can work on
both a Xen PVH guest and an HVM one.
Based on the "OvmfPkg/8254Tim
When running as a Xen PVH guest, there is no CMOS to read the memory
size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
work without CMOS by reading the e820 table.
Rework XenPublishRamRegions to also care for the reserved and ACPI
entry in the e820 table. The region that was add
Check if there's a start of the day struct provided to PVH guest, save
the ACPI RSDP address for later.
This patch import import arch-x86/hvm/start_info.h from xen.git.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
Allow to use Xen hypercalls earlier, during the PEIM stage, but
XenHypercallLibInit() must be called once the XenInfo HOB is created
with the HyperPage setup.
Change the return value of XenHypercallLibInit so failure can be
detected when the call shouldn't fail, but still have the constructor
alwa
EFI_XEN_OVMF_INFO is only useful to retrieve the E820 table. The
mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
retrieve the E820 table.
Also remove the unused pointer from the XenInfo HOB as that information
is only useful in the XenPlatformPei.
Ref: https://bugzilla.tia
When running in a Xen PVH guest, there's nothing to do in
PciAcpiInitialization() because there isn't any PCI bus. When the Host
Bridge DID isn't recognised, simply continue. (The value of
PcdOvmfHostBridgePciDevId would be 0 because it isn't set.)
Ref: https://bugzilla.tianocore.org/show_bug.cgi?
Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used
from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use
RealTimeClockRuntimeDxe from EmbeddedPkg"
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Not
Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow
the same value to be used in a different module.
The reason for the number of page to be 4 doesn't exist anymore, so
simply remove the comment.
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v5:
XenPvhDetected() can be used to figure out if OVMF has started via the
Xen PVH entry point.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v5:
- in XenPvhDetected, check mXenInfo.HyperPages instead of .VersionMajo
We are going to replace XenDetected() implementation in
PlatformBootManagerLib by the one in XenPlatformLib.
PlatformBootManagerLib's implementation does cache the result of
GetFirstGuidHob(), so we do something similar in XenPlatformLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Si
This new XenHvmloaderDetected() return true if the hvmloader firmware
has runned before OVMF.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v3:
- Added one sentence in the commit message.
OvmfPkg/XenPlatformPei
When the device ID of the host bridge is unknown, check if we are
running as a PVH guest as there is no PCI bus in that case.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v3:
- Remove use of XEN_PVH_PCI_HOST_BRI
On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemented via SerialDxe.
That is a simple console implementation that can work on both PVH
guest and HVM guests, even if it is rarely going to be used on HVM.
H
We are going to need to make an hypercall in order to retreive the E820
table from the hypervisor before been able to setup the memory.
Calling XenConnect earlier will allow to setup the XenHypercallLib
earlier to allow to make hypercalls.
While here, add some comments in XenConnect().
Ref: http
This patch replace the XenDetected() function by the one in
XenPlatformLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v4:
- removed gEfiXenInfoGuid from Guids list.
v3:
- new patch, splited fr
The purpose of XenPlatformLib is to regroup the few functions that are
used in several places to detect if Xen is detected, and to get the
XenInfo HOB.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v4:
- fix t
Linux panic if the VGA region isn't reserved.
When Linux is booted on EFI system, it expects the memory at 0xa to
_not_ be conventional memory. Otherwise a variable isn't initialised
properly and Linux panic when a virtual console/terminal is asked to be
created.
See for more detail:
https://
If the firmware have been started via the Xen PVH entry point, a RSDP
pointer would have been provided. Use it.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v4:
- fix coding style
v3:
- patch spl
Use the already checked pointer mXenHvmloaderInfo to retrieve the E820
table produced by hvmloader.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
OvmfPkg/XenPlatformPei/Xen.c | 18 +-
1 file changed, 9 insertion
Replace the XenDetected() implementation by the one from
XenPlatformLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v4:
- removed gEfiXenInfoGuid from Guids list and the associated include of
Guid/Xen
A Xen PVH guest doesn't have a RTC that OVMF would expect, so
PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
firmware from finish to boot. To prevent that, we will use
XenRealTimeClockLib which simply always return the same time.
This will work on both Xen PVH and HVM guests.
Ref:
On 13/08/2019 13:21, Andrew Cooper wrote:
> On 09/08/2019 00:28, Sander Eikelenboom wrote:
>> On 09/08/2019 00:44, Andrew Cooper wrote:
>>> On 08/08/2019 23:34, Sander Eikelenboom wrote:
On 08/08/2019 23:14, Andrew Cooper wrote:
> On 08/08/2019 22:16, Sander Eikelenboom wrote:
>> On 08
Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some
of QEMU specific initialization, Xen does not support QemuFwCfg.
This new module will be adjusted to accommodate Xen PVH.
fw_cfg dependents that have been removed, which are dynamically skipped
when running PlatformPei on Xen:
-
1 - 100 of 124 matches
Mail list logo
