>>> On 21.07.15 at 02:57, wrote:
>> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew
> Cooper
>> Sent: Monday, July 20, 2015 4:21 PM
>>
>> On 20/07/2015 02:28, Tian, Kevin wrote:
>> >> From: Ting-Wei Lan [mailto:lant...@gmail.com]
>> >> Sent: Saturday, July 18, 2015 3:06
On Mon, Jun 01, Jan Beulich wrote:
> >>> On 01.06.15 at 15:56, wrote:
> > On Mon, 2015-06-01 at 14:50 +0100, Jan Beulich wrote:
> >> It's being removed in Linux 4.1.
> >>
> >> Signed-off-by: Jan Beulich
> >
> > Not sure who should, but:
>
> I guess no-one really needs to for that old code. Bu
>>> On 21.07.15 at 08:32, wrote:
> On Mon, Jul 20, Wei Liu wrote:
>
>> On Mon, Jul 20, 2015 at 11:16:34AM +0200, Olaf Hering wrote:
>> > On Mon, Jul 20, Jan Beulich wrote:
>> >
>> > > >>> On 19.07.15 at 11:33, wrote:
>> > > > [ 198s] block-log.c:549:23: error: array subscript is above array
>
But d_config is a libxl_domain_config which is supplied by libxl's
caller. It might contain some rdms.
I guess this line make you or other guys confused so lets delete this
line directly.
I don't think I am very confused.
And if you still worry about something, I can add assert() at the
beg
> I think the confusion here is that the d_config->rdms array (which
num_rdms is the length of) is in the public API (because it is in
libxl_types.idl) but is apparently only being used in this series as an
internal state for the domain build process (i.e. xl doesn't ever add
anything to the arr
On Mon, Jul 20, 2015 at 5:35 PM, Daniel Kiper wrote:
> malloc_in_range() should not use memory region if its starta is smaller
> than size. Otherwise target wraps around and points to region which is
> usually not a RAM, e.g.:
>
> loader/multiboot.c:93: segment 0: paddr=0x80, memsz=0x3f80,
I hope the following can address all comments below:
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 2f8e590..a4bd2a1 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -407,7 +407,7 @@ int libxl__domain_build(libxl__gc *gc,
switch (info-
>>> On 21.07.15 at 07:46, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>Sent: Sunday, July 19, 2015 11:53 PM
> On 18.07.15 at 00:32, wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, July 16, 2015 2:34 AM
>>> On 16.07.15 at 11:16, wrote:
>>
On Mon, Jul 20, Wei Liu wrote:
> On Mon, Jul 20, 2015 at 11:16:34AM +0200, Olaf Hering wrote:
> > On Mon, Jul 20, Jan Beulich wrote:
> >
> > > >>> On 19.07.15 at 11:33, wrote:
> > > > [ 198s] block-log.c:549:23: error: array subscript is above array
> > > > bounds [-Werror=array-bounds]
> > >
>>> On 21.07.15 at 07:04, wrote:
> Are you ok if this mechanical change doesn't go into our 4.6 series?
Reluctantly - yes.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 21.07.15 at 02:53, wrote:
>> > Okay, I regenerate this patch online. And I just hope its good to be
>>> acked here:
>>
>> Provided it also works,
>> Reviewed-by: Jan Beulich
>
> Why is this marked as Acked-by this time? The same question is raised to
> another hvmloader patch as well.
>
Hello All,
You can find the relevant thread that outlines the issue at [1].
In short, the issue is as follows. On the TI DRA72 chip, there is a
piece of hardware called the IRQ crossbar. Due to the large number of
peripheral devices, not all devices can fit onto the SPI lines on the
G
>From: Jan Beulich [mailto:jbeul...@suse.com]
>Sent: Monday, July 20, 2015 12:12 AM
>
On 17.07.15 at 21:43, wrote:
>> We are working on addressing review comments in this order (and you
>> will see this pattern in our review responses):
>>
>> * Category 1 - Address review comments that affect
flight 59770 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59770/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 13 guest-saverestore fail REGR. vs. 59254
test-amd64-i386-xl
>From: Jan Beulich [mailto:jbeul...@suse.com]
>Sent: Sunday, July 19, 2015 11:22 PM
>
On 17.07.15 at 23:08, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>>Sent: Thursday, July 16, 2015 2:39 AM
>>>
>> On 16.07.15 at 11:20, wrote:
> From: Jan Beulich [mailto:jbeul...@suse.c
>From: Jan Beulich [mailto:jbeul...@suse.com]
>Sent: Sunday, July 19, 2015 11:53 PM
>
On 18.07.15 at 00:32, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>>Sent: Thursday, July 16, 2015 2:34 AM
>>>
>> On 16.07.15 at 11:16, wrote:
> From: Jan Beulich [mailto:jbeul...@suse.c
On 07/21/2015 02:58 AM, Ed White wrote:
> From: Tamas K Lengyel
>
> Working altp2m test-case. Extended the test tool to support singlestepping
> to better highlight the core feature of altp2m view switching.
>
> Signed-off-by: Tamas K Lengyel
> Signed-off-by: Ed White
>
> Reviewed-by: Razvan
>From: Jan Beulich [mailto:jbeul...@suse.com]
>Sent: Sunday, July 19, 2015 11:20 PM
>
On 18.07.15 at 00:36, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>>Sent: Thursday, July 16, 2015 2:08 AM
>>>
>> On 16.07.15 at 10:57, wrote:
> From: Jan Beulich [mailto:jbeul...@suse.c
>From: Jan Beulich [mailto:jbeul...@suse.com]
>Sent: Sunday, July 19, 2015 11:18 PM
>
On 18.07.15 at 00:39, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>>Sent: Thursday, July 16, 2015 2:02 AM
>>>
>> On 16.07.15 at 10:48, wrote:
> From: Jan Beulich [mailto:jbeul...@suse.c
flight 59769 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59769/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 12 guest-saverestore fail REGR. vs. 59059
test-amd64-i386-xl-
Hi MM maintainers,
this patch is the last requiring an ack for the series to go in.
Could you please comment?
Juergen
On 07/17/2015 06:51 AM, Juergen Gross wrote:
During early boot as Xen pv domain the kernel needs to map some page
tables supplied by the hypervisor read only. This is needed t
This BUG_ON() will be triggered when previous purge work haven't finished.
It's reasonable under pretty extreme load and should not panic the system.
Signed-off-by: Bob Liu
---
drivers/block/xen-blkback/blkback.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/b
This BUG_ON() in blkif_free() is incorrect, because indirect page can be added
to list info->indirect_pages in blkif_completion() no matter feature_persistent
is true or false.
Signed-off-by: Bob Liu
---
drivers/block/xen-blkfront.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/b
There is a bug when migrate from !feature-persistent host to feature-persistent
host, because domU still think new host/backend don't support persistent.
Dmesg like:
backed has not unmapped grant: 839
backed has not unmapped grant: 773
backed has not unmapped grant: 773
backed has not unmapped gran
flight 59766 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59766/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 58581
Tests which are failin
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, July 20, 2015 8:24 PM
>
> >>> On 20.07.15 at 14:12, wrote:
> > On 17/07/15 20:05, Ting-Wei Lan wrote:
> >> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
> >> devices, It is possible to encounter graphics iss
> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew Cooper
> Sent: Monday, July 20, 2015 4:21 PM
>
> On 20/07/2015 02:28, Tian, Kevin wrote:
> >> From: Ting-Wei Lan [mailto:lant...@gmail.com]
> >> Sent: Saturday, July 18, 2015 3:06 AM
> >>
> >> When using Linux >= 3.19 (commi
Okay, I regenerate this patch online. And I just hope its good to be
acked here:
Provided it also works,
Reviewed-by: Jan Beulich
Why is this marked as Acked-by this time? The same question is raised to
another hvmloader patch as well.
This really makes me confused since you're the key ma
On Mon, Jul 20, 2015 at 4:57 PM, Ed White wrote:
> In preparation for selectively enabling #VE in a later patch, set
> suppress #VE on all EPTE's.
>
> Suppress #VE should always be the default condition for two reasons:
> it is generally not safe to deliver #VE into a guest unless that guest
> has
From: Ravi Sahita
Signed-off-by: Ravi Sahita
Acked-by: Daniel De Graaf
---
tools/flask/policy/policy/modules/xen/xen.if | 4 ++--
xen/arch/x86/hvm/hvm.c | 6 ++
xen/include/xsm/dummy.h | 12
xen/include/xsm/xsm.h
From: Tamas K Lengyel
Wrappers to issue altp2m hvmops.
Signed-off-by: Tamas K Lengyel
Signed-off-by: Ravi Sahita
Acked-by: Ian Campbell
---
tools/libxc/Makefile | 1 +
tools/libxc/include/xenctrl.h | 22
tools/libxc/xc_altp2m.c | 248 ++
The altp2mhvm and nestedhvm parameters are mutually
exclusive and cannot be set together.
Signed-off-by: Ed White
Reviewed-by: Andrew Cooper
Acked-by: Wei Liu
---
docs/man/xl.cfg.pod.5 | 12
tools/libxl/libxl.h | 6 ++
tools/libxl/libxl_create.c |
Add the remaining routines required to support enabling the alternate
p2m functionality.
Signed-off-by: Ed White
Reviewed-by: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 58 +-
xen/arch/x86/mm/hap/Makefile | 1 +
xen/arch/x86/mm/hap/altp2m_hap.c | 98 ++
xen/arch/x
From: Tamas K Lengyel
Working altp2m test-case. Extended the test tool to support singlestepping
to better highlight the core feature of altp2m view switching.
Signed-off-by: Tamas K Lengyel
Signed-off-by: Ed White
Reviewed-by: Razvan Cojocaru
Acked-by: Wei Liu
---
tools/tests/xen-access/x
Signed-off-by: Ed White
---
xen/arch/x86/hvm/hvm.c | 139
xen/include/public/hvm/hvm_op.h | 89 +
2 files changed, 228 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 38cf0c6..15973b4 1006
From: George Dunlap
The existing ept_set_entry() and ept_get_entry() routines are extended
to optionally set/get suppress_ve. Passing -1 will set suppress_ve on
new p2m entries, or retain suppress_ve flag on existing entries.
Signed-off-by: George Dunlap
Signed-off-by: Ravi Sahita
Reviewed-b
Add a flag to indicate that a memory event occurred in an alternate p2m
and a field containing the p2m index. Allow any event response to switch
to a different alternate p2m using the same flag and field.
Modify p2m_mem_access_check() to handle alternate p2m's.
Signed-off-by: Ed White
Acked-by:
From: Ravi Sahita
Signed-off-by: Ravi Sahita
---
xen/arch/x86/hvm/emulate.c | 18 +++--
xen/arch/x86/hvm/vmx/vmx.c | 36 ++
xen/arch/x86/x86_emulate/x86_emulate.c | 19 --
xen/arch/x86/x86_emulate/x86_emulate.h
Implement and hook up the code to enable VMX support of VMFUNC and #VE.
VMFUNC leaf 0 (EPTP switching) emulation is added in a later patch.
Signed-off-by: Ed White
Reviewed-by: Andrew Cooper
Acked-by: Jun Nakajima
---
xen/arch/x86/hvm/vmx/vmx.c | 139 +
In preparation for selectively enabling #VE in a later patch, set
suppress #VE on all EPTE's.
Suppress #VE should always be the default condition for two reasons:
it is generally not safe to deliver #VE into a guest unless that guest
has been modified to receive it; and even then for most EPT viol
Currently, neither is enabled globally but may be enabled on a per-VCPU
basis by the altp2m code.
Remove the check for EPTE bit 63 == zero in ept_split_super_page(), as
that bit is now hardware-defined.
Signed-off-by: Ed White
Reviewed-by: Andrew Cooper
Acked-by: George Dunlap
Acked-by: Jun N
Add the basic data structures needed to support alternate p2m's and
the functions to initialise them and tear them down.
Although Intel hardware can handle 512 EPTP's per hardware thread
concurrently, only 10 per domain are supported in this patch for
performance reasons.
The iterator in hap_enab
As implemented here, only supported on platforms with VMX HAP.
By default this functionality is force-disabled, it can be enabled
by specifying altp2m=1 on the Xen command line.
Signed-off-by: Ed White
Reviewed-by: Andrew Cooper
---
docs/misc/xen-command-line.markdown | 7 +++
xen/arch/x8
This set of patches adds support to hvm domains for EPTP switching by creating
multiple copies of the host p2m (currently limited to 10 copies).
The primary use of this capability is expected to be in scenarios where access
to memory needs to be monitored and/or restricted below the level at which
From: Andrew Cooper
For use on codepaths which would need to use domain_pause() but might be in
the target domain's context. In the case that the target domain is in
context, all other vcpus are paused.
Signed-off-by: Andrew Cooper
---
xen/common/domain.c | 28
flight 59768 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59768/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 11 guest-start fail REGR. vs. 58842
Regressions which are reg
flight 59767 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59767/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail
baseline untested
test-amd64-i
Thanks, Ian. I tried that, and it does seem to work (everything boots, I can
still bring up VMs, and I see an extra 16MB of free memory). The patch I came
up with follows (it would be nice to share code between create_32mb_mappings()
and create_2mb_mappings(), but the setting of the contig bit i
>>> On 20.07.15 at 16:35, wrote:
> Looks just a little bit should be changed so I also paste this new
> online to try winning your Acked here,
Just like the other one, provided it also works,
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-d
>>> On 20.07.15 at 16:32, wrote:
> On 2015/7/20 22:16, Jan Beulich wrote:
> On 20.07.15 at 16:10, wrote:
>>> Hmm... although I suppose that doesn't catch the possibility of a memory
>>> range crossing the 4G boundary.
>>
>> I think we can safely ignore that - both real and virtual hardware ha
htobe*() and be*toh() don't exist there. While replacing the 32-bit
ones with hton() and ntoh() would be possible, there wouldn't be an
obvious replacement for the 64-bit ones. Hence just take what current
glibc (2.21) has (assuming __bswap_*() exists, which it does back to
at least 2.4 according t
>>> On 20.07.15 at 16:12, wrote:
> On 20/07/15 14:55, Jan Beulich wrote:
> On 20.07.15 at 14:34, wrote:
>>> On 20/07/15 13:24, Jan Beulich wrote:
>>> On 20.07.15 at 14:12, wrote:
> On 17/07/15 20:05, Ting-Wei Lan wrote:
>> When using Linux >= 3.19 (commit 47591df) as dom0 on some
... to hook up pci_conf_write_intercept() even for Dom0 not using
method 1 accesses for the base part of PCI device config space.
Signed-off-by: Jan Beulich
---
Not entirely sure whether the complicated logging logic in x86/mm.c is
actually worth it.
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm
On 09/07/15 21:42, Julien Grall wrote:
> Average betwen 10 iperf :
>
> DOM0 Guest Result
>
> 4KB-mod 64KB3.176 Gbits/sec
> 4KB-mod 4KB-mod 3.245 Gbits/sec
> 4KB-mod 4KB 3.258 Gbits/sec
> 4KB 4KB 3.292 Gbits/sec
> 4KB 4KB-mod
Hi,
On 09/07/15 21:42, Julien Grall wrote:
> +static void xennet_make_one_txreq(unsigned long mfn, unsigned int offset,
> + unsigned int *len, void *data)
> +{
> + struct xennet_gnttab_make_txreq *info = data;
> +
> + info->tx->flags |= XEN_NETTXF_more_data;
>
Forgot to attach the graph referred to (or it is not showing up in the archives)
Lars
]
> On 20 Jul 2015, at 07:02, Lars Kurth wrote:
>
> Hi all,
>
> I have been travelling on Friday and wanted to appeal for calm on this
> particular issue. Let's try and focus on making as much progress as we
On Mon, 2015-07-20 at 16:39 +0100, Wei Liu wrote:
> The subject of this mail is very terse. I guess you meant
>
> ts-debian-hvm-install: *use* di_installcmdline_core
>
> ?
I did, I would even have sworn I typed that (or something very like it).
I may have driven vi wrongly at some point during
The subject of this mail is very terse. I guess you meant
ts-debian-hvm-install: *use* di_installcmdline_core
?
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Mon, 2015-07-20 at 16:24 +0100, Ian Jackson wrote:
> Chen, Tiejun writes ("Re: [v10][PATCH 11/16] tools/libxl: detect and
> avoid conflicts with RDM"):
> > [Ian Jackson:]
> > > The domain configuration specified to libxl might contain some rdms.
> > > Then num_rdms in the incoming config would b
On Mon, 2015-07-20 at 16:07 +0100, Anthony PERARD wrote:
> > > I have not done it, but we could have some smoke test before
> > > Tempest where osstest tryied to start a guest.
> >
> > A test can have a dependency on a build job, but I'm not sure about
> > another test, but that would seem gener
On Thu, Jul 16, Jim Fehlig wrote:
> @@ -448,6 +438,8 @@ libxlDomainMigrationPrepare(virConnectPtr dconn,
> virObjectUnref(socks[i]);
> }
> VIR_FREE(socks);
> +virObjectUnref(args);
This is now below the 'error' label, so args has to be initialized.
[ 149s] libxl/libxl_mig
Anthony PERARD writes ("Re: [PATCH OSSTEST 0/4] Have OpenStack tested on top of
xen's master and libvirt's master."):
> Yes, I think your description of raisin would match the description of
> devstack, the $rootthing.
> So, devstack will clone master of every other tree by default. But we
> can s
Chen, Tiejun writes ("Re: [v10][PATCH 11/16] tools/libxl: detect and
avoid conflicts with RDM"):
> [Ian Jackson:]
> > The domain configuration specified to libxl might contain some rdms.
> > Then num_rdms in the incoming config would be nonzero.
>
> We never set d_config->num_rdms/d_config->rdms b
This is primarily to get DEBIAN_FRONTEND=test, for easier to read
logging.
Previously the command line consisted of the console and
preseed/file=/preseed.cfg. After this it is more complex.
The preseed file uses file= which is an alias for preseed/file. Extra
options are given including DEBIAN_FR
The main one is the middle one which would have made
http://logs.test-lab.xenproject.org/osstest/logs/59681/test-amd64-i386-xl-qemuu-debianhvm-amd64/info.html
a lot easier to read due to the DEBIAN_FRONTEND=text.
___
Xen-devel mailing list
Xen-devel@l
I don't think there is any point in these since 60b6d20b0fd2
"ts-debian-hvm-install: Arrange for installed guest to use a serial
console" and they represent an unexplained difference between the
islinux and grub cases.
Signed-off-by: Ian Campbell
---
ts-debian-hvm-install | 4 ++--
1 file change
The current arrangement is a bit odd, I'm not sure why it would be
that way and it results in a huge list of files in the middle of the
log which is rather boring to scroll through.
Signed-off-by: Ian Campbell
---
ts-debian-hvm-install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Fri, Jul 17, 2015 at 05:22:10PM +0100, Ian Campbell wrote:
> On Thu, 2015-07-16 at 12:18 +0100, Anthony PERARD wrote:
>
> > I've introduce an extra Osstest::Toolstack which help to install extra
> > package,
>
> I've commented on this.
>
> > and use ballonning for Dom0, 500MB for Dom0 is def
+int libxl__domain_device_construct_rdm(libxl__gc *gc,
+ libxl_domain_config *d_config,
+ uint64_t rdm_mem_boundary,
+ struct xc_hvm_build_args *args)
+{
...
+/* Query all RDM en
Misc fixes for FreeBSD that affect libxl and the recently added
xendriverdomain rc.d script.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
hotplugpath.sh by default is located in /usr/local/etc/xen/scripts on
FreeBSD. Instead of hardcoding it's location use the XEN_SCRIPT_DIR variable
like it's used on the xencommons rc.d script.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
tools/hotplug/FreeBS
be64toh and friends are declared in sys/endian.h on FreeBSD, so include it
as part of libxl_osdeps.h.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxl/libxl_osdeps.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/libxl_osdeps.h b/too
We cannot use the systems errno values when checking return values from Xen,
because some OSes don't have the same set of errno definitions. Instead
use the definitions present in Xen public errno.h header.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
I have
Chen, Tiejun writes ("Re: [v10][PATCH 11/16] tools/libxl: detect and avoid
conflicts with RDM"):
> Note I need more time to address others.
Right. But thanks for coming back quickly with this question:
> >> +int libxl__domain_device_construct_rdm(libxl__gc *gc,
> >> +
On 07/20/2015 10:09 AM, Dario Faggioli wrote:
On Fri, 2015-07-17 at 14:17 -0400, Boris Ostrovsky wrote:
On 07/17/2015 03:27 AM, Dario Faggioli wrote:
In the meanwhile, what should we do? Document this? How? "don't use
vNUMA with PV guest in SMT enabled systems" seems a bit harsh... Is
there a w
Note I need more time to address others.
+int libxl__domain_device_construct_rdm(libxl__gc *gc,
+ libxl_domain_config *d_config,
+ uint64_t rdm_mem_boundary,
+ struct xc_hvm_build_a
Add multiboot2 protocol support for relocatable images. Only GRUB2
with relevant patches understands that feature. Older multiboot
protocol (regardless of version) compatible loaders ignore it
and everything works as usual.
Signed-off-by: Daniel Kiper
---
xen/arch/x86/boot/head.S | 46
Do not pass memory maps to image if it asked for EFI boot services. Maps are
usually invalid in that case and they can confuse potential user. Image should
get memory map itself just before ExitBootServices() call.
Signed-off-by: Daniel Kiper
---
grub-core/loader/multiboot_mbi2.c | 71
Add tags used to pass ImageHandle to loaded image. It is used
by at least ExitBootServices() function.
Signed-off-by: Daniel Kiper
---
grub-core/loader/multiboot_mbi2.c | 46 +
include/multiboot2.h | 16 +
2 files changed, 53 inser
Hi,
This patch series:
- enables EFI boot services usage in loaded images
by multiboot2 protocol,
- add support for multiboot2 protocol compatible
relocatable images,
- fixes two minor issues.
Daniel
.gitignore|3 ++
grub-core/Makefile.core.def
Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded
Signed-off-by: Daniel Kiper
---
grub-core/loader/i386/multiboot_mbi.c |6 ++--
grub-core/loader/multiboot.c | 12 +--
grub-core/loader/multiboot_elfxx.c| 28 +++
grub-core/loader/multiboot_mbi2.c | 63 +
include/grub/multi
malloc_in_range() should not use memory region if its starta is smaller
than size. Otherwise target wraps around and points to region which is
usually not a RAM, e.g.:
loader/multiboot.c:93: segment 0: paddr=0x80, memsz=0x3f80,
vaddr=0x80
lib/relocator.c:1241: min_addr = 0x0, max_addr
Signed-off-by: Daniel Kiper
---
.gitignore |3 +++
1 file changed, 3 insertions(+)
diff --git a/.gitignore b/.gitignore
index 18ab8e8..6d25d39 100644
--- a/.gitignore
+++ b/.gitignore
@@ -147,6 +147,7 @@ mod-*.c
missing
netboot_test
*.o
+*.orig
*.a
ohci_test
partmap_test
@@ -160,9 +161
Looks just a little bit should be changed so I also paste this new
online to try winning your Acked here,
hvmloader/e820: construct guest e820 table
Now use the hypervisor-supplied memory map to build our final e820 table:
* Add regions for BIOS ranges and other special mappings not in the
h
On 2015/7/20 22:16, Jan Beulich wrote:
On 20.07.15 at 16:10, wrote:
Hmm... although I suppose that doesn't catch the possibility of a memory
range crossing the 4G boundary.
I think we can safely ignore that - both real and virtual hardware have
special regions right below 4Gb, so neither RAM
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 1
Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box and much e
..which finds suitable GOP mode. We want to re-use this
code to support multiboot2 protocol on EFI platforms.
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/common/efi/boot.c | 94
..which gets memory map and calls ExitBootServices(). We want to re-use this
code to support multiboot2 protocol on EFI platforms.
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/common/efi/boot.c | 92 +++
..which sets chosen GOP mode. We want to re-use this
code to support multiboot2 protocol on EFI platforms.
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/common/efi/boot.c | 33 -
1 fi
On Mon, 2015-07-20 at 15:12 +0100, Anthony PERARD wrote:
> On Fri, Jul 17, 2015 at 05:04:03PM +0100, Ian Campbell wrote:
> > On Thu, 2015-07-16 at 12:18 +0100, Anthony PERARD wrote:
> > > +cd $builddir/devstack
> > > +>local.conf
> > > +echo >>local.conf '[[local|localrc]]'
> > > +e
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load not ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
Currently, PE file contains many sections which are not "linear" (
..which collects system tables data. We want to re-use this
code to support multiboot2 protocol on EFI platforms.
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/common/efi/boot.c | 61 +++-
We need more fine grained knowledge about EFI environment and check
for EFI platform and EFI loader separately to properly support
multiboot2 protocol. In general Xen loaded by this protocol uses
memory mappings and loaded modules in similar way to Xen loaded
by multiboot (v1) protocol. Hence, crea
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and
going down. Sadly this does not work when Xen is loaded using multiboot2
protocol because start lives on 1 MiB address. So, I tried to use
mem_lower address calculate
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- generate multiboot2 header using macros
(suggested by Jan Beulich),
- switch CPU to x86_32 mode before
jumping to 32-bit code
(suggested by Andrew Cooper),
- reduce code changes to increase patch readability
(su
..which sets console mode. We want to re-use this
code to support multiboot2 protocol on EFI platforms.
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/common/efi/boot.c | 37 -
1 f
..which initializes basic EFI variables. We want to re-use this
code to support multiboot2 protocol on EFI platforms.
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/common/efi/boot.c | 28 +---
..which collects variable store parameters. We want to re-use this
code to support multiboot2 protocol on EFI platforms.
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/common/efi/boot.c | 41 -
1 - 100 of 212 matches
Mail list logo
