Re: [Xen-devel] [PULL 0/1] Xen tree 2015-01-26
On 26 January 2015 at 12:00, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: The following changes since commit b3a4755a67a52aa7297eb8927b482d09dabdefec: Merge remote-tracking branch 'remotes/kraxel/tags/pull-vnc-20150122-1' into staging (2015-01-22 12:14:19 +) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2015-01-26 for you to fetch changes up to d01a5a3fe19645f3cdea1566f0e518ea2152a029: fix QEMU build on Xen/ARM (2015-01-26 11:56:33 +) Stefano Stabellini (1): fix QEMU build on Xen/ARM Applied, thanks. -- PMM ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 04/19] Pass host to toolstack()
This will be needed in a future patch.
Everywhere already has a $ho in hand. Also cache the answer as
$ho-{Toolstack}.
I scanned the source with:
find -name \*.pm -exec perl -c {} \;
for i in ts-* ; do perl -c $i; done
which reported Not enough arguments for Osstest::TestSupport::toolstack
for each callsite which needed changing.
Also don't pass the toolstack command name directly to
host_get_free_memory(). Look it up instead.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
Osstest/TestSupport.pm | 16 ++--
ts-debian-fixup| 2 +-
ts-debian-hvm-install | 4 ++--
ts-guest-localmigrate | 2 +-
ts-guest-migrate | 2 +-
ts-guest-saverestore | 8
ts-guest-start | 4 ++--
ts-guest-stop | 2 +-
ts-logs-capture| 2 +-
ts-migrate-support-check | 4 ++--
ts-redhat-install | 2 +-
ts-rumpuserxen-demo-xenstorels | 4 ++--
ts-windows-install | 2 +-
ts-xen-install | 10 +-
14 files changed, 34 insertions(+), 30 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 17fb4ce..28d8767 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -954,8 +954,9 @@ END
});
}
-sub host_get_free_memory($$) {
-my ($ho,$toolstack) = @_;
+sub host_get_free_memory($) {
+my ($ho) = @_;
+my $toolstack = toolstack($ho)-{Command};
# The line is as followed:
# free_memory :
my $info = target_cmd_output_root($ho, $toolstack info, 10);
@@ -1318,7 +1319,7 @@ sub guest_await_shutdown ($$$) {
sub guest_destroy ($$) {
my ($ho,$gho) = @_;
-target_cmd_root($ho, toolstack()-{Command}. destroy $gho-{Name}, 40);
+target_cmd_root($ho, toolstack($ho)-{Command}. destroy $gho-{Name},
40);
}
sub guest_create ($$) {
@@ -1611,7 +1612,7 @@ sub guest_check_up ($) {
sub guest_get_state ($$) {
my ($ho,$gho) = @_;
-my $domains= target_cmd_output_root($ho, toolstack()-{Command}. list);
+my $domains= target_cmd_output_root($ho, toolstack($ho)-{Command}.
list);
$domains =~ s/^Name.*\n//;
foreach my $l (split /\n/, $domains) {
$l =~ m/^(\S+) (?: \s+ \d+ ){3} \s+ ([-a-z]+) \s/x or die $l ?;
@@ -1816,7 +1817,7 @@ sub guest_find_domid ($$) {
my ($ho,$gho) = @_;
return if defined $gho-{Domid};
my $list= target_cmd_output_root($ho,
-toolstack()-{Command}. list $gho-{Name});
+toolstack($ho)-{Command}. list $gho-{Name});
$list =~ m/^(?!Name\s)(\S+)\s+(\d+)\s+(\d+)+(\d+)\s.*$/m
or die domain list: $list;
$1 eq $gho-{Name} or die domain list name $1 expected $gho-{Name};
@@ -1886,7 +1887,9 @@ our %toolstacks=
},
);
-sub toolstack () {
+sub toolstack ($) {
+my ($ho) = @_;
+return $ho-{Toolstack} if $ho-{Toolstack};
my $tsname= $r{toolstack};
$tsname= 'xend' if !defined $tsname;
my $ts= $toolstacks{$tsname};
@@ -1895,6 +1898,7 @@ sub toolstack () {
logm(toolstack $tsname);
$ts-{Name}= $tsname;
}
+$ho-{Toolstack} = $ts;
return $ts;
}
diff --git a/ts-debian-fixup b/ts-debian-fixup
index b560501..ee1ec98 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -148,7 +148,7 @@ sub otherfixupcfg () {
if (@pcipt) {
logm(checking passthrough device(s) are assignable: @pcipt);
my @assignables= split /\n/,
-target_cmd_output_root($ho, toolstack()-{Command}.
+target_cmd_output_root($ho, toolstack($ho)-{Command}.
pci-assignable-list);
foreach my $pcipt (@pcipt) {
die not assignable: $pcipt (not in: @assignables)
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 37eade2..0148eef 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -41,7 +41,7 @@ our $disk_mb= 1;
our $guesthost= $gn.guest.osstest;
our $gho;
-our $toolstack= toolstack()-{Command};
+our $toolstack= toolstack($ho)-{Command};
sub preseed () {
@@ -171,7 +171,7 @@ sub prep () {
# If host has 8G free memory, create a guest with 4G memory to catch
# any error that triggers cross 4G boundary
-my $host_freemem_mb = host_get_free_memory($ho, $toolstack);
+my $host_freemem_mb = host_get_free_memory($ho);
my $ram_minslop = 100;
my $ram_lots = 5000;
if ($host_freemem_mb $ram_lots * 2 + $ram_minslop) {
diff --git a/ts-guest-localmigrate b/ts-guest-localmigrate
index e50e93a..f3381da 100755
--- a/ts-guest-localmigrate
+++ b/ts-guest-localmigrate
@@ -33,7 +33,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
sub migrate () {
guest_checkrunning($ho,$gho) or die $gho-{Name};
target_cmd_root($ho,
- toolstack()-{Command}
+ toolstack($ho)-{Command}
. migrate $gho-{Name} localhost,
[Xen-devel] [PATCH v3 17/19] Toolstack: Remove Command field for all toolstacks.
Nothing in generic code uses this now, so remove.
xl+xend retain as _Command for internal use only.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
Osstest/Toolstack/libvirt.pm | 1 -
Osstest/Toolstack/xend.pm| 2 +-
Osstest/Toolstack/xl.pm | 18 +-
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 28c5cb1..f5f099a 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -29,7 +29,6 @@ sub new {
NewDaemons = [qw(libvirtd)],
Dom0MemFixed = 1,
CfgPathVar = 'cfgpath',
- Command = 'virsh',
ExtraPackages = [qw(libnl1 libavahi-client3)],
}, $class;
}
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 8e77a05..ed9071b 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -29,7 +29,7 @@ sub new {
Host = $ho,
NewDaemons = [qw(xend)],
OldDaemonInitd = 'xend',
- Command = 'xm',
+ _Command = 'xm',
CfgPathVar = 'cfgpath',
Dom0MemFixed = 1,
}, $class;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index b730783..7938649 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -28,7 +28,7 @@ sub new {
Host = $ho,
NewDaemons = [],
Dom0MemFixed = 1,
- Command = 'xl',
+ _Command = 'xl',
CfgPathVar = 'cfgpath',
RestoreNeedsConfig = 1,
}, $class;
@@ -37,31 +37,31 @@ sub new {
sub destroy ($$) {
my ($self,$gho) = @_;
my $gn = $gho-{Name};
-target_cmd_root($self-{Host}, $self-{Command}. destroy $gn, 40);
+target_cmd_root($self-{Host}, $self-{_Command}. destroy $gn, 40);
}
sub create ($$) {
my ($self,$cfg) = @_;
-target_cmd_root($self-{Host}, $self-{Command}. create $cfg, 100);
+target_cmd_root($self-{Host}, $self-{_Command}. create $cfg, 100);
}
sub consolecmd ($$) {
my ($self,$gho) = @_;
my $gn = $gho-{Name};
-return $self-{Command}. console $gn;
+return $self-{_Command}. console $gn;
}
sub shutdown_wait ($$$) {
my ($self,$gho,$timeout) = @_;
my $ho = $self-{Host};
my $gn = $gho-{Name};
-target_cmd_root($ho,$self-{Command} shutdown -w $gn, $timeout);
+target_cmd_root($ho,$self-{_Command} shutdown -w $gn, $timeout);
}
sub migrate_check ($) {
my ($self) = @_;
my $ho = $self-{Host};
-my $help = target_cmd_output_root($ho, $self-{Command}. help);
+my $help = target_cmd_output_root($ho, $self-{_Command}. help);
my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
logm(rc=$rc);
return $rc;
@@ -73,7 +73,7 @@ sub migrate () {
my $dst = $dho-{Name};
my $gn = $gho-{Name};
target_cmd_root($sho,
- $self-{Command}. migrate $gn $dst,
+ $self-{_Command}. migrate $gn $dst,
$timeout);
}
@@ -81,7 +81,7 @@ sub save () {
my ($self,$gho,$f,$timeout) = @_;
my $ho = $self-{Host};
my $gn = $gho-{Name};
-target_cmd_root($ho,$self-{Command}. save $gn $f, $timeout);
+target_cmd_root($ho,$self-{_Command}. save $gn $f, $timeout);
}
sub restore () {
@@ -90,7 +90,7 @@ sub restore () {
my $gn = $gho-{Name};
my $cfg = $self-{RestoreNeedsConfig} ? $gho-{CfgPath} : '';
target_cmd_root($ho,
- $self-{Command}
+ $self-{_Command}
. restore
.$cfg
. $f, $timeout);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 15/19] libvirt: Implement initscript restart which has some hope of working.
... by refactoring start/stop actions into the functions which are
expected by restart.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v3: Refactor into start/stop functions
---
ts-libvirt-build | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/ts-libvirt-build b/ts-libvirt-build
index 8c5d1fc..7322d73 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -128,22 +128,32 @@ test -x $DAEMON || exit 0
PIDFILE=/var/run/$NAME.pid
+start() {
+ start-stop-daemon --start --pidfile $PIDFILE \
+ --exec $DAEMON $@ -- -d $libvirtd_opts
+}
+
+stop() {
+ start-stop-daemon --stop --pidfile $PIDFILE \
+ --exec $DAEMON $@
+}
+
case $1 in
start)
[ $VERBOSE != no ] log_daemon_msg Starting $DESC $NAME
- start-stop-daemon --start --pidfile $PIDFILE \
- --exec $DAEMON -- -d $libvirtd_opts
+ start
[ $VERBOSE != no ] log_end_msg $?
;;
stop)
[ $VERBOSE != no ] log_daemon_msg Stopping $DESC $NAME
- start-stop-daemon --stop --pidfile $PIDFILE \
- --exec $DAEMON
+ stop
[ $VERBOSE != no ] log_end_msg $?
;;
restart)
- stop
+ [ $VERBOSE != no ] log_daemon_msg Restarting $DESC $DAEMON
+ stop --oknodo
start
+ [ $VERBOSE != no ] log_end_msg $?
;;
reload|force-reload)
start-stop-daemon --stop --signal 1 --quiet --pidfile \
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 19/19] Toolstack: Pass $gho to create method
The cfg file can be obtained from $gho-{CfgPath}. This is more
consistent with other methods.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v3: New patch, implementing suggesting from review of Toolstack:
Refactor guest lifecycle.
---
Osstest/TestSupport.pm | 2 +-
Osstest/Toolstack/libvirt.pm | 3 ++-
Osstest/Toolstack/xl.pm | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 427ead4..086ac10 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1340,7 +1340,7 @@ sub guest_await_destroy ($$) {
sub guest_create ($) {
my ($gho) = @_;
my $ho = $gho-{Host};
-toolstack($ho)-create($gho-{CfgPath});
+toolstack($ho)-create($gho);
}
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index e9d3952..8bd7f4f 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -39,8 +39,9 @@ sub destroy ($$) {
}
sub create ($$) {
-my ($self,$cfg) = @_;
+my ($self,$gho) = @_;
my $ho = $self-{Host};
+my $cfg = $gho-{CfgPath};
my $lcfg = $cfg;
$lcfg =~ s,/,-,g;
$lcfg = $ho-{Name}--$lcfg;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 5498c0a..71aefd5 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -40,7 +40,8 @@ sub destroy ($$) {
}
sub create ($$) {
-my ($self,$cfg) = @_;
+my ($self,$gho) = @_;
+my $cfg = $gho-{CfgPath};
target_cmd_root($self-{Host}, $self-{_Command}. create $cfg, 100);
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 13/19] Toolstack: Refactor migration support.
Note that since the previous patch arranges for
ts-migration-support-check to continue to fail for libvirt the libvirt
code is not actually called yet (and will die if it is). This patch is
mainly included to reduce the number of users of
toolstack()-{Command} closer to zero.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v3: Pass a $ho object as the destination, rather than it's name.
---
Osstest/Toolstack/libvirt.pm | 5 +
Osstest/Toolstack/xl.pm | 10 ++
ts-guest-localmigrate| 6 ++
ts-guest-migrate | 5 +
4 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index b74c8cb..3f84be8 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -68,4 +68,9 @@ sub migrate_check ($) {
die Migration check is not yet supported on libvirt.;
}
+sub migrate ($) {
+my ($self,$gho,$dst,$timeout) = @_;
+die Migration is not yet supported on libvirt.;
+}
+
1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index dcf3b08..4f710dd 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -67,4 +67,14 @@ sub migrate_check ($) {
return $rc;
}
+sub migrate () {
+my ($self,$gho,$dho,$timeout) = @_;
+my $sho = $self-{Host};
+my $dst = $dho-{Name};
+my $gn = $gho-{Name};
+target_cmd_root($sho,
+ $self-{Command}. migrate $gn $dst,
+ $timeout);
+}
+
1;
diff --git a/ts-guest-localmigrate b/ts-guest-localmigrate
index f3381da..a831521 100755
--- a/ts-guest-localmigrate
+++ b/ts-guest-localmigrate
@@ -32,10 +32,8 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
sub migrate () {
guest_checkrunning($ho,$gho) or die $gho-{Name};
-target_cmd_root($ho,
- toolstack($ho)-{Command}
- . migrate $gho-{Name} localhost,
- $timeout{Migrate});
+# Migrate to same host, via localhost interface.
+toolstack($ho)-migrate($gho, { %$ho, Name = localhost },
$timeout{Migrate});
}
guest_await_dhcp_tcp($gho, 5);
diff --git a/ts-guest-migrate b/ts-guest-migrate
index 65e7b42..b77d0de 100755
--- a/ts-guest-migrate
+++ b/ts-guest-migrate
@@ -31,10 +31,7 @@ our $gho = selectguest($ARGV[2],$sho);
sub migrate () {
guest_checkrunning($sho,$gho) or die $gho-{Name};
my $err= guest_check_ip($gho); die $err $gho-{Name} if defined $err;
-target_cmd_root($sho,
- toolstack($sho)-{Command}
- . migrate $gho-{Name} $dho-{Name},
- $timeout{Migrate});
+toolstack($sho)-migrate($gho, $dho, $timeout{Migrate});
}
guest_await_dhcp_tcp($gho, 5);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 33690: regressions - FAIL
On 01/26/2015 09:49 AM, Andrew Cooper wrote: On 26/01/15 11:38, Jan Beulich wrote: On 26.01.15 at 12:04, jbeul...@suse.com wrote: On 24.01.15 at 13:54, ian.jack...@eu.citrix.com wrote: test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637 Jan 24 00:35:16.262627 (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] Jan 24 00:35:16.478599 (XEN) CPU:1 Jan 24 00:35:16.478624 (XEN) RIP:e008:[] Jan 24 00:35:16.486596 (XEN) RFLAGS: 00010082 CONTEXT: hypervisor ... Jan 24 00:35:16.678620 (XEN) Xen call trace: Jan 24 00:35:16.678650 (XEN)[82d0801d36d0] vpmu_do_interrupt+0x2f/0x8a Jan 24 00:35:16.686605 (XEN)[82d08015e242] pmu_apic_interrupt+0x33/0x35 Jan 24 00:35:16.698582 (XEN)[82d080171bf0] do_IRQ+0x9c/0x624 Jan 24 00:35:16.698615 (XEN)[82d080234062] common_interrupt+0x62/0x70 Jan 24 00:35:16.698653 (XEN)[82d08012c6fe] _spin_unlock_irq+0x30/0x31 Jan 24 00:35:16.706604 (XEN)[82d08012bcf1] __do_softirq+0x81/0x8c Jan 24 00:35:16.706638 (XEN)[82d08012bd49] do_softirq+0x13/0x15 Jan 24 00:35:16.718591 (XEN)[82d0801ec4da] vmx_asm_do_vmentry+0x2a/0x50 I think I see what the problem here is: Commit 8097616fbd (x86/VPMU: handle APIC_LVTPC accesses) gives the guest control over LVTPC.mask regardless of whether the vPMU was actually initialized for it. Supposedly in the case above the guest is being run with core2_no_vpmu_ops, which in particular has .do_interrupt == NULL. It's not immediately clear whether vpmu_lvtpc_update() should do the check or its (sole) caller. In any event I'm going to revert that commit as the primary suspect for causing the regression. I have just fallen over this as well. I second a revert in the absence of a clear way to fix the patch. I can't reproduce this -- neither at this patch level nor at full series. Yes, we can test for do_interrupt presence in vpmu_lvtpc_update() (or in vpmu_interrupt() itself) but since we cannot arm the counters (there is no do_wrmsr op) I am not sure I understand what can trigger this interrupt. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH v1] xen/arm: split the init_xen_time() in 2 parts
Hi Oleksandr,
Thank you for the patch. See few comments below.
On 23/01/15 15:49, Oleksandr Tyshchenko wrote:
Create preinit_xen_time() and move to it minimum required
subset of operations needed to properly initialized
cpu_khz and boot_count vars. This is allow us to use udelay()
immediately after the call.
Signed-off-by: Oleksandr Tyshchenko oleksandr.tyshche...@globallogic.com
CC: Julien Grall julien.gr...@linaro.org
---
xen/arch/arm/setup.c | 2 ++
xen/arch/arm/time.c| 71
--
xen/include/xen/time.h | 1 +
3 files changed, 48 insertions(+), 26 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f49569d..dbd7d5a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -743,6 +743,8 @@ void __init start_xen(unsigned long boot_phys_offset,
init_IRQ();
+preinit_xen_time();
+
dt_uart_init();
console_init_preirq();
console_init_ring();
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 455f217..b2560db 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -61,25 +61,56 @@ unsigned int timer_get_irq(enum timer_ppi ppi)
return muldiv64(ns, 1000 * cpu_khz, SECONDS(1));
}
-/* Set up the timer on the boot CPU */
-int __init init_xen_time(void)
+static __init struct dt_device_node *find_timer_node(void)
+{
+ static const struct dt_device_match timer_ids[] __initconst =
+ {
+ DT_MATCH_TIMER,
+ { /* sentinel */ },
+ };
+
+ return dt_find_matching_node(NULL, timer_ids);
+}
If you store the device tree pointer into a static variable, you won't
able to look at twice the node (in preinit_xen_time and init_xen_time).
+
+/* Set up the timer on the boot CPU (early init function) */
+int __init preinit_xen_time(void)
You always return 0 and never check the return. Please use void.
{
-static const struct dt_device_match timer_ids[] __initconst =
-{
-DT_MATCH_TIMER,
-{ /* sentinel */ },
-};
struct dt_device_node *dev;
int res;
-unsigned int i;
u32 rate;
-dev = dt_find_matching_node(NULL, timer_ids);
+dev = find_timer_node();
if ( !dev )
panic(Unable to find a compatible timer in the device tree);
dt_device_set_used_by(dev, DOMID_XEN);
+res = platform_init_time();
If you move platform_init_time in preinit_xen_time, you also have to
move platform_init before calling preinit_xen_time.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: also use tzcnt instead of bsf in __scanbit()
On 26/01/15 12:03, Jan Beulich wrote:
... when available, i.e. by runtime patching. This saves the
conditional move, having a back-to-back dependency on BSF's (EFLAGS)
result.
The need to include asm/cpufeatures.h from asm/bitops.h requires a
workaround for an otherwise resulting circular header file dependency:
Provide a mode by which the including site of the former header can
request to only get the X86_FEATURE_* defines (and very little more)
from it, allowing it to nevertheless be included in its entirety later
on.
While doing this I also noticed that the function's max parameter was
pointlessly unsigned long - the function only returning
unsigned int, this can't be of any use, and hence gets converted at
once, along with the necessary adjustments to CMOVZ's output operands.
Note that while only alternative_io() is needed by this change (and
hence gets pulled over from Linux), for completeness its input-only
counterpart alternative_input() gets added as well.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
--- a/xen/include/asm-x86/alternative.h
+++ b/xen/include/asm-x86/alternative.h
@@ -12,6 +12,7 @@
.byte \alt_len
.endm
#else
+#include xen/stringify.h
#include xen/types.h
struct alt_instr {
@@ -73,6 +74,26 @@ extern void alternative_instructions(voi
#define alternative(oldinstr, newinstr, feature)\
asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) : : :
memory)
+/*
+ * Alternative inline assembly with input.
+ *
+ * Pecularities:
+ * No memory clobber here.
+ * Argument numbers start with 1.
+ * Best is to use constraints that are fixed size (like (%1) ... r)
+ * If you use variable sized constraints like m or g in the
+ * replacement make sure to pad to the worst case length.
+ * Leaving an unused argument 0 to keep API compatibility.
+ */
+#define alternative_input(oldinstr, newinstr, feature, input...) \
+ asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) \
+ : : i (0), ## input)
+
+/* Like alternative_input, but with a single output argument */
+#define alternative_io(oldinstr, newinstr, feature, output, input...)
\
+ asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) \
+ : output : i (0), ## input)
+
#endif /* __ASSEMBLY__ */
#endif /* __X86_ALTERNATIVE_H__ */
--- a/xen/include/asm-x86/bitops.h
+++ b/xen/include/asm-x86/bitops.h
@@ -5,7 +5,9 @@
* Copyright 1992, Linus Torvalds.
*/
-#include xen/config.h
+#include asm/alternative.h
+#define X86_FEATURES_ONLY
+#include asm/cpufeature.h
/*
* We specify the memory operand as both input and output because the memory
@@ -313,9 +315,17 @@ extern unsigned int __find_first_zero_bi
extern unsigned int __find_next_zero_bit(
const unsigned long *addr, unsigned int size, unsigned int offset);
-static inline unsigned int __scanbit(unsigned long val, unsigned long max)
+static inline unsigned int __scanbit(unsigned long val, unsigned int max)
{
-asm ( bsf %1,%0 ; cmovz %2,%0 : =r (val) : r (val), r (max) );
+if ( __builtin_constant_p(max) max == BITS_PER_LONG )
+alternative_io(bsf %[in],%[out]; cmovz %[max],%k[out],
+ rep; bsf %[in],%[out],
+ X86_FEATURE_BMI1,
+ [out] =r (val),
+ [in] r (val), [max] r (max));
+else
+asm ( bsf %1,%0 ; cmovz %2,%k0
+ : =r (val) : r (val), r (max) );
return (unsigned int)val;
}
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -5,10 +5,8 @@
*/
#ifndef __ASM_I386_CPUFEATURE_H
+#ifndef X86_FEATURES_ONLY
#define __ASM_I386_CPUFEATURE_H
-
-#ifndef __ASSEMBLY__
-#include xen/bitops.h
#endif
#define NCAPINTS 8 /* N 32-bit words worth of info */
@@ -155,7 +153,9 @@
#define X86_FEATURE_ADX (7*32+19) /* ADCX, ADOX instructions */
#define X86_FEATURE_SMAP (7*32+20) /* Supervisor Mode Access Prevention
*/
-#ifndef __ASSEMBLY__
+#if !defined(__ASSEMBLY__) !defined(X86_FEATURES_ONLY)
+#include xen/bitops.h
+
#define cpu_has(c, bit) test_bit(bit, (c)-x86_capability)
#define boot_cpu_has(bit)test_bit(bit, boot_cpu_data.x86_capability)
#define cpufeat_mask(idx) (1u ((idx) 31))
@@ -262,6 +262,8 @@ struct cpuid4_info {
int cpuid4_cache_lookup(int index, struct cpuid4_info *this_leaf);
#endif
+#undef X86_FEATURES_ONLY
+
#endif /* __ASM_I386_CPUFEATURE_H */
/*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH v1] xen/arm: split the init_xen_time() in 2 parts
On Mon, Jan 26, 2015 at 3:32 PM, Julien Grall julien.gr...@linaro.org wrote:
Hi Oleksandr,
Hi Julien
Thank you for your comments.
Thank you for the patch. See few comments below.
On 23/01/15 15:49, Oleksandr Tyshchenko wrote:
Create preinit_xen_time() and move to it minimum required
subset of operations needed to properly initialized
cpu_khz and boot_count vars. This is allow us to use udelay()
immediately after the call.
Signed-off-by: Oleksandr Tyshchenko oleksandr.tyshche...@globallogic.com
CC: Julien Grall julien.gr...@linaro.org
---
xen/arch/arm/setup.c | 2 ++
xen/arch/arm/time.c| 71
--
xen/include/xen/time.h | 1 +
3 files changed, 48 insertions(+), 26 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f49569d..dbd7d5a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -743,6 +743,8 @@ void __init start_xen(unsigned long boot_phys_offset,
init_IRQ();
+preinit_xen_time();
+
dt_uart_init();
console_init_preirq();
console_init_ring();
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 455f217..b2560db 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -61,25 +61,56 @@ unsigned int timer_get_irq(enum timer_ppi ppi)
return muldiv64(ns, 1000 * cpu_khz, SECONDS(1));
}
-/* Set up the timer on the boot CPU */
-int __init init_xen_time(void)
+static __init struct dt_device_node *find_timer_node(void)
+{
+ static const struct dt_device_match timer_ids[] __initconst =
+ {
+ DT_MATCH_TIMER,
+ { /* sentinel */ },
+ };
+
+ return dt_find_matching_node(NULL, timer_ids);
+}
If you store the device tree pointer into a static variable, you won't
able to look at twice the node (in preinit_xen_time and init_xen_time).
Agree.
+
+/* Set up the timer on the boot CPU (early init function) */
+int __init preinit_xen_time(void)
You always return 0 and never check the return. Please use void.
ok
{
-static const struct dt_device_match timer_ids[] __initconst =
-{
-DT_MATCH_TIMER,
-{ /* sentinel */ },
-};
struct dt_device_node *dev;
int res;
-unsigned int i;
u32 rate;
-dev = dt_find_matching_node(NULL, timer_ids);
+dev = find_timer_node();
if ( !dev )
panic(Unable to find a compatible timer in the device tree);
dt_device_set_used_by(dev, DOMID_XEN);
+res = platform_init_time();
If you move platform_init_time in preinit_xen_time, you also have to
move platform_init before calling preinit_xen_time.
ok
Regards,
--
Julien Grall
--
Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/5]arm64: Add multiboot support (via fdt) for Xen boot
Ping?
I think it would be great to have multiboot support in grub.
As a matter of fact without it grub cannot load xen on arm.
On Wed, 21 Jan 2015, Fu Wei wrote:
Hi everybody,
any suggestion for my patchset?
if these patches look fine, can they be merged?
Any feedback is welcome! :-)
Great thanks !
On 9 January 2015 at 00:38, Ian Campbell ian.campb...@citrix.com wrote:
On Fri, 2014-12-19 at 01:55 +0800, Fu Wei wrote:
Signed-off-by: Fu Wei fu@linaro.org
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
I've tested the code at
git://git.linaro.org/people/fu.wei/grub.git#multiboot_xen_support_upstream_v4.0
which I believe is the same as this posting on an AMD Seattle system
with a 40_custom containing:
menuentry 'Baremetal' {
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
search --no-floppy --fs-uuid --set=root
d4178d5c-96a8-46ee-a304-0d87baa545cd
linux /boot/vmlinuz console=ttyAMA0,115200n8
earlycon=pl011,0xe101 root=/dev/sda2 rootwait
}
menuentry 'Xen' {
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
search --no-floppy --fs-uuid --set=root
d4178d5c-96a8-46ee-a304-0d87baa545cd
multiboot /boot/xen no-bootscrub console=dtuart
conswitch=x dtuart=/smb/serial@e101 noreboot
sync_console dom0_mem=256M dom0_max_vcpus=1
module /boot/vmlinuz-xen console=hvc0
earlycon=pl011,0xe101 root=/dev/sda2 rootwait
}
(my system is too confused for 10_linux or 20_linux_xen right now, but I
believe this is representative of what they would emit)
The result was that I could boot both Baremetal and Xen via grub. So:
Tested-by: Ian Campbell ian.campb...@citrix.com
I've not looked at the code (although I did review several older
iterations), would it be useful to the grub maintainers for me to do so?
Ian.
--
Best regards,
Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 OSSTEST 0/19] Implement for driving libvirt via virsh
The following series switches osstest to implement the toolstack via
get_host_method_object()-method rather than toolstack()-{Command}.
method etc.
This is needed because virsh differs from xm/xl in a few commands.
It also implements partial virsh support (simple lifecycle stuff, but
not e.g. migration yet). Due to the ts-migration-check logic this means
that the libvirt sequence works in so far as it skips/ignores the
migration/save+restore related tests. Wei has a followup series (or at
least a WIP?) which adds migration support. I've dropped my WIP patch
from last time in favour of that.
Since last time I've addressed all of Ian's review on v2. Lots of
passing $gho to things instead of individual properties, switch to a
better inheritance scheme for Osstest::Toolstack::xend,
*TestSupport: Add helper to wait for a guest to shutdown
apt: lock osstest's usages of apt-get against each other
Ats-logs-capture: Collect some libvirt logs and capabilities
APass host to toolstack()
Ats-rumpuserxen-demo-xenstorels: Use standard functions for things
Toolstack: use get_host_method_object() to manage toolstack selection
TestSupport: always use xl for generic operations.
TestSupport: guest_create and guest_destroy take only a $gho.
Toolstack: Refactor guest lifecycle.
Toolstack: Refactor consolecmd handling
Toolstack: Refactor shutdown support
AToolstack: Refactor migration support check.
Toolstack: Refactor migration support.
Toolstack: Refactor save/restore support
libvirt: Implement initscript restart which has some hope of working.
Alibvirt: Implement shutdown_wait
AToolstack: Remove Command field for all toolstacks.
Ats-guest-start: Use guest_create
NToolstack: Pass $gho to create method
* == TestSupport: Add helper to wait for a guest to shutdown) wasn't
posted last time, it was actually part of the add distro domU testing
flight series, but it is needed here too and I expect this one to land
first.
N == New
A == Acked
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 33690: regressions - FAIL
On 26/01/15 11:38, Jan Beulich wrote: On 26.01.15 at 12:04, jbeul...@suse.com wrote: On 24.01.15 at 13:54, ian.jack...@eu.citrix.com wrote: test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637 Jan 24 00:35:16.262627 (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] Jan 24 00:35:16.478599 (XEN) CPU:1 Jan 24 00:35:16.478624 (XEN) RIP:e008:[] Jan 24 00:35:16.486596 (XEN) RFLAGS: 00010082 CONTEXT: hypervisor ... Jan 24 00:35:16.678620 (XEN) Xen call trace: Jan 24 00:35:16.678650 (XEN)[82d0801d36d0] vpmu_do_interrupt+0x2f/0x8a Jan 24 00:35:16.686605 (XEN)[82d08015e242] pmu_apic_interrupt+0x33/0x35 Jan 24 00:35:16.698582 (XEN)[82d080171bf0] do_IRQ+0x9c/0x624 Jan 24 00:35:16.698615 (XEN)[82d080234062] common_interrupt+0x62/0x70 Jan 24 00:35:16.698653 (XEN)[82d08012c6fe] _spin_unlock_irq+0x30/0x31 Jan 24 00:35:16.706604 (XEN)[82d08012bcf1] __do_softirq+0x81/0x8c Jan 24 00:35:16.706638 (XEN)[82d08012bd49] do_softirq+0x13/0x15 Jan 24 00:35:16.718591 (XEN)[82d0801ec4da] vmx_asm_do_vmentry+0x2a/0x50 I think I see what the problem here is: Commit 8097616fbd (x86/VPMU: handle APIC_LVTPC accesses) gives the guest control over LVTPC.mask regardless of whether the vPMU was actually initialized for it. Supposedly in the case above the guest is being run with core2_no_vpmu_ops, which in particular has .do_interrupt == NULL. It's not immediately clear whether vpmu_lvtpc_update() should do the check or its (sole) caller. In any event I'm going to revert that commit as the primary suspect for causing the regression. I have just fallen over this as well. I second a revert in the absence of a clear way to fix the patch. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 05/19] ts-rumpuserxen-demo-xenstorels: Use standard functions for things
Specifically guest_create and guest_find_domid.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
ts-rumpuserxen-demo-xenstorels | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index a2a6a77..6698848 100755
--- a/ts-rumpuserxen-demo-xenstorels
+++ b/ts-rumpuserxen-demo-xenstorels
@@ -40,11 +40,9 @@ sub arrangepreserve () {
}
sub start () {
-my $cmd= toolstack($ho)-{Command}. create .
-$r{ $gho-{Guest}.'_'. toolstack($ho)-{CfgPathVar} };
-target_cmd_root($ho, $cmd, 30);
+guest_create($gho,toolstack($ho));
-$domid = target_cmd_output_root($ho,xl domid $gho-{Guest});
+$domid = guest_find_domid($ho, $gho);
}
sub await_end () {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single
On 01/26/2015, 11:53 AM, Ian Campbell wrote: On Fri, 2014-11-21 at 17:00 +, Stefano Stabellini wrote: Need to pass the pointer within the swiotlb internal buffer to the swiotlb library, that in the case of xen_unmap_single is dev_addr, not paddr. Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com CC: konrad.w...@oracle.com CC: sta...@vger.kernel.org This went into mainline as 2c3fc8d26dd0 swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single but was reverted in dbdd74763f1f. However it seems that 2c3fc8d26dd0 has made it into at least some stable kernel trees: v3.18.3 as 2129c43d41e9 v3.16.7-ckt4 as 94ab279b0c9a v3.14.29 as 3394691d34fc v3.10.65 as 81cb80b578c5 so it should be reverted there too. This is causing issues in the field such as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776237. v3.17, v3.15, v3.13.11-ckt14, v3.12.x, v3.11.x appear clean, I stopped Hi, dropped from the 3.12 queue. thanks, -- js suse labs ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 07/19] TestSupport: always use xl for generic operations.
Unless the toolstack is xend (for compatibility with pre-xl Xen
versions), when we use xm.
For several operations in TestSupport.pm the actual toolstack isn't
really relevant, since we want info straight from Xen. For simplicity
just use xl (or xm) in these cases, to avoid needing to implement the
following specially for each toolstack:
- host_get_free_memory
- guest_get_state
- guest_find_domid
- listing assignable pci devices
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v3: common_toolstack() takes a $ho and checks if toolstack($ho) is
xend.
---
Osstest/TestSupport.pm | 14 +++---
ts-debian-fixup| 2 +-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 14d6b47..37df50e 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -936,6 +936,14 @@ sub compress_stashed($) {
#-- other stuff --
+sub common_toolstack ($) {
+my ($ho) = @_;
+my $tsname = toolstack($ho);
+my $ts = 'xl';
+$ts = 'xm' if $tsname eq 'xend';
+return $ts;
+}
+
sub host_reboot ($) {
my ($ho) = @_;
target_reboot($ho);
@@ -956,7 +964,7 @@ END
sub host_get_free_memory($) {
my ($ho) = @_;
-my $toolstack = toolstack($ho)-{Command};
+my $toolstack = common_toolstack($ho);
# The line is as followed:
# free_memory :
my $info = target_cmd_output_root($ho, $toolstack info, 10);
@@ -1612,7 +1620,7 @@ sub guest_check_up ($) {
sub guest_get_state ($$) {
my ($ho,$gho) = @_;
-my $domains= target_cmd_output_root($ho, toolstack($ho)-{Command}.
list);
+my $domains= target_cmd_output_root($ho, common_toolstack($ho). list);
$domains =~ s/^Name.*\n//;
foreach my $l (split /\n/, $domains) {
$l =~ m/^(\S+) (?: \s+ \d+ ){3} \s+ ([-a-z]+) \s/x or die $l ?;
@@ -1817,7 +1825,7 @@ sub guest_find_domid ($$) {
my ($ho,$gho) = @_;
return if defined $gho-{Domid};
my $list= target_cmd_output_root($ho,
-toolstack($ho)-{Command}. list $gho-{Name});
+common_toolstack($ho). list $gho-{Name});
$list =~ m/^(?!Name\s)(\S+)\s+(\d+)\s+(\d+)+(\d+)\s.*$/m
or die domain list: $list;
$1 eq $gho-{Name} or die domain list name $1 expected $gho-{Name};
diff --git a/ts-debian-fixup b/ts-debian-fixup
index ee1ec98..beae049 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -148,7 +148,7 @@ sub otherfixupcfg () {
if (@pcipt) {
logm(checking passthrough device(s) are assignable: @pcipt);
my @assignables= split /\n/,
-target_cmd_output_root($ho, toolstack($ho)-{Command}.
+target_cmd_output_root($ho, common_toolstack($ho).
pci-assignable-list);
foreach my $pcipt (@pcipt) {
die not assignable: $pcipt (not in: @assignables)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 10/19] Toolstack: Refactor consolecmd handling
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/Toolstack/libvirt.pm | 6 ++
Osstest/Toolstack/xl.pm | 6 ++
ts-logs-capture | 2 +-
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 0d09ffc..fb9b9a9 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -51,4 +51,10 @@ sub create ($$) {
target_cmd_root($ho, virsh create --file $cfg.xml, 100);
}
+sub consolecmd ($$) {
+my ($self,$gho) = @_;
+my $gn = $gho-{Name};
+return virsh console $gn;
+}
+
1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 12417ca..4997775 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -45,4 +45,10 @@ sub create ($$) {
target_cmd_root($self-{Host}, $self-{Command}. create $cfg, 100);
}
+sub consolecmd ($$) {
+my ($self,$gho) = @_;
+my $gn = $gho-{Name};
+return $self-{Command}. console $gn;
+}
+
1;
diff --git a/ts-logs-capture b/ts-logs-capture
index 841ad5a..dbca13a 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -195,7 +195,7 @@ sub fetch_logs_guest ($) {
logm(cannot find domid: $@);
return;
}
-my $consolecmd= toolstack($ho)-{Command}. console $gho-{Name};
+my $consolecmd= toolstack($ho)-consolecmd($gho);
try_cmd_output_save(sleep 1 | $consolecmd | cat,
guest-$gho-{Name}-console);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 02/19] apt: lock osstest's usages of apt-get against each other
Currently we rely on all apt-get invocations being in a single
ts-xen-build-prep job which can't run on a shared host.
That is a bit inflexible so instead use our own lock. We wait
indefinitely and rely on osstest's existing command timeout
infrastructure to catch problems.
target_install_packages*() previous estimated the time taken to
install the packages based on the number of packages. This no longer
applies because the install might get stuck behind some other large
install. Use a 3000s (nearly an hour) timeout instead (I expect
failures here to be unusual so erred on the big side)
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v3: Drop timeout parameter to target_run_apt
Reindent target_run_apt more sensibly
---
Osstest/Debian.pm | 2 +-
Osstest/TestSupport.pm | 12 +---
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 7081a29..d4bf62d 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -492,7 +492,7 @@ d-i apt-setup/another boolean false
d-i apt-setup/non-free boolean false
d-i apt-setup/contrib boolean false
-d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool,
$extra_packages
+d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool,
chiark-utils-bin, $extra_packages
$xopts{ExtraPreseed}
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index b983bd4..17fb4ce 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -434,20 +434,18 @@ sub target_putfile_root (;$) {
tputfileex('root', @_);
}
sub target_run_apt {
-my ($ho, $timeout, @aptopts) = @_;
+my ($ho, @aptopts) = @_;
target_cmd_root($ho,
- DEBIAN_PRIORITY=critical UCF_FORCE_CONFFOLD=y apt-get @aptopts,
-$timeout);
+DEBIAN_PRIORITY=critical UCF_FORCE_CONFFOLD=y \
+with-lock-ex -w /var/lock/osstest-apt apt-get @aptopts, 3000);
}
sub target_install_packages {
my ($ho, @packages) = @_;
-target_run_apt($ho, 300 + 100 * @packages,
- qw(-y install), @packages);
+target_run_apt($ho, qw(-y install), @packages);
}
sub target_install_packages_norec {
my ($ho, @packages) = @_;
-target_run_apt($ho, 300 + 100 * @packages,
- qw(--no-install-recommends -y install), @packages);
+target_run_apt($ho, qw(--no-install-recommends -y install), @packages);
}
sub target_somefile_getleaf ($$$) {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 16/19] libvirt: Implement shutdown_wait
virsh does not include a --wait option to shutdown as xl and xm do, so
we implement it by hand.
Needs new guest_await_destroy helper. Note the guest_await_shutdown
requires on_shutdown='preserve'
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
v3: Drop $ho parameter frm guest_await_destroy, for consistency with
changes to guest_destroy.
---
Osstest/TestSupport.pm | 8 +++-
Osstest/Toolstack/libvirt.pm | 4 +++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 5c753b4..427ead4 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -93,7 +93,7 @@ BEGIN {
guest_checkrunning guest_check_ip guest_find_ether
guest_find_domid guest_check_up guest_check_up_quick
guest_get_state guest_await_reboot
- guest_await_shutdown guest_destroy
+ guest_await_shutdown guest_await_destroy guest_destroy
guest_vncsnapshot_begin guest_vncsnapshot_stash
guest_check_remus_ok guest_editconfig
host_involves_pcipassthrough host_get_pcipassthrough_devs
@@ -1331,6 +1331,12 @@ sub guest_destroy ($) {
toolstack($ho)-destroy($gho);
}
+sub guest_await_destroy ($$) {
+my ($gho, $timeout) = @_;
+my $ho = $gho-{Host};
+return guest_await_state($ho,$gho, destroy, , $timeout);
+}
+
sub guest_create ($) {
my ($gho) = @_;
my $ho = $gho-{Host};
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 471b42e..28c5cb1 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -59,8 +59,10 @@ sub consolecmd ($$) {
sub shutdown_wait ($$$) {
my ($self,$gho,$timeout) = @_;
+my $ho = $self-{Host};
my $gn = $gho-{Name};
-die libvirt shutdown wait not implemented yet.
+target_cmd_root($ho, virsh shutdown $gn, 30);
+guest_await_destroy($gho,$timeout);
}
sub migrate_check ($) {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 03/19] ts-logs-capture: Collect some libvirt logs and capabilities
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
ts-logs-capture | 4
1 file changed, 4 insertions(+)
diff --git a/ts-logs-capture b/ts-logs-capture
index 21974a9..6cf51c1 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -117,6 +117,9 @@ sub fetch_logs_host_guests () {
/var/log/xen/osstest*
/var/log/xen/xenstored*
+ /var/log/libvirt/libvirtd.log
+ /var/log/libvirt/libxl/*
+
/var/run/xenstored*
/var/log/xenstored*
@@ -161,6 +164,7 @@ sub fetch_logs_host_guests () {
'lspci -vvv',
'lspci -tv',
'cat /proc/partitions',
+ 'virsh capabilities',
) {
try_cmd_output_save($cmd);
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 14/19] Toolstack: Refactor save/restore support
Use $gho-{CfgPath} rather than constructing it again.
Still stubbed out for libvirt.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v3: Switch to CfgPath defered from incorrect home in earlier patch to
here.
RestoreNeedsConfig is an xl/xm ism, not relevant to libvirt, so
remove $cfg parameter from restore method.
---
Osstest/Toolstack/libvirt.pm | 10 ++
Osstest/Toolstack/xl.pm | 19 +++
ts-guest-saverestore | 12 ++--
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 3f84be8..471b42e 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -73,4 +73,14 @@ sub migrate ($) {
die Migration is not yet supported on libvirt.;
}
+sub save () {
+my ($self,$gho,$f,$timeout) = @_;
+die Save is not yet supported on libvirt.;
+}
+
+sub restore () {
+my ($self,$gho,$f,$timeout) = @_;
+die Restore is not yet supported on libvirt.;
+}
+
1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 4f710dd..b730783 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -77,4 +77,23 @@ sub migrate () {
$timeout);
}
+sub save () {
+my ($self,$gho,$f,$timeout) = @_;
+my $ho = $self-{Host};
+my $gn = $gho-{Name};
+target_cmd_root($ho,$self-{Command}. save $gn $f, $timeout);
+}
+
+sub restore () {
+my ($self,$gho,$f,$timeout) = @_;
+my $ho = $self-{Host};
+my $gn = $gho-{Name};
+my $cfg = $self-{RestoreNeedsConfig} ? $gho-{CfgPath} : '';
+target_cmd_root($ho,
+ $self-{Command}
+ . restore
+ .$cfg
+ . $f, $timeout);
+}
+
1;
diff --git a/ts-guest-saverestore b/ts-guest-saverestore
index 9e04ae9..7e13d90 100755
--- a/ts-guest-saverestore
+++ b/ts-guest-saverestore
@@ -27,19 +27,11 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
sub save () {
guest_checkrunning($ho,$gho) or die $gho-{Name};
my $err= guest_check_ip($gho); die $err $gho-{Name} if defined $err;
-target_cmd_root($ho,
- toolstack($ho)-{Command}
- . save $gho-{Name} image,
- 200);
+toolstack($ho)-save($gho,image,200);
target_ping_check_down($gho);
}
sub restore () {
-target_cmd_root($ho,
- toolstack($ho)-{Command}
- . restore
- .(toolstack($ho)-{RestoreNeedsConfig} ?
- $r{ $gho-{Guest}.'_'. toolstack($ho)-{CfgPathVar} } :
'')
- . image, 200);
+toolstack($ho)-restore($gho,image, 200);
target_ping_check_up($gho);
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 09/19] Toolstack: Refactor guest lifecycle.
Implement destory/create as per toolstack methods, including
implementing the libvirt version which previously didn't work. To do
this we use the virsh capability to convert an xl/xm style config file
into the correct XML.
xend basically calls into the xl helper since they are compatible.
xl/xm, uses -{Command} which will eventually become private.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v3: Rebased of prototype changes to guest_create/destroy (only $gho)
Use xen-xl format to domxml-from-native rather than xen-xm
Moved spurious change in ts-save-restore to correct home later in
the series.
Suggested switch to passing $gho to -start has been deferred to a
new patch towards the end of the series
---
Osstest/TestSupport.pm | 4 ++--
Osstest/Toolstack/libvirt.pm | 20
Osstest/Toolstack/xl.pm | 13 +
ts-guest-start | 4 +---
ts-windows-install | 7 +--
5 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6124d19..5c753b4 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1328,13 +1328,13 @@ sub guest_await_shutdown ($$$) {
sub guest_destroy ($) {
my ($gho) = @_;
my $ho = $gho-{Host};
-target_cmd_root($ho, toolstack($ho)-{Command}. destroy $gho-{Name},
40);
+toolstack($ho)-destroy($gho);
}
sub guest_create ($) {
my ($gho) = @_;
my $ho = $gho-{Host};
-target_cmd_root($ho, toolstack($ho)-{Command}. create $gho-{CfgPath},
100);
+toolstack($ho)-create($gho-{CfgPath});
}
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 90fe434..0d09ffc 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -20,15 +20,35 @@ package Osstest::Toolstack::libvirt;
use strict;
use warnings;
+use Osstest::TestSupport;
+
sub new {
my ($class, $ho, $methname,$asset) = @_;
return bless { Name = libvirt,
Host = $ho,
NewDaemons = [qw(libvirtd)],
Dom0MemFixed = 1,
+ CfgPathVar = 'cfgpath',
Command = 'virsh',
ExtraPackages = [qw(libnl1 libavahi-client3)],
}, $class;
}
+sub destroy ($$) {
+my ($self,$gho) = @_;
+my $gn = $gho-{Name};
+target_cmd_root($self-{Host}, virsh destroy $gn, 40);
+}
+
+sub create ($$) {
+my ($self,$cfg) = @_;
+my $ho = $self-{Host};
+my $lcfg = $cfg;
+$lcfg =~ s,/,-,g;
+$lcfg = $ho-{Name}--$lcfg;
+target_cmd_root($ho, virsh domxml-from-native xen-xl $cfg $cfg.xml,
30);
+target_getfile_root($ho,60,$cfg.xml, $stash/$lcfg);
+target_cmd_root($ho, virsh create --file $cfg.xml, 100);
+}
+
1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 0b66201..12417ca 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -20,6 +20,8 @@ package Osstest::Toolstack::xl;
use strict;
use warnings;
+use Osstest::TestSupport;
+
sub new {
my ($class, $ho, $methname,$asset) = @_;
return bless { Name = xl,
@@ -32,4 +34,15 @@ sub new {
}, $class;
}
+sub destroy ($$) {
+my ($self,$gho) = @_;
+my $gn = $gho-{Name};
+target_cmd_root($self-{Host}, $self-{Command}. destroy $gn, 40);
+}
+
+sub create ($$) {
+my ($self,$cfg) = @_;
+target_cmd_root($self-{Host}, $self-{Command}. create $cfg, 100);
+}
+
1;
diff --git a/ts-guest-start b/ts-guest-start
index bfbb734..fb6a174 100755
--- a/ts-guest-start
+++ b/ts-guest-start
@@ -26,9 +26,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
sub start () {
guest_umount_lv($ho, $gho);
-my $cmd= toolstack($ho)-{Command}. create .
-$r{ $gho-{Guest}.'_'. toolstack($ho)-{CfgPathVar} };
-target_cmd_root($ho, $cmd, 30);
+toolstack($ho)-create($r{ $gho-{Guest}.'_'. toolstack($ho)-{CfgPathVar}
});
}
sub checkstart () {
diff --git a/ts-windows-install b/ts-windows-install
index 4b06310..7740ee6 100755
--- a/ts-windows-install
+++ b/ts-windows-install
@@ -49,13 +49,8 @@ END
store_runvar($gho-{Guest}_pingbroken, 1);
}
-sub start () {
-target_cmd_root($ho, toolstack($ho)-{Command}.
- create $gho-{CfgPath}, 100);
-}
-
prep();
-start();
+guest_create($gho);
guest_await_dhcp_tcp($gho,7000);
guest_check_up($gho);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 18/19] ts-guest-start: Use guest_create
This allows us to abolish CfgPathVar which was inconsistently used,
appears redundant with $gho-{CfgPath} and in any case never set to
anything other than 'cfgpath'.
I suppose it was intended to deal with toolstacks with a cfg format
completely dissimilar to xm/xl's. I think if this arises in a future
toolstack this functionality could be reintroduced pretty trivially
via the toolstack abstraction which is added by this series.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
v3: Adjust for dropping $ho param to guest_create
---
Osstest/Toolstack/libvirt.pm | 1 -
Osstest/Toolstack/xend.pm| 1 -
Osstest/Toolstack/xl.pm | 1 -
ts-guest-start | 2 +-
4 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index f5f099a..e9d3952 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -28,7 +28,6 @@ sub new {
Host = $ho,
NewDaemons = [qw(libvirtd)],
Dom0MemFixed = 1,
- CfgPathVar = 'cfgpath',
ExtraPackages = [qw(libnl1 libavahi-client3)],
}, $class;
}
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index ed9071b..1d5d059 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -30,7 +30,6 @@ sub new {
NewDaemons = [qw(xend)],
OldDaemonInitd = 'xend',
_Command = 'xm',
- CfgPathVar = 'cfgpath',
Dom0MemFixed = 1,
}, $class;
}
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 7938649..5498c0a 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -29,7 +29,6 @@ sub new {
NewDaemons = [],
Dom0MemFixed = 1,
_Command = 'xl',
- CfgPathVar = 'cfgpath',
RestoreNeedsConfig = 1,
}, $class;
}
diff --git a/ts-guest-start b/ts-guest-start
index fb6a174..1aa9e69 100755
--- a/ts-guest-start
+++ b/ts-guest-start
@@ -26,7 +26,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
sub start () {
guest_umount_lv($ho, $gho);
-toolstack($ho)-create($r{ $gho-{Guest}.'_'. toolstack($ho)-{CfgPathVar}
});
+guest_create($gho);
}
sub checkstart () {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 06/19] Toolstack: use get_host_method_object() to manage toolstack selection
This will allow us to more easily have per-toolstack methods etc.
The previous hash of toolstack parameters is now a blessed object. For
now the callers don't need to change but over the following patches we
will refactor things to use method calls. In particular we will be
aiming to remove Command from the hash and use method calls for
everything.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
v3: Use use parent to pull in xl baseline for xend.
---
Osstest/TestSupport.pm | 37 -
Osstest/Toolstack/libvirt.pm | 34 ++
Osstest/Toolstack/xend.pm| 38 ++
Osstest/Toolstack/xl.pm | 35 +++
4 files changed, 111 insertions(+), 33 deletions(-)
create mode 100644 Osstest/Toolstack/libvirt.pm
create mode 100644 Osstest/Toolstack/xend.pm
create mode 100644 Osstest/Toolstack/xl.pm
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 28d8767..14d6b47 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1864,42 +1864,13 @@ sub guest_vncsnapshot_stash () {
target_getfile_root($ho,100, $rfile, $stash/$leaf);
}
-our %toolstacks=
-('xend' = {
-NewDaemons = [qw(xend)],
-OldDaemonInitd = 'xend',
-Command = 'xm',
-CfgPathVar = 'cfgpath',
-Dom0MemFixed = 1,
-},
- 'xl' = {
-NewDaemons = [],
-Dom0MemFixed = 1,
-Command = 'xl',
-CfgPathVar = 'cfgpath',
- RestoreNeedsConfig = 1,
-},
- 'libvirt' = {
-NewDaemons = [qw(libvirtd)],
-Dom0MemFixed = 1,
-Command = 'virsh',
-ExtraPackages = [qw(libnl1 libavahi-client3)],
-},
- );
-
sub toolstack ($) {
my ($ho) = @_;
return $ho-{Toolstack} if $ho-{Toolstack};
-my $tsname= $r{toolstack};
-$tsname= 'xend' if !defined $tsname;
-my $ts= $toolstacks{$tsname};
-die $tsname ? unless defined $ts;
-if (!exists $ts-{Name}) {
-logm(toolstack $tsname);
-$ts-{Name}= $tsname;
-}
-$ho-{Toolstack} = $ts;
-return $ts;
+
+my $tsname= $r{toolstack} || 'xend';
+$ho-{Toolstack}= get_host_method_object($ho, 'Toolstack', $tsname);
+return $ho-{Toolstack};
}
sub authorized_keys () {
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
new file mode 100644
index 000..90fe434
--- /dev/null
+++ b/Osstest/Toolstack/libvirt.pm
@@ -0,0 +1,34 @@
+# This is part of osstest, an automated testing framework for Xen.
+# Copyright (C) 2014 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+
+package Osstest::Toolstack::libvirt;
+
+use strict;
+use warnings;
+
+sub new {
+my ($class, $ho, $methname,$asset) = @_;
+return bless { Name = libvirt,
+ Host = $ho,
+ NewDaemons = [qw(libvirtd)],
+ Dom0MemFixed = 1,
+ Command = 'virsh',
+ ExtraPackages = [qw(libnl1 libavahi-client3)],
+}, $class;
+}
+
+1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
new file mode 100644
index 000..720bcc8
--- /dev/null
+++ b/Osstest/Toolstack/xend.pm
@@ -0,0 +1,38 @@
+# This is part of osstest, an automated testing framework for Xen.
+# Copyright (C) 2014 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+
+package Osstest::Toolstack::xend;
+
+use strict;
+use warnings;
+
+# Defer to xl driver for most things
+use parent qw(Osstest::Toolstack::xl);
+
+sub new {
+my ($class, $ho, $methname,$asset) = @_;
+return bless { Name = xend,
+ Host = $ho,
+
[Xen-devel] [PATCH v3 11/19] Toolstack: Refactor shutdown support
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v3: Timeout is set in the caller, not the method handler. Different
guests might take different times to shut down - but different
toolstacks shouldn't.
---
Osstest/Toolstack/libvirt.pm | 6 ++
Osstest/Toolstack/xl.pm | 7 +++
ts-guest-stop| 5 +
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index fb9b9a9..7f4180e 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -57,4 +57,10 @@ sub consolecmd ($$) {
return virsh console $gn;
}
+sub shutdown_wait ($$$) {
+my ($self,$gho,$timeout) = @_;
+my $gn = $gho-{Name};
+die libvirt shutdown wait not implemented yet.
+}
+
1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 4997775..f0c15fb 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -51,4 +51,11 @@ sub consolecmd ($$) {
return $self-{Command}. console $gn;
}
+sub shutdown_wait ($$$) {
+my ($self,$gho,$timeout) = @_;
+my $ho = $self-{Host};
+my $gn = $gho-{Name};
+target_cmd_root($ho,$self-{Command} shutdown -w $gn, $timeout);
+}
+
1;
diff --git a/ts-guest-stop b/ts-guest-stop
index 0e3a863..378f334 100755
--- a/ts-guest-stop
+++ b/ts-guest-stop
@@ -26,10 +26,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
sub stop () {
guest_checkrunning($ho, $gho) or die $gho-{Name} not running;
-target_cmd_root($ho,
- toolstack($ho)-{Command}
- . shutdown -w
- .$gho-{Name}, 200);
+toolstack($ho)-shutdown_wait($gho, 200);
guest_checkrunning($ho, $gho) and die $gho-{Name};
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 01/19] TestSupport: Add helper to wait for a guest to shutdown
Refactor the guts of guest_await_reboot into a helper and use for both
shutdown and reboot handling.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v3: Refactor common code with guest_await_reboot.
---
Osstest/TestSupport.pm | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 5ac66e5..b983bd4 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -92,7 +92,8 @@ BEGIN {
guest_umount_lv guest_await guest_await_dhcp_tcp
guest_checkrunning guest_check_ip guest_find_ether
guest_find_domid guest_check_up guest_check_up_quick
- guest_get_state guest_await_reboot guest_destroy
+ guest_get_state guest_await_reboot
+ guest_await_shutdown guest_destroy
guest_vncsnapshot_begin guest_vncsnapshot_stash
guest_check_remus_ok guest_editconfig
host_involves_pcipassthrough host_get_pcipassthrough_devs
@@ -1295,17 +1296,28 @@ sub report_once ($$$) {
$ho-{$k}= $msg;
}
-sub guest_await_reboot ($$$) {
-my ($ho,$gho, $timeout) = @_;
-poll_loop($timeout, 30, await reboot request from $gho-{Guest}, sub {
+sub guest_await_state ($) {
+my ($ho,$gho, $what,$wait_st,$timeout) = @_;
+
+poll_loop($timeout, 30, await $what request from $gho-{Guest}, sub {
my $st= guest_get_state($ho,$gho);
-return undef if $st eq 'sr';
+return undef if $st eq $wait_st;
fail(guest unexpectedly shutdown; state is '$st')
if $st =~ m/^s/ || $st eq '';
-return guest state is $st;
+return guest state is \$st\;
});
}
+sub guest_await_reboot ($$$) {
+my ($ho,$gho, $timeout) = @_;
+return guest_await_state($ho,$gho, reboot, sr, $timeout);
+}
+
+sub guest_await_shutdown ($$$) {
+my ($ho,$gho, $timeout) = @_;
+return guest_await_state($ho,$gho, shutdown, s, $timeout);
+}
+
sub guest_destroy ($$) {
my ($ho,$gho) = @_;
target_cmd_root($ho, toolstack()-{Command}. destroy $gho-{Name}, 40);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 12/19] Toolstack: Refactor migration support check.
Not implemented for libvirt (the check itself that is, the hook is
present).
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
Osstest/Toolstack/libvirt.pm | 5 +
Osstest/Toolstack/xend.pm| 3 +++
Osstest/Toolstack/xl.pm | 9 +
ts-migrate-support-check | 10 +-
4 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 7f4180e..b74c8cb 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -63,4 +63,9 @@ sub shutdown_wait ($$$) {
die libvirt shutdown wait not implemented yet.
}
+sub migrate_check ($) {
+my ($self) = @_;
+die Migration check is not yet supported on libvirt.;
+}
+
1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 720bcc8..8e77a05 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -35,4 +35,7 @@ sub new {
}, $class;
}
+# xend always supported migration
+sub migrate_check ($) { return 0; }
+
1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index f0c15fb..dcf3b08 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -58,4 +58,13 @@ sub shutdown_wait ($$$) {
target_cmd_root($ho,$self-{Command} shutdown -w $gn, $timeout);
}
+sub migrate_check ($) {
+my ($self) = @_;
+my $ho = $self-{Host};
+my $help = target_cmd_output_root($ho, $self-{Command}. help);
+my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
+logm(rc=$rc);
+return $rc;
+}
+
1;
diff --git a/ts-migrate-support-check b/ts-migrate-support-check
index c70b77a..cd41f68 100755
--- a/ts-migrate-support-check
+++ b/ts-migrate-support-check
@@ -24,12 +24,4 @@ tsreadconfig();
our $ho = selecthost($ARGV[0]);
-# all xend/xm platforms support migration
-exit(0) if toolstack($ho)-{Command} eq xm;
-
-my $help = target_cmd_output_root($ho, toolstack($ho)-{Command}. help);
-
-my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
-
-logm(rc=$rc);
-exit($rc);
+exit(toolstack($ho)-migrate_check());
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 12/14] xen-blkback: safely unmap grants in case they are still in use
On 19/01/15 15:51, David Vrabel wrote:
From: Jenny Herbert jennifer.herb...@citrix.com
Use gnttab_unmap_refs_async() to wait until the mapped pages are no
longer in use before unmapping them.
This allows blkback to use network storage which may retain refs to
pages in queued skbs after the block I/O has completed.
Hi Jens,
This xen-blkback change depends on several Xen changes and it would be
easiest if this went via the Xen tree. Are you ok with this?
David
Signed-off-by: Jenny Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/block/xen-blkback/blkback.c | 175
+--
drivers/block/xen-blkback/common.h |3 +
2 files changed, 127 insertions(+), 51 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index 908e630..39a7aba 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -47,6 +47,7 @@
#include asm/xen/hypervisor.h
#include asm/xen/hypercall.h
#include xen/balloon.h
+#include xen/grant_table.h
#include common.h
/*
@@ -262,6 +263,17 @@ static void put_persistent_gnt(struct xen_blkif *blkif,
atomic_dec(blkif-persistent_gnt_in_use);
}
+static void free_persistent_gnts_unmap_callback(int result,
+ struct gntab_unmap_queue_data
*data)
+{
+ struct completion* c = data-data;
+
+ /* BUG_ON used to reproduce existing behaviour,
+but is this the best way to deal with this? */
+ BUG_ON(result);
+ complete(c);
+}
+
static void free_persistent_gnts(struct xen_blkif *blkif, struct rb_root
*root,
unsigned int num)
{
@@ -269,8 +281,17 @@ static void free_persistent_gnts(struct xen_blkif
*blkif, struct rb_root *root,
struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
struct persistent_gnt *persistent_gnt;
struct rb_node *n;
- int ret = 0;
int segs_to_unmap = 0;
+ struct gntab_unmap_queue_data unmap_data;
+ struct completion unmap_completion;
+
+ init_completion(unmap_completion);
+
+ unmap_data.data = unmap_completion;
+ unmap_data.done = free_persistent_gnts_unmap_callback;
+ unmap_data.pages = pages;
+ unmap_data.unmap_ops = unmap;
+ unmap_data.kunmap_ops = NULL;
foreach_grant_safe(persistent_gnt, n, root, node) {
BUG_ON(persistent_gnt-handle ==
@@ -285,9 +306,11 @@ static void free_persistent_gnts(struct xen_blkif
*blkif, struct rb_root *root,
if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
!rb_next(persistent_gnt-node)) {
- ret = gnttab_unmap_refs(unmap, NULL, pages,
- segs_to_unmap);
- BUG_ON(ret);
+
+ unmap_data.count = segs_to_unmap;
+ gnttab_unmap_refs_async(unmap_data);
+ wait_for_completion(unmap_completion);
+
put_free_pages(blkif, pages, segs_to_unmap);
segs_to_unmap = 0;
}
@@ -653,18 +676,14 @@ void xen_blkbk_free_caches(struct xen_blkif *blkif)
shrink_free_pagepool(blkif, 0 /* All */);
}
-/*
- * Unmap the grant references, and also remove the M2P over-rides
- * used in the 'pending_req'.
- */
-static void xen_blkbk_unmap(struct xen_blkif *blkif,
-struct grant_page *pages[],
-int num)
+static unsigned int xen_blkbk_unmap_prepare(
+ struct xen_blkif *blkif,
+ struct grant_page **pages,
+ unsigned int num,
+ struct gnttab_unmap_grant_ref *unmap_ops,
+ struct page **unmap_pages)
{
- struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
- struct page *unmap_pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
unsigned int i, invcount = 0;
- int ret;
for (i = 0; i num; i++) {
if (pages[i]-persistent_gnt != NULL) {
@@ -674,21 +693,99 @@ static void xen_blkbk_unmap(struct xen_blkif *blkif,
if (pages[i]-handle == BLKBACK_INVALID_HANDLE)
continue;
unmap_pages[invcount] = pages[i]-page;
- gnttab_set_unmap_op(unmap[invcount], vaddr(pages[i]-page),
+ gnttab_set_unmap_op(unmap_ops[invcount],
vaddr(pages[invcount]-page),
GNTMAP_host_map, pages[i]-handle);
pages[i]-handle = BLKBACK_INVALID_HANDLE;
- if (++invcount == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
- ret = gnttab_unmap_refs(unmap, NULL, unmap_pages,
- invcount);
+ invcount++;
+ }
+
+ return invcount;
+}
+
+static void xen_blkbk_unmap_done(struct xen_blkif *blkif,
+
Re: [Xen-devel] [PATCH 12/14] xen-blkback: safely unmap grants in case they are still in use
On 23/01/15 16:00, David Vrabel wrote:
On 23/01/15 15:47, Roger Pau Monné wrote:
El 23/01/15 a les 15.54, David Vrabel ha escrit:
On 23/01/15 14:31, Roger Pau Monné wrote:
El 19/01/15 a les 16.51, David Vrabel ha escrit:
+ if (invcount) {
+ ret = gnttab_unmap_refs(unmap, NULL, unmap_pages,
invcount);
BUG_ON(ret);
- put_free_pages(blkif, unmap_pages, invcount);
- invcount = 0;
+ xen_blkbk_unmap_done(blkif, unmap_pages, invcount);
}
- }
- if (invcount) {
- ret = gnttab_unmap_refs(unmap, NULL, unmap_pages, invcount);
- BUG_ON(ret);
- put_free_pages(blkif, unmap_pages, invcount);
+ pages += batch;
+ num -= batch;
This should be fixed to at least be (which is still not fully correct,
but it's better):
pages += invcount;
num -= invcount;
I hope an example will clarify this, suppose we have the following pages
array:
pages[0] = persistent grant
pages[1] = persistent grant
pages[2] = regular grant
pages[3] = persistent grant
pages[4] = regular grant
And batch is 1. In this case, the unmapped grant will be pages[2], but
then due to the code below pages will be updated to point to pages[1],
which has already been scanned. If this was done correctly pages should
point to pages[3]. As said, it's not really a bug, but the loop is
sub-optimal.
Ah ha. Thanks for the clear explanation.
gnttab_blkback_unmap_prepare() stops once its been through the whole
batch regardless of whether it filled the array with ops so we don't
check a page twice but this does mean we have a sub-optimal number of ops.
This is not a hot path (it's only called during error recovery). Are
you happy to leave this as is?
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 33690: regressions - FAIL
On 01/26/2015 09:56 AM, Andrew Cooper wrote: On 26/01/15 14:51, Boris Ostrovsky wrote: On 01/26/2015 09:49 AM, Andrew Cooper wrote: On 26/01/15 11:38, Jan Beulich wrote: On 26.01.15 at 12:04, jbeul...@suse.com wrote: On 24.01.15 at 13:54, ian.jack...@eu.citrix.com wrote: test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637 Jan 24 00:35:16.262627 (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] Jan 24 00:35:16.478599 (XEN) CPU:1 Jan 24 00:35:16.478624 (XEN) RIP:e008:[] Jan 24 00:35:16.486596 (XEN) RFLAGS: 00010082 CONTEXT: hypervisor ... Jan 24 00:35:16.678620 (XEN) Xen call trace: Jan 24 00:35:16.678650 (XEN)[82d0801d36d0] vpmu_do_interrupt+0x2f/0x8a Jan 24 00:35:16.686605 (XEN)[82d08015e242] pmu_apic_interrupt+0x33/0x35 Jan 24 00:35:16.698582 (XEN)[82d080171bf0] do_IRQ+0x9c/0x624 Jan 24 00:35:16.698615 (XEN)[82d080234062] common_interrupt+0x62/0x70 Jan 24 00:35:16.698653 (XEN)[82d08012c6fe] _spin_unlock_irq+0x30/0x31 Jan 24 00:35:16.706604 (XEN)[82d08012bcf1] __do_softirq+0x81/0x8c Jan 24 00:35:16.706638 (XEN)[82d08012bd49] do_softirq+0x13/0x15 Jan 24 00:35:16.718591 (XEN)[82d0801ec4da] vmx_asm_do_vmentry+0x2a/0x50 I think I see what the problem here is: Commit 8097616fbd (x86/VPMU: handle APIC_LVTPC accesses) gives the guest control over LVTPC.mask regardless of whether the vPMU was actually initialized for it. Supposedly in the case above the guest is being run with core2_no_vpmu_ops, which in particular has .do_interrupt == NULL. It's not immediately clear whether vpmu_lvtpc_update() should do the check or its (sole) caller. In any event I'm going to revert that commit as the primary suspect for causing the regression. I have just fallen over this as well. I second a revert in the absence of a clear way to fix the patch. I can't reproduce this -- neither at this patch level nor at full series. Yes, we can test for do_interrupt presence in vpmu_lvtpc_update() (or in vpmu_interrupt() itself) but since we cannot arm the counters (there is no do_wrmsr op) I am not sure I understand what can trigger this interrupt. -boris As Jan explained, The patch in question allows guests (windows in both problematic cases) to arm LVTPC, with a vpmu instance with a NULL pointer for do_interrupt. Right, I understand that. But you'd need to arm the counters (not just APIC) for the interrupt to happen, wouldn't you? And I don't see how that can happen. This issue also appears to happen on debian, so it's not Windows only. In any case, you should indeed revert this until I resend a safer patch. Before I do that I'd like to be able to reproduce this though. -boris When a pmu apic interrupt arrives, the interrupt handler dies from a NULL function pointer dereference. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues
Hey Jan, Andrew, I am hoping you can help me in directing me where I ought to go next in debugging this. This is a Lenovo Thinkpad x230 with the latest BIOS and Xen 4.6 (todays 'staging' + my patches). Initially when I installed Xen the first time it would hang when loading the efi_vars module in Linux. Debugging a bit more and I found out that the issue is that we crash when calling GetNextVariableName (works fine with GetTime/SetTime, hand't tried GetVariable). I decided to implement in the hypervisor a little loop that would call GetNextVariableName and it works on my ASUS M5A87 board nicely. (attached at the bottom for comparison) However on this laptop it keeps on crashing. I've also added a bit of code to get the binary code from the GetNextVariableName to see if it looks legit - and it looks OK (obviously different from what the ASUS has implemented). Anyhow I am bit stuck: 1) It works with Linux, so what is it that Linux does that Xen does not? 2). I can't make sense of the stack trace. I am not entirely sure where it crashes in the firmware code - so I don't know what code to debug/print. I hadn't yet added debugging for the EFI L3/L4 pagetables to figure out the MFNs exactly. Thinking to sprinkle a bunch of printks - but perhaps you know what 1) is in comparison and I can also take that in account? Here is the USB debug (thanks for making that work - makes debugging so much easier!) trace of the crash along along with the decompilation of the assembler code. Full boot on Lenovo ThinkPad x230: Xen 4.6-unstable (XEN) Xen version 4.6-unstable (konrad@) (gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)) debug=y Mon Jan 26 11:01:21 EST 2015 (XEN) Latest ChangeSet: Sun Jan 25 16:50:58 2015 -0500 git:16279eb-dirty (XEN) Bootloader: EFI (XEN) Command line: console=dbgp,vga dbgp=ehci1 loglvl=all iommu=verbose,debug vga=keep (XEN) Video information: (XEN) VGA is graphics mode 1366x768, 32 bpp (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 1 EDD information structures (XEN) EFI RAM map: (XEN) - 0009 (usable) (XEN) 0009 - 000c (reserved) (XEN) 0010 - 2000 (usable) (XEN) 2000 - 2020 (reserved) (XEN) 2020 - 40004000 (usable) (XEN) 40004000 - 40005000 (reserved) (XEN) 40005000 - cfdd (usable) (XEN) cfdd - cffd2000 (reserved) (XEN) cffd2000 - d685 (usable) (XEN) d685 - dae9f000 (reserved) (XEN) dae9f000 - daf9f000 (ACPI NVS) (XEN) daf9f000 - dafff000 (ACPI data) (XEN) dafff000 - db00 (usable) (XEN) db00 - dfa0 (reserved) (XEN) f80f8000 - f80f9000 (reserved) (XEN) fed1c000 - fed2 (reserved) (XEN) 0001 - 00021e60 (usable) (XEN) 00021e60 - 00021e80 (reserved) (XEN) ACPI: RSDP DAFFE014, 0024 (r2 LENOVO) (XEN) ACPI: XSDT DAFFE170, 00C4 (r1 LENOVO TP-G22620 PTL 2) (XEN) ACPI: FACP DAFE5000, 010C (r5 LENOVO TP-G22620 PTL 2) (XEN) ACPI: DSDT DAFE7000, 11383 (r1 LENOVO TP-G22620 INTL 20061109) (XEN) ACPI: FACS DAF5A000, 0040 (XEN) ACPI: SLIC DAFFD000, 0176 (r1 LENOVO TP-G22620 PTL 1) (XEN) ACPI: TCPA DAFFC000, 0032 (r2PTL LENOVO 604 LNVO1) (XEN) ACPI: SSDT DAFFB000, 0408 (r1 LENOVO TP-SSDT2 200 INTL 20061109) (XEN) ACPI: SSDT DAFFA000, 0033 (r1 LENOVO TP-SSDT1 100 INTL 20061109) (XEN) ACPI: SSDT DAFF9000, 07A8 (r1 LENOVO SataAhci 1000 INTL 20061109) (XEN) ACPI: HPET DAFE3000, 0038 (r1 LENOVO TP-G22620 PTL 2) (XEN) ACPI: APIC DAFE2000, 0098 (r1 LENOVO TP-G22620 PTL 2) (XEN) ACPI: MCFG DAFE1000, 003C (r1 LENOVO TP-G22620 PTL 2) (XEN) ACPI: ECDT DAFE, 0052 (r1 LENOVO TP-G22620 PTL 2) (XEN) ACPI: FPDT DAFDF000, 0064 (r1 LENOVO TP-G22620 PTL 2) (XEN) ACPI: ASF! DAFE6000, 00A5 (r32 LENOVO TP-G22620 PTL 2) (XEN) ACPI: UEFI DAFDE000, 003E (r1 LENOVO TP-G22620 PTL 2) (XEN) ACPI: UEFI DAFDD000, 0042 (r1 PTL COMBUF1 PTL 1) (XEN) ACPI: POAT DAFDC000, 0055 (r3 LENOVO TP-G22620 PTL 2) (XEN) ACPI: SSDT DAFDB000, 0C79 (r1 PmRef Cpu0Ist 3000 INTL 20061109) (XEN) ACPI: SSDT DAFDA000, 0A83 (r1 PmRefCpuPm 3000 INTL 20061109) (XEN) ACPI: DMAR DAFD9000, 00B8 (r1 INTEL SNB 1 INTL1) (XEN) ACPI: UEFI DAFD8000, 02A6 (r1 LENOVO TP-G22620 PTL 2) (XEN) ACPI: DBG2 DAFD7000, 00E9 (r0 LENOVO TP-G22620 PTL 2) (XEN) System RAM: 8009MB (8202104kB) (XEN) No NUMA configuration found (XEN) Faking a node at -00021e60 (XEN) Domain heap initialised (XEN) vesafb: framebuffer at 0xe000, mapped to
Re: [Xen-devel] Problem building xon with cross-compiler
On 26.01.15 at 16:38, stefan.ku...@gmx.net wrote: I try to compile xen-4.5.0 in the uclibc buildroot. Of course a first step would be to try to build in a more conventional environment. On make xen I get this error: mkdir -p compat/.xlat grep -v '^[[:blank:]]*#' xlat.lst | sed -ne 's,@arch@,x86_32,g' -re 's,[[:blank:]]+xen\.h[[:blank:]]*$,,p' compat/.xlat/xen.lst.new if ! cmp -s compat/.xlat/xen.lst.new compat/.xlat/xen.lst; then mv -f compat/.xlat/xen.lst.new compat/.xlat/xen.lst; else rm -f compat/.xlat/xen.lst.new; fi export PYTHON=python; \ while read what name; do \ /bin/sh /foo/buildroot/output/build/xen-4.5.0/xen/tools/get-fields.sh $what compat_$name compat/xen.h || exit $?; \ done compat/.xlat/xen.lst compat/.xlat/xen.h.new Fields of 'compat_xenctl_bitmap' not found in 'compat/xen.h' Makefile:70: recipe for target 'compat/.xlat/xen.h' failed make[4]: *** [compat/.xlat/xen.h] Error 1 Has anyone an idea what is going wrong? Perhaps there's something in xen/tools/get-fields.sh that's incompatible with the shell used? I didn't get into it, because compat/xen.h isn't in the sources. It's a generated file, but it ought to be there by the time the command above gets executed, as it's a dependency of the current target being processed. So another reason might be a make incompatibility. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] open-coded page list manipulation in shadow code
Tim, in the course of adding 16Tb support to the hypervisor, I ran into issues with you having added several open-coded page list accesses while breaking up non-order-0 allocations there. I looked at that code for quite a while, but wasn't really able to figure how to properly convert these. In particular I'm struggling with the list terminations (would using NULL for PAGE_LIST_NULL be correct when using ordinary struct list_head-s for struct page_info's list member?) and the implications of this comment /* Page lists don't have pointers back to the head structure, so * it's safe to use a head structure on the stack to link the pages * together. */ in shadow_alloc(), but then again I also didn't look very closely at the other places that also fail to compile. To help myself test the new code, I invented a shadow stub which provides just enough functionality to build and not crash with all the other shadow code compiled out. I wonder whether such a build mode might actually be useful for other purposes, and hence whether it might be worthwhile extracting that from the patch into a standalone one. Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Problem building xon with cross-compiler
Hello, I try to compile xen-4.5.0 in the uclibc buildroot. On make xen I get this error: mkdir -p compat/.xlat grep -v '^[[:blank:]]*#' xlat.lst | sed -ne 's,@arch@,x86_32,g' -re 's,[[:blank:]]+xen\.h[[:blank:]]*$,,p' compat/.xlat/xen.lst.new if ! cmp -s compat/.xlat/xen.lst.new compat/.xlat/xen.lst; then mv -f compat/.xlat/xen.lst.new compat/.xlat/xen.lst; else rm -f compat/.xlat/xen.lst.new; fi export PYTHON=python; \ while read what name; do \ /bin/sh /foo/buildroot/output/build/xen-4.5.0/xen/tools/get-fields.sh $what compat_$name compat/xen.h || exit $?; \ done compat/.xlat/xen.lst compat/.xlat/xen.h.new Fields of 'compat_xenctl_bitmap' not found in 'compat/xen.h' Makefile:70: recipe for target 'compat/.xlat/xen.h' failed make[4]: *** [compat/.xlat/xen.h] Error 1 Has anyone an idea what is going wrong? I didn't get into it, because compat/xen.h isn't in the sources. Kindly regards, Stefan Kuhne ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 0/5] Split off mini-os to a separate tree
Wei Liu writes (Re: [PATCH RFC 0/5] Split off mini-os to a separate tree): Cc Ian and Ian and some folks who might be interested in this work. Thanks. This is all good. I think we need some changes to osstest too because we will want a push gate for xen's minios. I don't think we want to keep hardcoding the minios revision. But that can wait - for now we can do it the way qemu-trad works. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC] xen: arm: context switch vtimer PPI state.
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does)
To do this introduce the concept of routing a PPI to the currently
running VCPU. For such interrupts irq_get_domain returns NULL.
Then we make use of the GICD I[SC]ACTIVER registers to save and
restore the active state of the interrupt, which prevents the nested
invocations which the current masking works around.
For edge triggered interrupts we also need to context switch the
pending bit via I[SC]PENDR. Note that for level triggered interrupts
SPENDR sets a latch which is only cleared by ICPENDR (and not by h/w
state changes), therefore we do not want to context switch the pending
state for level PPIs -- instead we rely on the context switch of the
peripheral to restore the correct level.
RFC Only:
- Not implemented for GIC v3 yet.
- Lightly tested with hackbench on systems with level and edge
triggered vtimer PPI.
- Is irq_get_domain == NULL to indicate route-to-current-vcpu the
best idea? Any alternatives?
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/gic-v2.c| 84 ++
xen/arch/arm/gic.c | 32 +---
xen/arch/arm/irq.c | 48 ++--
xen/arch/arm/time.c | 26 +
xen/arch/arm/vtimer.c| 24 ++--
xen/include/asm-arm/domain.h | 11 ++
xen/include/asm-arm/gic.h| 14 +++
xen/include/asm-arm/irq.h|1 +
8 files changed, 204 insertions(+), 36 deletions(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..9074aca 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -156,6 +156,45 @@ static void gicv2_save_state(struct vcpu *v)
writel_gich(0, GICH_HCR);
}
+static void gicv2_save_and_mask_hwppi(struct vcpu *v, const unsigned virq,
+ struct hwppi_state *s)
+{
+struct pending_irq *p = irq_to_pending(v, virq);
+const unsigned int offs = virq / 32;
+const unsigned int mask = (1u (virq % 32));
+const unsigned int pendingr = readl_gicd(GICD_ISPENDR + offs*4);
+const unsigned int activer = readl_gicd(GICD_ISACTIVER + offs*4);
+const unsigned int enabler = readl_gicd(GICD_ISENABLER + offs*4);
+const bool is_edge = !!(p-desc-arch.type DT_IRQ_TYPE_EDGE_BOTH);
+
+ASSERT(!is_idle_vcpu(v));
+
+s-active = !!(activer mask);
+s-enabled = !!(enabler mask);
+s-pending = !!(pendingr mask);
+s-inprogress = test_and_clear_bit(_IRQ_INPROGRESS, p-desc-status);
+
+/* Write a 1 to IC...R to clear the corresponding bit of state */
+if ( s-active )
+writel_gicd(mask, GICD_ICACTIVER + offs*4);
+/*
+ * For an edge interrupt clear the pending state, for a level interrupt
+ * this clears the latch there is no need since saving the peripheral state
+ * (and/or restoring the next VCPU) will cause the correct action.
+ */
+if ( is_edge s-pending )
+writel_gicd(mask, GICD_ICPENDR + offs*4);
+
+if ( s-enabled )
+{
+writel_gicd(mask, GICD_ICENABLER + offs*4);
+set_bit(_IRQ_DISABLED, p-desc-status);
+}
+
+ASSERT(!(readl_gicd(GICD_ISACTIVER + offs*4) mask));
+ASSERT(!(readl_gicd(GICD_ISENABLER + offs*4) mask));
+}
+
static void gicv2_restore_state(const struct vcpu *v)
{
int i;
@@ -168,6 +207,49 @@ static void gicv2_restore_state(const struct vcpu *v)
writel_gich(GICH_HCR_EN, GICH_HCR);
}
+static void gicv2_restore_hwppi(struct vcpu *v, const unsigned virq,
+const struct hwppi_state *s)
+{
+struct pending_irq *p = irq_to_pending(v, virq);
+const unsigned int offs = virq / 32;
+const unsigned int mask = (1u (virq % 32));
+struct irq_desc *desc = irq_to_desc(virq);
+const bool is_edge = !!(desc-arch.type DT_IRQ_TYPE_EDGE_BOTH);
+struct pending_irq *pending = irq_to_pending(v, virq);
+
+pending-desc = desc; /* Migrate to new physical processor */
+
+/*
+ * The IRQ must always have been set inactive and masked etc by
+ * the saving of the previous state via save_and_mask_hwppi.
+ */
+ASSERT(!(readl_gicd(GICD_ISACTIVER + offs*4) mask));
+ASSERT(!(readl_gicd(GICD_ISENABLER + offs*4) mask));
+
+if ( s-active )
+writel_gicd(mask, GICD_ICACTIVER + offs*4);
+
+/*
+ * Restore pending state for edge triggered interrupts only. For
+ * level triggered interrupts the level will be restored as
+ * necessary by restoring the state of the relevant peripheral.
+ *
+ * For a level triggered interrupt ISPENDR acts as a *latch* which
+ * is only cleared by ICPENDR (i.e. the input level is no longer
+ * relevant). We certainly do not want that here.
+ */
+if ( is_edge s-pending )
+writel_gicd(mask, GICD_ISPENDR + offs*4);
Re: [Xen-devel] [xen-unstable test] 33690: regressions - FAIL
On 26/01/15 14:51, Boris Ostrovsky wrote: On 01/26/2015 09:49 AM, Andrew Cooper wrote: On 26/01/15 11:38, Jan Beulich wrote: On 26.01.15 at 12:04, jbeul...@suse.com wrote: On 24.01.15 at 13:54, ian.jack...@eu.citrix.com wrote: test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637 Jan 24 00:35:16.262627 (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] Jan 24 00:35:16.478599 (XEN) CPU:1 Jan 24 00:35:16.478624 (XEN) RIP:e008:[] Jan 24 00:35:16.486596 (XEN) RFLAGS: 00010082 CONTEXT: hypervisor ... Jan 24 00:35:16.678620 (XEN) Xen call trace: Jan 24 00:35:16.678650 (XEN)[82d0801d36d0] vpmu_do_interrupt+0x2f/0x8a Jan 24 00:35:16.686605 (XEN)[82d08015e242] pmu_apic_interrupt+0x33/0x35 Jan 24 00:35:16.698582 (XEN)[82d080171bf0] do_IRQ+0x9c/0x624 Jan 24 00:35:16.698615 (XEN)[82d080234062] common_interrupt+0x62/0x70 Jan 24 00:35:16.698653 (XEN)[82d08012c6fe] _spin_unlock_irq+0x30/0x31 Jan 24 00:35:16.706604 (XEN)[82d08012bcf1] __do_softirq+0x81/0x8c Jan 24 00:35:16.706638 (XEN)[82d08012bd49] do_softirq+0x13/0x15 Jan 24 00:35:16.718591 (XEN)[82d0801ec4da] vmx_asm_do_vmentry+0x2a/0x50 I think I see what the problem here is: Commit 8097616fbd (x86/VPMU: handle APIC_LVTPC accesses) gives the guest control over LVTPC.mask regardless of whether the vPMU was actually initialized for it. Supposedly in the case above the guest is being run with core2_no_vpmu_ops, which in particular has .do_interrupt == NULL. It's not immediately clear whether vpmu_lvtpc_update() should do the check or its (sole) caller. In any event I'm going to revert that commit as the primary suspect for causing the regression. I have just fallen over this as well. I second a revert in the absence of a clear way to fix the patch. I can't reproduce this -- neither at this patch level nor at full series. Yes, we can test for do_interrupt presence in vpmu_lvtpc_update() (or in vpmu_interrupt() itself) but since we cannot arm the counters (there is no do_wrmsr op) I am not sure I understand what can trigger this interrupt. -boris As Jan explained, The patch in question allows guests (windows in both problematic cases) to arm LVTPC, with a vpmu instance with a NULL pointer for do_interrupt. When a pmu apic interrupt arrives, the interrupt handler dies from a NULL function pointer dereference. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5 v8 4/7] xen: Add vmware_port support
On 01/22/15 03:32, Jan Beulich wrote:
On 21.01.15 at 18:52, dsl...@verizon.com wrote:
On 01/16/15 05:09, Jan Beulich wrote:
On 03.10.14 at 00:40, dsl...@verizon.com wrote:
This is a new domain_create() flag, DOMCRF_vmware_port. It is
passed to domctl as XEN_DOMCTL_CDF_vmware_port.
Can you explain why a HVM param isn't suitable here?
The issue is that you need this flag during construct_vmcb() and
construct_vmcs(). While Intel has vmx_update_exception_bitmap()
AMD does not. So when HVM param's are setup and/or changed there
currently is no way to adjust AMD's exception bitmap.
So this is the simpler way.
But the less desirable one from a design/consistency perspective.
Unless other maintainers disagree, I'd like to see this changed.
Ok, but will wait some time to see if Unless other maintainers disagree
This is both a more complete support then in currently provided by
QEMU and/or KVM and less. The missing part requires QEMU changes
and has been left out until the QEMU patches are accepted upstream.
I vaguely recall the question having been asked before, but I can't
find it to the answer to it: If qemu has support for this, why can't
you build on that rather than adding everything in the hypervisor?
The v10 version of this patch set (which is waiting for an adjusted
QEMU (the released 2.2.0 is one) does use QEMU for more VMware port
support. The issues are:
Was there a newer version of these posted than the v8 I looked at?
If so, I must have overlooked the posting (as otherwise I would of
course have commented on the newer version).
The newer version was being worked on, but had not been posted (and had no
changes to this patch). Since it was never posted, I will just continue
getting v9
(instead of v10) into shape to post.
1) QEMU needs access to parts of CPU registers to handle VMware port.
2) You need to allow ring 3 access to this 1 I/O port.
3) There is more state in xen that would need to also be sent to
QEMU if all support is moved to QEMU.
Understood.
@@ -2111,6 +2112,31 @@ svm_vmexit_do_vmsave(struct vmcb_struct *vmcb,
return;
}
+static void svm_vmexit_gp_intercept(struct cpu_user_regs *regs,
+struct vcpu *v)
+{
+struct vmcb_struct *vmcb = v-arch.hvm_svm.vmcb;
+/*
+ * Just use 15 for the instruction length; vmport_gp_check will
+ * adjust it. This is because
+ * __get_instruction_length_from_list() has issues, and may
+ * require a double read of the instruction bytes. At some
+ * point a new routine could be added that is based on the code
+ * in vmport_gp_check with extensions to make it more general.
+ * Since that routine is the only user of this code this can be
+ * done later.
+ */
+unsigned long inst_len = 15;
Surely this can be unsigned int?
The code is smaller this way. In vmx_vmexit_gp_intercept():
unsigned long inst_len;
...
__vmread(VM_EXIT_INSTRUCTION_LEN, inst_len);
...
rc = vmport_gp_check(regs, v, inst_len, inst_addr,
...
So changing the argument to vmport_gp_check() to unsigned int would
add code there.
So be it then. Generic code shouldn't use odd types just because of
vendor specific code needs it, unless this makes things _a lot_ more
complicated.
Ok. Since It looks like I will not be using get_instruction_length() I will
change this to unsigned int (or should I use unsigned short or
unsigned byte?).
+int rc = X86EMUL_OKAY;
+
+if ( regs-_eax == BDOOR_MAGIC )
With this, is handling other than 32-bit in/out really meaningful/
correct?
Yes. Harder to use, but since VMware allows it, I allow it also.
But then a comment explaining the non-architectural (from an
instruction set perspective) behavior is the minimum that's
needed for future readers (and reviewers) to understand this.
Ok will add.
+case BDOOR_CMD_GETHWVERSION:
+/* vmware_hw */
+regs-_eax = 0;get_instruction_length
+if ( is_hvm_vcpu(curr) )
Since you can't get here for PV, I can't see what you need this
conditional for.
Since I was not 100% sure, I was being safe. Would converting
this to be a debug=y check be ok?
ASSERT() would indeed be the right vehicle.
Will do.
+{
+struct hvm_domain *hd = d-arch.hvm_domain;
+
+regs-_eax = hd-params[HVM_PARAM_VMWARE_HW];
+}
+if ( !regs-_eax )
+regs-_eax = 4; /* Act like version 4 */
Why version 4?
That is the 1st version that VMware was more consistent in the handling
of the VMware hardware version. Any value between 1 and 6 would be
ok. This should only happen in strange configs.
Please make the comment say so then.
Will do.
+/* hostUsecs */
+regs-_ebx =value / 100ULL;
+/* maxTimeLag */
+regs-_ecx = 100;
+break;
Perhaps this should share code
[Xen-devel] Xen Project Document Day this Wednesday, January 28: The Great 4.5 Clean-Up
We want to begin this year by making sure that our documentation is correct for the recent 4.5 release. Do you have new feature information? Do you see old information which will confuse new users (especially those which rely on the xm command instead of xl)? Do you know of best practices which change in the 4.5 release? This is the day to focus on cleaning up these things and anything else relating to the 4.5 release. All the information you need to participate in Document Day is here: http://wiki.xenproject.org/wiki/Xen_Document_Days Also take a look at the current TODO list to see other items which need attention: http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO Please think about how you can help out. If you haven't requested to be made a Wiki editor, save time and do it now so you are ready to go on Document Day. Just fill out the form below: http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html We hope to see you Wednesday in #xendocs! ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5 v8 4/7] xen: Add vmware_port support
On 26.01.15 at 16:58, dsl...@verizon.com wrote:
On 01/22/15 03:32, Jan Beulich wrote:
On 21.01.15 at 18:52, dsl...@verizon.com wrote:
On 01/16/15 05:09, Jan Beulich wrote:
On 03.10.14 at 00:40, dsl...@verizon.com wrote:
+
+/* Only adjust byte_cnt 1 time */
+if ( bytes[0] == 0x66 ) /* operand size prefix */
+{
+if ( byte_cnt == 4 )
+byte_cnt = 2;
+else
+byte_cnt = 4;
+}
Iirc REX.W set following 0x66 cancels the effect of the latter. Another
thing x86emul would be taking care of for you if you used it.
I did not know this. Most of my testing was done without any check
for prefix(s). I.E. (Open) VMware Tools only uses the inl. I do
not know of anybody using 16bit segments and VMware tools.
But this isn't the perspective to take when adding code to the
hypervisor - you should always consider what a (perhaps
malicious) guest could do.
Ok, but my read of this statement does not help decide which way
to go. I see several options:
1) Only allow #GP to work for 0xed (inl (%dx),%eax).
Pros: No attack surface for malicious guest.
No need for get_instruction_length().
No need for Intel to confirm the necessary hardware
behaviour as being architectural.
Cons: There may exist user apps. that work on VMware and
not on xen (16bit segments, realmode, vm86, etc).
2) Only allow #GP to work for all 4 I/O instructions without prefix.
Pros: No attack surface for malicious guest.
No need for get_instruction_length().
No need for Intel to confirm the necessary hardware
behaviour as being architectural.
Cons: There may exist user apps. that work on VMware and
not on xen (16bit segments, realmode, vm86, etc).
3) Only allow zero or one 0x66 prefix and 0xed (inl (%dx),%eax).
Pros: No attack surface for malicious guest.
No need for get_instruction_length().
No need for Intel to confirm the necessary hardware
behaviour as being architectural.
Cons: There may exist user apps. that work on VMware and
not on xen (using too many prefixes, using other
opcodes).
4) Only allow zero or one 0x66 prefix and all 4 I/O instructions.
Pros: No attack surface for malicious guest.
No need for get_instruction_length().
No need for Intel to confirm the necessary hardware
behaviour as being architectural.
Cons: There may exist user apps. that work on VMware and
not on xen (using too many prefixes).
5) Only allow zero to 14 0x66 prefix and 0xed (inl (%dx),%eax).
Pros: No attack surface for malicious guest.
Cons: There may exist user apps. that work on VMware and
not on xen (using unneeded prefixes, using other
opcodes).
5a:Would be cleaner with get_instruction_length() on Intel,
but would need for Intel to confirm the necessary hardware
behaviour as being architectural.
5b: Always pass in MAX_INST_LEN.
6) Only allow zero to 14 0x66 prefix and all 4 I/O instructions.
Pros: No attack surface for malicious guest.
Cons: There may exist user apps. that work on VMware and
not on xen (using unneeded prefixes).
6a:Would be cleaner with get_instruction_length() on Intel,
but would need for Intel to confirm the necessary hardware
behaviour as being architectural.
6b: Always pass in MAX_INST_LEN.
7) Add complete prefix handling, and all 4 I/O instructions
Pros: Limited attack surface for malicious guest (the handling
of all prefixes greatly increases the complexity of the
code).
Cons: Lots of added code.
7a:Would be cleaner with get_instruction_length() on Intel,
but would need for Intel to confirm the necessary hardware
behaviour as being architectural.
7b: Always pass in MAX_INST_LEN.
8) Use hvm_emulate_one().
Pros: shares code, reduces new code.
Cons: Adds a lot of attack surface for malicious guest.
I had picked #6, you asked for #8, but I read your answer as do not
do #8.
I don't think it can or should be read that way; in particular - without
having seen it to be the case in whatever code it takes - I don't buy
the argument of this adding a lot of attack surface: The emulator
code is there anyway.
I would be happy to go with any of the 8 ways (or a way I did not list
above),
just need to know which one to focus on.
As stated before - if feasible, 8 would seem the best option. The
second best one would be to support all four I/O insns (assuming
VMware supports all of them too) with any legal (even if pointless
or redundant)
[Xen-devel] [PATCH v2 22/29] Ovmf/Xen: implement XenHypercallLib for ARM
This patch adds an implementation of XenHypercallLib for both AArch64 and AArch32 execution modes on ARM systems. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h| 436 +++ OvmfPkg/Include/IndustryStandard/Xen/xen.h | 2 +- OvmfPkg/Library/XenHypercallLib/Aarch64/Hypercall.S| 26 ++ OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S| 25 + OvmfPkg/Library/XenHypercallLib/XenHypercallLibArm.inf | 40 5 files changed, 528 insertions(+), 1 deletion(-) diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h new file mode 100644 index ..655a221f6337 --- /dev/null +++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h @@ -0,0 +1,436 @@ +/** + * arch-arm.h + * + * Guest OS interface to ARM Xen. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the Software), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright 2011 (C) Citrix Systems + */ + +#ifndef __XEN_PUBLIC_ARCH_ARM_H__ +#define __XEN_PUBLIC_ARCH_ARM_H__ + +/* + * `incontents 50 arm_abi Hypercall Calling Convention + * + * A hypercall is issued using the ARM HVC instruction. + * + * A hypercall can take up to 5 arguments. These are passed in + * registers, the first argument in x0/r0 (for arm64/arm32 guests + * respectively irrespective of whether the underlying hypervisor is + * 32- or 64-bit), the second argument in x1/r1, the third in x2/r2, + * the forth in x3/r3 and the fifth in x4/r4. + * + * The hypercall number is passed in r12 (arm) or x16 (arm64). In both + * cases the relevant ARM procedure calling convention specifies this + * is an inter-procedure-call scratch register (e.g. for use in linker + * stubs). This use does not conflict with use during a hypercall. + * + * The HVC ISS must contain a Xen specific TAG: XEN_HYPERCALL_TAG. + * + * The return value is in x0/r0. + * + * The hypercall will clobber x16/r12 and the argument registers used + * by that hypercall (except r0 which is the return value) i.e. in + * addition to x16/r12 a 2 argument hypercall will clobber x1/r1 and a + * 4 argument hypercall will clobber x1/r1, x2/r2 and x3/r3. + * + * Parameter structs passed to hypercalls are laid out according to + * the Procedure Call Standard for the ARM Architecture (AAPCS, AKA + * EABI) and Procedure Call Standard for the ARM 64-bit Architecture + * (AAPCS64). Where there is a conflict the 64-bit standard should be + * used regardless of guest type. Structures which are passed as + * hypercall arguments are always little endian. + * + * All memory which is shared with other entities in the system + * (including the hypervisor and other guests) must reside in memory + * which is mapped as Normal Inner-cacheable. This applies to: + * - hypercall arguments passed via a pointer to guest memory. + * - memory shared via the grant table mechanism (including PV I/O + *rings etc). + * - memory shared with the hypervisor (struct shared_info, struct + *vcpu_info, the grant table, etc). + * + * Any Inner cache allocation strategy (Write-Back, Write-Through etc) + * is acceptable. There is no restriction on the Outer-cacheability. + */ + +/* + * `incontents 55 arm_hcall Supported Hypercalls + * + * Xen on ARM makes extensive use of hardware facilities and therefore + * only a subset of the potential hypercalls are required. + * + * Since ARM uses second stage paging any machine/physical addresses + * passed to hypercalls are Guest Physical Addresses (Intermediate + * Physical Addresses) unless otherwise noted. + * + * The following hypercalls (and sub operations) are supported on the + * ARM platform. Other hypercalls should be considered + * unavailable/unsupported. + * + *
[Xen-devel] [PATCH v2 29/29] ArmVirtualizationPkg: add platform description for Xen guests
This adds the .dsc and .fdf descriptions to build a UEFI image that is bootable by a Xen guest on 64-bit ARM (AArch64) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc | 279 +++ ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.fdf | 337 + 2 files changed, 616 insertions(+) diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc new file mode 100644 index ..bcc9742c6828 --- /dev/null +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc @@ -0,0 +1,279 @@ +# +# Copyright (c) 2011-2013, ARM Limited. All rights reserved. +# Copyright (c) 2014, Linaro Limited. All rights reserved. +# +# This program and the accompanying materials +# are licensed and made available under the terms and conditions of the BSD License +# which accompanies this distribution. The full text of the license may be found at +# http://opensource.org/licenses/bsd-license.php +# +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +# +# + + +# +# Defines Section - statements that will be processed to create a Makefile. +# + +[Defines] + PLATFORM_NAME = ArmVirtualizationQemu + PLATFORM_GUID = 37d7e986-f7e9-45c2-8067-e371421a626c + PLATFORM_VERSION = 0.1 + DSC_SPECIFICATION = 0x00010005 + OUTPUT_DIRECTORY = Build/ArmVirtualizationXen-$(ARCH) + SUPPORTED_ARCHITECTURES= AARCH64 + BUILD_TARGETS = DEBUG|RELEASE + SKUID_IDENTIFIER = DEFAULT + FLASH_DEFINITION = ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.fdf + +!include ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization.dsc.inc + +[LibraryClasses] + SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf + RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf + XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLibArm.inf + XenIoMmioLib|ArmPlatformPkg/ArmVirtualizationPkg/Library/XenIoMmioLib/XenIoMmioLib.inf + +[LibraryClasses.AARCH64] + ArmLib|ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf + ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexAEMv8Lib/ArmCortexAEMv8Lib.inf + +[LibraryClasses.ARM] + ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf + ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf + +[LibraryClasses.common] + # Virtio Support + VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf + VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf + + ArmPlatformLib|ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf + ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf + + TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf + +!ifdef INTEL_BDS + CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf + GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf + PlatformBdsLib|ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf + CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf +!endif + +[LibraryClasses.common.UEFI_DRIVER] + UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf + +[LibraryClasses.AARCH64.SEC] + ArmLib|ArmPkg/Library/ArmLib/AArch64/AArch64LibSec.inf + +[LibraryClasses.ARM.SEC] + ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf + +[BuildOptions] + RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 -I$(WORKSPACE)/ArmPlatformPkg/ArmVirtualizationPkg/Include + GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 -I$(WORKSPACE)/ArmPlatformPkg/ArmVirtualizationPkg/Include + GCC:*_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmPlatformPkg/ArmVirtualizationPkg/Include + + +# +# Pcd Section - list of all EDK II PCD Entries defined by this Platform +# + + +[PcdsFeatureFlag.common] + ## If TRUE, Graphics Output Protocol will be installed on virtual handle created by ConsplitterDxe. + # It could be set FALSE to save size. + gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|FALSE + +[PcdsFixedAtBuild.common] + gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x804F + +
[Xen-devel] [PATCH v2 28/29] ArmVirtualizationPkg/VirtFdtDxe: wire up XenBusDxe to xen, xen DT node
This patchs adds support to VirtFdtDxe for the Xen DT node which
contains the base address of the Grant Table. This data is communicated
to XenBusDxe using a XENIO_PROTOCOL instance.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c | 23
+++
ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf | 1 +
2 files changed, 24 insertions(+)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
index 34fac40fa803..1ceb85146430 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
@@ -26,6 +26,7 @@
#include Library/DxeServicesLib.h
#include Library/HobLib.h
#include libfdt.h
+#include Library/XenIoMmioLib.h
#include Guid/Fdt.h
#include Guid/VirtioMmioTransport.h
@@ -49,6 +50,7 @@ typedef enum {
PropertyTypePsci,
PropertyTypeFwCfg,
PropertyTypeGicV3,
+ PropertyTypeXen,
} PROPERTY_TYPE;
typedef struct {
@@ -66,6 +68,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
{ PropertyTypePsci,arm,psci-0.2},
{ PropertyTypeFwCfg, qemu,fw-cfg-mmio},
{ PropertyTypeGicV3, arm,gic-v3 },
+ { PropertyTypeXen, xen,xen },
{ PropertyTypeUnknown, }
};
@@ -332,6 +335,26 @@ InitializeVirtFdtDxe (
}
break;
+case PropertyTypeXen:
+ ASSERT (Len == 16);
+
+ //
+ // Retrieve the reg base from this node and add it to a
+ // XENIO_PROTOCOL instance installed on a new handle.
+ //
+ RegBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
+ Handle = NULL;
+ Status = XenIoMmioInstall (Handle, RegBase);
+ if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, %a: Failed to install XENIO_PROTOCOL on a new
handle
+ (Status == %r)\n, __FUNCTION__, Status));
+break;
+ }
+
+ DEBUG ((EFI_D_INFO, Found Xen node with Grant table @ 0x%p\n,
RegBase));
+
+ break;
+
default:
break;
}
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
index 1392c7c3fa45..f8a58238c37b 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
@@ -41,6 +41,7 @@
FdtLib
VirtioMmioDeviceLib
HobLib
+ XenIoMmioLib
[Guids]
gFdtTableGuid
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 27/29] ArmVirtualizationPkg: add XenIoMmioLib
This adds a XenIoMmioLib declaration and implementation that can
be invoked to install the XENIO_PROTOCOL and a corresponding
grant table address on a EFI handle.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec | 6
+
ArmPlatformPkg/ArmVirtualizationPkg/Include/Library/XenIoMmioLib.h| 20
+++
ArmPlatformPkg/ArmVirtualizationPkg/Library/XenIoMmioLib/XenIoMmioLib.c | 91
+
ArmPlatformPkg/ArmVirtualizationPkg/Library/XenIoMmioLib/XenIoMmioLib.inf | 38
+
4 files changed, 155 insertions(+)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
index 868488906643..c690f1481093 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
@@ -30,6 +30,12 @@
[Includes.common]
Include# Root include for the package
+[LibraryClasses]
+ #
+ # library to create handles containing the XENIO_PROTOCOL I/O protocol
+ #
+ XenIoMmioLib|Include/Library/XenIoMmioLib.h
+
[Guids.common]
gArmVirtualizationTokenSpaceGuid = { 0x0B6F5CA7, 0x4F53, 0x445A, { 0xB7,
0x6E, 0x2E, 0x36, 0x5B, 0x80, 0x63, 0x66 } }
gEarlyPL011BaseAddressGuid = { 0xB199DEA9, 0xFD5C, 0x4A84, { 0x80,
0x82, 0x2F, 0x41, 0x70, 0x78, 0x03, 0x05 } }
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Include/Library/XenIoMmioLib.h
b/ArmPlatformPkg/ArmVirtualizationPkg/Include/Library/XenIoMmioLib.h
new file mode 100644
index ..faeabe5affe0
--- /dev/null
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/Include/Library/XenIoMmioLib.h
@@ -0,0 +1,20 @@
+/** @file
+* Library to install the XENIO_PROTOCOL on a handle
+*
+* Copyright (c) 2015, Linaro Ltd. All rights reserved.BR
+*
+* This program and the accompanying materials are
+* licensed and made available under the terms and conditions of the BSD
License
+* which accompanies this distribution. The full text of the license may be
found at
+* http://opensource.org/licenses/bsd-license.php
+*
+* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+*
+**/
+
+EFI_STATUS
+XenIoMmioInstall (
+ IN EFI_HANDLE *Handle,
+ IN UINT64 GrantTableAddress
+ );
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/XenIoMmioLib/XenIoMmioLib.c
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/XenIoMmioLib/XenIoMmioLib.c
new file mode 100644
index ..2d8413638680
--- /dev/null
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/Library/XenIoMmioLib/XenIoMmioLib.c
@@ -0,0 +1,91 @@
+/** @file
+* Library to install the XENIO_PROTOCOL on a handle
+*
+* Copyright (c) 2015, Linaro Ltd. All rights reserved.BR
+*
+* This program and the accompanying materials are
+* licensed and made available under the terms and conditions of the BSD
License
+* which accompanies this distribution. The full text of the license may be
found at
+* http://opensource.org/licenses/bsd-license.php
+*
+* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+*
+**/
+
+#include Library/BaseLib.h
+#include Library/UefiBootServicesTableLib.h
+#include Library/DebugLib.h
+#include Library/UefiLib.h
+#include Library/BaseMemoryLib.h
+#include Library/MemoryAllocationLib.h
+#include Library/DevicePathLib.h
+#include Library/XenIoMmioLib.h
+
+#include Protocol/XenIo.h
+#include Guid/XenBusRootDevice.h
+
+#pragma pack (1)
+typedef struct {
+ VENDOR_DEVICE_PATH Vendor;
+ EFI_DEVICE_PATH_PROTOCOLEnd;
+} XENBUS_ROOT_DEVICE_PATH;
+#pragma pack ()
+
+EFI_STATUS
+XenIoMmioInstall (
+ IN EFI_HANDLE *Handle,
+ IN UINT64 GrantTableAddress
+ )
+{
+ EFI_STATUS Status;
+ XENIO_PROTOCOL *XenIo;
+ XENBUS_ROOT_DEVICE_PATH*XenBusDevicePath;
+
+ ASSERT (Handle != NULL);
+
+ XenIo = AllocateZeroPool (sizeof *XenIo);
+ ASSERT (XenIo != NULL);
+ XenIo-GrantTableAddress = GrantTableAddress;
+
+ XenBusDevicePath = (XENBUS_ROOT_DEVICE_PATH *)CreateDeviceNode (
+HARDWARE_DEVICE_PATH,
+HW_VENDOR_DP,
+sizeof (XENBUS_ROOT_DEVICE_PATH));
+ if (XenBusDevicePath == NULL) {
+DEBUG ((EFI_D_ERROR, %a: Out of memory\n, __FUNCTION__));
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ CopyMem (XenBusDevicePath-Vendor.Guid, gXenBusRootDeviceGuid,
+sizeof (EFI_GUID));
+ SetDevicePathNodeLength (XenBusDevicePath-Vendor,
+sizeof (*XenBusDevicePath) - sizeof (XenBusDevicePath-End));
+ SetDevicePathEndNode
[Xen-devel] [PATCH v2 20/29] Ovmf/Xen: add separate driver for Xen PCI device
Prepare for making XenBusDxe suitable for use with non-PCI devices
(such as the DT node exposed by Xen on ARM) by introducing a separate
DXE driver that binds to the Xen virtual PCI device and exposes the
abstract XENIO_PROTOCOL for XenBusDxe to bind against.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/XenIoPciDxe/XenIoPciDxe.c | 365
++
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf | 45 +
2 files changed, 410 insertions(+)
diff --git a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.c
b/OvmfPkg/XenIoPciDxe/XenIoPciDxe.c
new file mode 100644
index ..8c91590f7eb5
--- /dev/null
+++ b/OvmfPkg/XenIoPciDxe/XenIoPciDxe.c
@@ -0,0 +1,365 @@
+/** @file
+
+ Driver for the virtual Xen PCI device
+
+ Copyright (C) 2012, Red Hat, Inc.
+ Copyright (c) 2012, Intel Corporation. All rights reserved.BR
+ Copyright (C) 2013, ARM Ltd.
+ Copyright (C) 2015, Linaro Ltd.
+
+ This program and the accompanying materials are licensed and made available
+ under the terms and conditions of the BSD License which accompanies this
+ distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, WITHOUT
+ WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include IndustryStandard/Acpi.h
+#include IndustryStandard/Pci.h
+#include Library/BaseMemoryLib.h
+#include Library/DebugLib.h
+#include Library/MemoryAllocationLib.h
+#include Library/UefiBootServicesTableLib.h
+#include Library/UefiLib.h
+
+#include Protocol/PciIo.h
+#include Protocol/XenIo.h
+
+#define PCI_VENDOR_ID_XEN0x5853
+#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001
+
+/**
+
+ Device probe function for this driver.
+
+ The DXE core calls this function for any given device in order to see if the
+ driver can drive the device.
+
+ @param[in] ThisThe EFI_DRIVER_BINDING_PROTOCOL object
+ incorporating this driver (independently of
+ any device).
+
+ @param[in] DeviceHandle The device to probe.
+
+ @param[in] RemainingDevicePath Relevant only for bus drivers, ignored.
+
+
+ @retval EFI_SUCCESS The driver supports the device being probed.
+
+ @retval EFI_UNSUPPORTED The driver does not support the device being probed.
+
+ @return Error codes from the OpenProtocol() boot service or
+ the PciIo protocol.
+
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+XenIoPciDeviceBindingSupported (
+ IN EFI_DRIVER_BINDING_PROTOCOL *This,
+ IN EFI_HANDLE DeviceHandle,
+ IN EFI_DEVICE_PATH_PROTOCOL*RemainingDevicePath
+ )
+{
+ EFI_STATUS Status;
+ EFI_PCI_IO_PROTOCOL *PciIo;
+ PCI_TYPE00 Pci;
+
+ //
+ // Attempt to open the device with the PciIo set of interfaces. On success,
+ // the protocol is instantiated for the PCI device. Covers duplicate open
+ // attempts (EFI_ALREADY_STARTED).
+ //
+ Status = gBS-OpenProtocol (
+ DeviceHandle, // candidate device
+ gEfiPciIoProtocolGuid, // for generic PCI access
+ (VOID **)PciIo,// handle to instantiate
+ This-DriverBindingHandle, // requestor driver identity
+ DeviceHandle, // ControllerHandle, according to
+ // the UEFI Driver Model
+ EFI_OPEN_PROTOCOL_BY_DRIVER // get exclusive PciIo access to
+ // the device; to be released
+ );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ //
+ // Read entire PCI configuration header for more extensive check ahead.
+ //
+ Status = PciIo-Pci.Read (
+PciIo,// (protocol, device)
+ // handle
+EfiPciIoWidthUint32, // access width copy
+ // mode
+0,// Offset
+sizeof Pci / sizeof (UINT32), // Count
+Pci // target buffer
+);
+
+ if (Status == EFI_SUCCESS) {
+if ((Pci.Hdr.VendorId == PCI_VENDOR_ID_XEN)
+(Pci.Hdr.DeviceId == PCI_DEVICE_ID_XEN_PLATFORM)) {
+ Status = EFI_SUCCESS;
+} else {
+ Status = EFI_UNSUPPORTED;
+}
+ }
+
+ //
+ // We needed PCI IO access only transitorily, to see whether we support the
+ // device or not.
+ //
+ gBS-CloseProtocol (DeviceHandle, gEfiPciIoProtocolGuid,
+ This-DriverBindingHandle, DeviceHandle);
+
+ return
[Xen-devel] [PATCH v2 14/29] ArmVirtualizationPkg: Xen/PV relocatable platformlib instance
Add a ArmPlatformLib instance that can deal with the self relocation
and truly dynamic discovery of system RAM base and size.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
.../ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/MemnodeParser.S
| 232 +++
.../ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/RelocatableVirtHelper.S
| 161
.../ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf
| 59
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c
| 71 +++
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c
| 83 +
5 files changed, 606 insertions(+)
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/MemnodeParser.S
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/MemnodeParser.S
new file mode 100644
index ..cce2c4800c51
--- /dev/null
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/MemnodeParser.S
@@ -0,0 +1,232 @@
+/*
+ * Copyright (c) 2014, Linaro Ltd. All rights reserved.
+ *
+ * This program and the accompanying materials
+ * are licensed and made available under the terms and conditions of the BSD
License
+ * which accompanies this distribution. The full text of the license may be
found at
+ * http://opensource.org/licenses/bsd-license.php
+ *
+ * THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+ * WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+ */
+
+/*
+ * Theory of operation
+ * ---
+ *
+ * This code parses a Flattened Device Tree binary (DTB) to find the base of
+ * system RAM. It is written in assembly so that it can be executed before a
+ * stack has been set up.
+ *
+ * To find the base of system RAM, we have to traverse the FDT to find a memory
+ * node. In the context of this implementation, the first node that has a
+ * device_type property with the value 'memory' and a 'reg' property is
+ * acceptable, and the name of the node (memory[@xxx]) is ignored, as are any
+ * other nodes that match the above constraints.
+ *
+ * In pseudo code, this implementation does the following:
+ *
+ * for each node {
+ * have_device_type = false
+ * have_reg = false
+ *
+ * for each property {
+ * if property value == 'memory' {
+ * if property name == 'device_type' {
+ * have_device_type = true
+ * }
+ * } else {
+ * if property name == 'reg' {
+ * have_reg = true
+ * membase = property value[0]
+ * memsize = property value[1]
+ * }
+ * }
+ * }
+ * if have_device_type and have_reg {
+ * return membase and memsize
+ * }
+ * }
+ * return NOT_FOUND
+ */
+
+#define FDT_MAGIC 0xedfe0dd0
+
+#define FDT_BEGIN_NODE 0x1
+#define FDT_END_NODE 0x2
+#define FDT_PROP 0x3
+#define FDT_END0x9
+
+ xMEMSIZE.reqx0
+ xMEMBASE.reqx1
+
+ xLR .reqx8
+ xDTP.reqx9
+ xSTRTAB .reqx10
+ xMEMNODE.reqx11
+
+ .text
+ .align 3
+_memory:
+ .asciz memory
+_reg:
+ .asciz reg
+_device_type:
+ .asciz device_type
+
+ /*
+* Compare strings in x4 and x5, return in w7
+*/
+ .align 3
+strcmp:
+ ldrbw2, [x4], #1
+ ldrbw3, [x5], #1
+ subsw7, w2, w3
+ cbz w2, 0f
+ cbz w3, 0f
+ beq strcmp
+0: ret
+
+ .globl find_memnode
+find_memnode:
+ // preserve link register
+ mov xLR, x30
+ mov xDTP, x0
+ mov xMEMNODE, #0
+
+ /*
+* Check the DTB magic at offset 0
+*/
+ movzw4, #:abs_g0_nc:FDT_MAGIC
+ movkw4, #:abs_g1:FDT_MAGIC
+ ldr w5, [xDTP]
+ cmp w4, w5
+ bne err_invalid_magic
+
+ /*
+* Read the string offset and store it for later use
+*/
+ ldr w4, [xDTP, #12]
+ rev w4, w4
+ add xSTRTAB, xDTP, x4
+
+ /*
+* Read the struct offset and add it to the DT pointer
+*/
+ ldr w5, [xDTP, #8]
+ rev w5, w5
+ add xDTP, xDTP, x5
+
+ /*
+* Check current tag for FDT_BEGIN_NODE
+*/
+ ldr w5, [xDTP]
+ rev w5, w5
+ cmp w5, #FDT_BEGIN_NODE
+ bne err_unexpected_begin_tag
+
+begin_node:
+ mov xMEMNODE, #0
+ add xDTP, xDTP, #4
+
+ /*
+*
[Xen-devel] [PATCH v2 17/29] Ovmf/Xen: refactor XenBusDxe hypercall implementation
This refactors the Xen hypercall implementation that is part of the
XenBusDxe driver, in preparation of splitting it off entirely into
a XenHypercallLib library. This involves:
- removing the dependency on XENBUS_DEVICE* pointers in the XenHypercall()
prototypes
- moving the discovered hyperpage address to a global variable
- moving XenGetSharedInfoPage() to its only user XenBusDxe.c (the shared info
page is not strictly part of the Xen hypercall interface, and is not used
by other expected users of XenHypercallLib such as the Xen console version
of SerialPortLib
- reimplement XenHypercall2() in C and move the indexing of the hyperpage
there; the existing asm implementations are renamed to __XenHypercall2() and
invoked from the new C implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/XenBusDxe/EventChannel.c | 11 +++
OvmfPkg/XenBusDxe/GrantTable.c| 4 ++--
OvmfPkg/XenBusDxe/Ia32/hypercall.nasm | 6 +++---
OvmfPkg/XenBusDxe/X64/hypercall.nasm | 6 +++---
OvmfPkg/XenBusDxe/XenBusDxe.c | 44
+++-
OvmfPkg/XenBusDxe/XenBusDxe.h | 1 -
OvmfPkg/XenBusDxe/XenHypercall.c | 50
++
OvmfPkg/XenBusDxe/XenHypercall.h | 28 +++-
OvmfPkg/XenBusDxe/XenStore.c | 4 ++--
9 files changed, 73 insertions(+), 81 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/EventChannel.c b/OvmfPkg/XenBusDxe/EventChannel.c
index 03efaf9cb904..a86323e6adfd 100644
--- a/OvmfPkg/XenBusDxe/EventChannel.c
+++ b/OvmfPkg/XenBusDxe/EventChannel.c
@@ -28,7 +28,7 @@ XenEventChannelNotify (
evtchn_send_t Send;
Send.port = Port;
- ReturnCode = XenHypercallEventChannelOp (Dev, EVTCHNOP_send, Send);
+ ReturnCode = XenHypercallEventChannelOp (EVTCHNOP_send, Send);
return (UINT32)ReturnCode;
}
@@ -40,15 +40,12 @@ XenBusEventChannelAllocate (
OUT evtchn_port_t *Port
)
{
- XENBUS_PRIVATE_DATA *Private;
evtchn_alloc_unbound_t Parameter;
UINT32 ReturnCode;
- Private = XENBUS_PRIVATE_DATA_FROM_THIS (This);
-
Parameter.dom = DOMID_SELF;
Parameter.remote_dom = DomainId;
- ReturnCode = (UINT32)XenHypercallEventChannelOp (Private-Dev,
+ ReturnCode = (UINT32)XenHypercallEventChannelOp (
EVTCHNOP_alloc_unbound,
Parameter);
if (ReturnCode != 0) {
@@ -79,10 +76,8 @@ XenBusEventChannelClose (
IN evtchn_port_t Port
)
{
- XENBUS_PRIVATE_DATA *Private;
evtchn_close_t Close;
- Private = XENBUS_PRIVATE_DATA_FROM_THIS (This);
Close.port = Port;
- return (UINT32)XenHypercallEventChannelOp (Private-Dev, EVTCHNOP_close,
Close);
+ return (UINT32)XenHypercallEventChannelOp (EVTCHNOP_close, Close);
}
diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
index 8405edc51bc4..53cb99f0e004 100644
--- a/OvmfPkg/XenBusDxe/GrantTable.c
+++ b/OvmfPkg/XenBusDxe/GrantTable.c
@@ -161,7 +161,7 @@ XenGrantTableInit (
Parameters.idx = Index;
Parameters.space = XENMAPSPACE_grant_table;
Parameters.gpfn = (xen_pfn_t) ((UINTN) GrantTable EFI_PAGE_SHIFT) +
Index;
-ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_add_to_physmap,
Parameters);
+ReturnCode = XenHypercallMemoryOp (XENMEM_add_to_physmap, Parameters);
if (ReturnCode != 0) {
DEBUG ((EFI_D_ERROR, Xen GrantTable, add_to_physmap hypercall error:
%d\n, ReturnCode));
}
@@ -184,7 +184,7 @@ XenGrantTableDeinit (
Parameters.domid = DOMID_SELF;
Parameters.gpfn = (xen_pfn_t) ((UINTN) GrantTable EFI_PAGE_SHIFT) +
Index;
DEBUG ((EFI_D_INFO, Xen GrantTable, removing %X\n, Parameters.gpfn));
-ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_remove_from_physmap,
Parameters);
+ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap,
Parameters);
if (ReturnCode != 0) {
DEBUG ((EFI_D_ERROR, Xen GrantTable, remove_from_physmap hypercall
error: %d\n, ReturnCode));
}
diff --git a/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
b/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
index 8547c30b81ee..e0fa71bb5ba8 100644
--- a/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
+++ b/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
@@ -2,13 +2,13 @@ SECTION .text
; INTN
; EFIAPI
-; XenHypercall2 (
+; __XenHypercall2 (
; IN VOID *HypercallAddr,
; IN OUT INTN Arg1,
; IN OUT INTN Arg2
; );
-global ASM_PFX(XenHypercall2)
-ASM_PFX(XenHypercall2):
+global ASM_PFX(__XenHypercall2)
+ASM_PFX(__XenHypercall2):
; Save only ebx, ecx is supposed to be a scratch register and needs to be
; saved by the caller
push ebx
diff --git a/OvmfPkg/XenBusDxe/X64/hypercall.nasm
b/OvmfPkg/XenBusDxe/X64/hypercall.nasm
index 177f271ef094..5e6a0c05c5c4 100644
--- a/OvmfPkg/XenBusDxe/X64/hypercall.nasm
+++ b/OvmfPkg/XenBusDxe/X64/hypercall.nasm
@@ -3,13 +3,13 @@ SECTION .text
; INTN
;
[Xen-devel] [PATCH v2 19/29] Ovmf/Xen: introduce XENIO_PROTOCOL
This introduces the abstract XENIO_PROTOCOL that will be used to
communicate the Xen grant table address to drivers supporting this
protocol. Primary purpose is allowing us to change the XenBusDxe
implementation so that it can support non-PCI Xen implementations
such as Xen on ARM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/Include/Protocol/XenIo.h | 48
OvmfPkg/OvmfPkg.dec | 1 +
2 files changed, 49 insertions(+)
diff --git a/OvmfPkg/Include/Protocol/XenIo.h b/OvmfPkg/Include/Protocol/XenIo.h
new file mode 100644
index ..510391f3b3e8
--- /dev/null
+++ b/OvmfPkg/Include/Protocol/XenIo.h
@@ -0,0 +1,48 @@
+/** @file
+ XenIo protocol to abstract arch specific details
+
+ The Xen implementations for the Intel and ARM archictures differ in the way
+ the base address of the grant table is communicated to the guest. The former
+ uses a virtual PCI device, while the latter uses a device tree node.
+ In order to allow the XenBusDxe UEFI driver to be reused for the non-PCI
+ Xen implementation, this abstract protocol can be installed on a handle
+ with the appropriate base address.
+
+ Copyright (C) 2014, Linaro Ltd.
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __PROTOCOL_XENIO_H__
+#define __PROTOCOL_XENIO_H__
+
+#include IndustryStandard/Xen/xen.h
+
+#define XENIO_PROTOCOL_GUID \
+ {0x6efac84f, 0x0ab0, 0x4747, {0x81, 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04,
0x49}}
+
+///
+/// Forward declaration
+///
+typedef struct _XENIO_PROTOCOL XENIO_PROTOCOL;
+
+///
+/// Protocol structure
+///
+struct _XENIO_PROTOCOL {
+ //
+ // Protocol data fields
+ //
+ EFI_PHYSICAL_ADDRESS GrantTableAddress;
+};
+
+extern EFI_GUID gXenIoProtocolGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 30a9fb1e9b42..3711fa922311 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -58,6 +58,7 @@
gVirtioDeviceProtocolGuid = {0xfa920010, 0x6785, 0x4941, {0xb6, 0xec,
0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
gBlockMmioProtocolGuid = {0x6b558ce3, 0x69e5, 0x4c67, {0xa6, 0x34,
0xf7, 0xfe, 0x72, 0xad, 0xbe, 0x84}}
gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 0x5d,
0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
+ gXenIoProtocolGuid = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 0xbe,
0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
[PcdsFixedAtBuild]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 23/29] Ovmf/Xen: add ARM and AArch64 support to XenBusDxe
This patch adds support to XenBusDxe for executing on ARM and AArch64
machines (the former only when built with GCC).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/XenBusDxe/AtomicsGcc.c | 44
OvmfPkg/XenBusDxe/XenBusDxe.inf | 3 +++
2 files changed, 47 insertions(+)
diff --git a/OvmfPkg/XenBusDxe/AtomicsGcc.c b/OvmfPkg/XenBusDxe/AtomicsGcc.c
new file mode 100644
index ..a0bdcbf67440
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/AtomicsGcc.c
@@ -0,0 +1,44 @@
+/** @file
+ Arch-independent implementations of XenBusDxe atomics using GCC __builtins
+
+ Copyright (C) 2014, Linaro Ltd.
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+UINT16
+EFIAPI
+InternalSyncCompareExchange16 (
+ IN volatile UINT16 *Value,
+ IN UINT16CompareValue,
+ IN UINT16ExchangeValue
+ )
+{
+ return __sync_val_compare_and_swap_2 (Value, CompareValue, ExchangeValue);
+}
+
+INT32
+EFIAPI
+TestAndClearBit (
+ IN INT32Bit,
+ IN volatile VOID*Address
+ )
+{
+ //
+ // Calculate the effective address relative to 'Address' based on the
+ // higher order bits of 'Bit'. Use signed shift instead of division to
+ // ensure we round towards -Inf, and end up with a positive shift in 'Bit',
+ // even if 'Bit' itself is negative.
+ //
+ Address += (Bit 5) * sizeof(INT32);
+ Bit = 31;
+
+ return (__sync_fetch_and_and_4 (Address, ~(1U Bit)) (1U Bit)) != 0;
+}
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 31553ac5a64a..949ec0a0c732 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -54,6 +54,9 @@
X64/InterlockedCompareExchange16.nasm
X64/TestAndClearBit.nasm
+[Sources.AARCH64, Sources.ARM]
+ AtomicsGcc.c | GCC
+
[LibraryClasses]
UefiDriverEntryPoint
UefiBootServicesTableLib
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 13/29] ArmVirtualizationPkg: allow patchable PCD for FV base address
Allow the use of a patchable PCD for gArmTokenSpaceGuid.PcdFvBaseAddress by moving it from the [FixedPcd] to the [Pcd] section in the INF file of PlatformPeiLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf index 96019e4009ff..1fca9b28f9e2 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf +++ b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf @@ -37,9 +37,11 @@ FdtLib [FixedPcd] - gArmTokenSpaceGuid.PcdFvBaseAddress gArmTokenSpaceGuid.PcdFvSize + +[Pcd] gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress + gArmTokenSpaceGuid.PcdFvBaseAddress [Guids] gEarlyPL011BaseAddressGuid -- 1.8.3.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 26/29] Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus root
On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI
device but an abstract 'platform' device. Add a dedicated Vendor
Hardware device path GUID to identify this node.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/Include/Guid/XenBusRootDevice.h | 24
OvmfPkg/OvmfPkg.dec | 1 +
2 files changed, 25 insertions(+)
diff --git a/OvmfPkg/Include/Guid/XenBusRootDevice.h
b/OvmfPkg/Include/Guid/XenBusRootDevice.h
new file mode 100644
index ..2b6e71018052
--- /dev/null
+++ b/OvmfPkg/Include/Guid/XenBusRootDevice.h
@@ -0,0 +1,24 @@
+/** @file
+ GUID to be used to identify the XenBus root node on non-PCI Xen guests
+
+ Copyright (C) 2015, Linaro Ltd.
+
+ This program and the accompanying materials are licensed and made available
+ under the terms and conditions of the BSD License that accompanies this
+ distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php.
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, WITHOUT
+ WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __XENBUS_ROOT_DEVICE_H__
+#define __XENBUS_ROOT_DEVICE_H__
+
+#define XENBUS_ROOT_DEVICE_GUID \
+{0xa732241f, 0x383d, 0x4d9c, {0x8a, 0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
+
+extern EFI_GUID gXenBusRootDeviceGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 3711fa922311..d61600225919 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -53,6 +53,7 @@
gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 0x12,
0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 0xac,
0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 0x9a,
0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
+ gXenBusRootDeviceGuid = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 0xe1,
0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
[Protocols]
gVirtioDeviceProtocolGuid = {0xfa920010, 0x6785, 0x4941, {0xb6, 0xec,
0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 21/29] Ovmf/Xen: move XenBusDxe to abstract XENIO_PROTOCOL
While Xen on Intel uses a virtual PCI device to communicate the
base address of the grant table, the ARM implementation uses a DT
node, which is fundamentally incompatible with the way XenBusDxe is
implemented, i.e., as a UEFI Driver Model implementation for a PCI
device.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32.fdf | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc| 1 +
OvmfPkg/OvmfPkgIa32X64.fdf| 1 +
OvmfPkg/OvmfPkgX64.dsc| 1 +
OvmfPkg/OvmfPkgX64.fdf| 1 +
OvmfPkg/XenBusDxe/ComponentName.c | 2 +-
OvmfPkg/XenBusDxe/GrantTable.c| 5 ++---
OvmfPkg/XenBusDxe/GrantTable.h| 3 +--
OvmfPkg/XenBusDxe/XenBus.c| 6 +++---
OvmfPkg/XenBusDxe/XenBusDxe.c | 57
++---
OvmfPkg/XenBusDxe/XenBusDxe.h | 8 ++--
OvmfPkg/XenBusDxe/XenBusDxe.inf | 2 +-
13 files changed, 30 insertions(+), 59 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 90540272745c..8c880613851d 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -444,6 +444,7 @@
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+ OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index f47e7ddc7834..ecef963d1e85 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -227,6 +227,7 @@ INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
INF OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 0a331eda8be0..ff32ecefd07b 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -451,6 +451,7 @@
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+ OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 4c034460d5d2..29414ff04082 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -227,6 +227,7 @@ INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
INF OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index e2b37c271681..8bac6dc313f0 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -449,6 +449,7 @@
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+ OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 2323eb2edf33..f1feb698ba66 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -227,6 +227,7 @@ INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
INF OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/XenBusDxe/ComponentName.c
b/OvmfPkg/XenBusDxe/ComponentName.c
index 4530509e65dc..3f2dd406c77d 100644
--- a/OvmfPkg/XenBusDxe/ComponentName.c
+++ b/OvmfPkg/XenBusDxe/ComponentName.c
@@ -155,7 +155,7 @@ XenBusDxeComponentNameGetControllerName (
Status = EfiTestManagedDevice (
ControllerHandle,
gXenBusDxeDriverBinding.DriverBindingHandle,
- gEfiPciIoProtocolGuid
+ gXenIoProtocolGuid
);
if (EFI_ERROR (Status)) {
return Status;
diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
index a80d5eff39cd..19117fbe0373 100644
--- a/OvmfPkg/XenBusDxe/GrantTable.c
+++ b/OvmfPkg/XenBusDxe/GrantTable.c
@@ -139,8 +139,7 @@ XenGrantTableEndAccess (
VOID
XenGrantTableInit (
- IN XENBUS_DEVICE *Dev,
[Xen-devel] [PATCH v2 25/29] Ovmf/Xen: implement dummy RealTimeClockLib for Xen
This implements a dummy RealTimeClockLib for Xen, as there is no
guest interface to access the time kept by Xen that can be shared
between UEFI and the OS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c | 196
++
OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf | 38
2 files changed, 234 insertions(+)
diff --git a/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
new file mode 100644
index ..70204ac22a92
--- /dev/null
+++ b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
@@ -0,0 +1,196 @@
+/** @file
+ Implement EFI RealTimeClock runtime services via Xen shared info page
+
+ Copyright (c) 2015, Linaro Ltd. All rights reserved.BR
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include Uefi.h
+#include PiDxe.h
+#include Library/BaseLib.h
+#include Library/DebugLib.h
+
+/**
+ Converts Epoch seconds (elapsed since 1970 JANUARY 01, 00:00:00 UTC) to
EFI_TIME
+ **/
+STATIC
+VOID
+EpochToEfiTime (
+ IN UINTN EpochSeconds,
+ OUT EFI_TIME *Time
+ )
+{
+ UINTN a;
+ UINTN b;
+ UINTN c;
+ UINTN d;
+ UINTN g;
+ UINTN j;
+ UINTN m;
+ UINTN y;
+ UINTN da;
+ UINTN db;
+ UINTN dc;
+ UINTN dg;
+ UINTN hh;
+ UINTN mm;
+ UINTN ss;
+ UINTN J;
+
+ J = (EpochSeconds / 86400) + 2440588;
+ j = J + 32044;
+ g = j / 146097;
+ dg = j % 146097;
+ c = (((dg / 36524) + 1) * 3) / 4;
+ dc = dg - (c * 36524);
+ b = dc / 1461;
+ db = dc % 1461;
+ a = (((db / 365) + 1) * 3) / 4;
+ da = db - (a * 365);
+ y = (g * 400) + (c * 100) + (b * 4) + a;
+ m = (((da * 5) + 308) / 153) - 2;
+ d = da - (((m + 4) * 153) / 5) + 122;
+
+ Time-Year = y - 4800 + ((m + 2) / 12);
+ Time-Month = ((m + 2) % 12) + 1;
+ Time-Day = d + 1;
+
+ ss = EpochSeconds % 60;
+ a = (EpochSeconds - ss) / 60;
+ mm = a % 60;
+ b = (a - mm) / 60;
+ hh = b % 24;
+
+ Time-Hour= hh;
+ Time-Minute = mm;
+ Time-Second = ss;
+ Time-Nanosecond = 0;
+
+}
+
+/**
+ Returns the current time and date information, and the time-keeping
capabilities
+ of the hardware platform.
+
+ @param Time A pointer to storage to receive a snapshot of
the current time.
+ @param Capabilities An optional pointer to a buffer to receive the
real time clock
+device's capabilities.
+
+ @retval EFI_SUCCESS The operation completed successfully.
+ @retval EFI_INVALID_PARAMETER Time is NULL.
+ @retval EFI_DEVICE_ERROR The time could not be retrieved due to
hardware error.
+
+**/
+EFI_STATUS
+EFIAPI
+LibGetTime (
+ OUT EFI_TIME*Time,
+ OUT EFI_TIME_CAPABILITIES *Capabilities
+ )
+{
+ ASSERT (Time != NULL);
+
+ //
+ // For now, there is nothing that we can do besides returning a bogus time,
+ // as Xen's timekeeping uses a shared info page which cannot be shared
+ // between UEFI and the OS
+ //
+ EpochToEfiTime(1421770011, Time);
+
+ return EFI_SUCCESS;
+}
+
+/**
+ Sets the current local time and date information.
+
+ @param Time A pointer to the current time.
+
+ @retval EFI_SUCCESS The operation completed successfully.
+ @retval EFI_INVALID_PARAMETER A time field is out of range.
+ @retval EFI_DEVICE_ERROR The time could not be set due due to hardware
error.
+
+**/
+EFI_STATUS
+EFIAPI
+LibSetTime (
+ IN EFI_TIME*Time
+ )
+{
+ return EFI_DEVICE_ERROR;
+}
+
+
+/**
+ Returns the current wakeup alarm clock setting.
+
+ @param Enabled Indicates if the alarm is currently enabled or
disabled.
+ @param Pending Indicates if the alarm signal is pending and
requires acknowledgement.
+ @param Time The current alarm setting.
+
+ @retval EFI_SUCCESS The alarm settings were returned.
+ @retval EFI_INVALID_PARAMETER Any parameter is NULL.
+ @retval EFI_DEVICE_ERROR The wakeup time could not be retrieved due to
a hardware error.
+ @retval EFI_UNSUPPORTED A wakeup timer is not supported on this
platform.
+
+**/
+EFI_STATUS
+EFIAPI
+LibGetWakeupTime (
+ OUT BOOLEAN *Enabled,
+ OUT BOOLEAN *Pending,
+ OUT EFI_TIME*Time
+ )
+{
+ return EFI_UNSUPPORTED;
Re: [Xen-devel] [PATCHv4 12/14] xen-blkback: safely unmap grants in case they are still in use
El 26/01/15 a les 18.01, David Vrabel ha escrit:
From: Jennifer Herbert jennifer.herb...@citrix.com
Use gnttab_unmap_refs_async() to wait until the mapped pages are no
longer in use before unmapping them.
This allows blkback to use network storage which may retain refs to
pages in queued skbs after the block I/O has completed.
Signed-off-by: Jennifer Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
Acked-by: Roger Pau Monné roger@citrix.com
This looks fine, only one comment below.
[...]
+/*
+ * Unmap the grant references, and also remove the M2P over-rides
+ * used in the 'pending_req'.
+ */
+static void xen_blkbk_unmap(struct xen_blkif *blkif,
+struct grant_page *pages[],
+int num)
+{
+ struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ struct page *unmap_pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ unsigned int invcount = 0;
+ int ret;
+
+ while (num) {
+ unsigned int batch = min(num, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+
+ invcount = xen_blkbk_unmap_prepare(blkif, pages, batch,
+unmap, unmap_pages);
+ if (invcount) {
+ ret = gnttab_unmap_refs(unmap, NULL, unmap_pages,
invcount);
BUG_ON(ret);
put_free_pages(blkif, unmap_pages, invcount);
- invcount = 0;
}
- }
- if (invcount) {
- ret = gnttab_unmap_refs(unmap, NULL, unmap_pages, invcount);
- BUG_ON(ret);
- put_free_pages(blkif, unmap_pages, invcount);
+ pages += batch;
+ num -= batch;
Could you add a comment explaining that the loop is not optimal if the
pages array contains both persistent and non-persistent grants?
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.14 test] 33780: regressions - FAIL
flight 33780 linux-3.14 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33780/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-xl-qemuu-ovmf-amd64 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-xl-win7-amd64 5 xen-boot fail REGR. vs. 33341 test-amd64-amd64-xl-qemut-winxpsp3 5 xen-bootfail REGR. vs. 33341 test-amd64-i386-xl-multivcpu 5 xen-boot fail REGR. vs. 33341 test-amd64-amd64-xl-winxpsp3 7 windows-install fail REGR. vs. 33341 test-amd64-i386-rumpuserxen-i386 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-freebsd10-i386 5 xen-bootfail REGR. vs. 33341 test-amd64-i386-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-xl-winxpsp3 5 xen-boot fail REGR. vs. 33341 test-amd64-amd64-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 33341 test-amd64-amd64-xl-win7-amd64 7 windows-install fail REGR. vs. 33341 test-amd64-i386-xl-winxpsp3-vcpus1 5 xen-bootfail REGR. vs. 33341 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 33341 test-amd64-amd64-xl-pvh-intel 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-freebsd10-amd64 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-libvirt 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-xl5 xen-boot fail REGR. vs. 33341 test-amd64-i386-xl-qemut-winxpsp3 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-qemut-rhel6hvm-intel 5 xen-boot fail REGR. vs. 33341 test-amd64-amd64-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-qemuu-rhel6hvm-intel 5 xen-boot fail REGR. vs. 33341 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33341 test-amd64-i386-xl-qemut-win7-amd64 5 xen-boot fail REGR. vs. 33341 test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 33341 test-amd64-i386-pair 7 xen-boot/src_host fail REGR. vs. 33341 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail in 33634 REGR. vs. 33341 test-amd64-i386-xl-qemuu-winxpsp3 6 leak-check/basis(6) fail in 33634 REGR. vs. 33341 test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail in 33580 REGR. vs. 33341 test-amd64-amd64-rumpuserxen-amd64 7 rumpuserxen-demo-setup fail in 33462 REGR. vs. 33341 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 33494 REGR. vs. 33341 test-amd64-amd64-xl-pvh-amd 7 debian-install fail in 33494 REGR. vs. 33341 test-amd64-i386-xl-credit27 debian-install fail in 33494 REGR. vs. 33341 test-amd64-amd64-xl 7 debian-install fail in 33689 REGR. vs. 33341 test-amd64-amd64-pair 16 guest-start/debian fail in 33689 REGR. vs. 33341 test-amd64-amd64-pair 15 leak-check/basis/dst_host(15) fail in 33689 REGR. vs. 33341 test-amd64-i386-rhel6hvm-amd 6 leak-check/basis(6) fail in 33560 REGR. vs. 33341 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 5 xen-boot fail pass in 33634 test-amd64-amd64-xl-qemut-debianhvm-amd64 5 xen-boot fail pass in 33580 test-amd64-amd64-rumpuserxen-amd64 5 xen-boot fail pass in 33462 test-amd64-i386-qemuu-rhel6hvm-amd 5 xen-boot fail pass in 33494 test-amd64-amd64-xl 5 xen-bootfail pass in 33689 test-amd64-amd64-xl-pvh-amd 5 xen-bootfail pass in 33689 test-amd64-i386-xl-qemuu-winxpsp3 5 xen-boot fail pass in 33689 test-amd64-i386-xl-credit25 xen-bootfail pass in 33494 test-amd64-i386-qemut-rhel6hvm-amd 5 xen-boot fail pass in 33580 test-amd64-i386-rhel6hvm-amd 5 xen-bootfail pass in 33560 test-amd64-amd64-libvirt 5 xen-bootfail pass in 33689 test-amd64-amd64-pair 8 xen-boot/dst_host fail pass in 33689 test-amd64-amd64-xl-qemut-win7-amd64 5 xen-bootfail pass in 33689 test-amd64-amd64-xl-winxpsp3 5 xen-boot fail in 33634 pass in 33780 test-amd64-amd64-xl-win7-amd64 5 xen-boot fail in 33634 pass in 33780 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 33462 pass in 33780 test-amd64-amd64-xl-qemuu-ovmf-amd64 5 xen-boot fail in 33462 pass in 33780 test-amd64-amd64-pair 7 xen-boot/src_host fail in 33462 pass in 33780 test-armhf-armhf-xl 12 guest-start.2 fail in 33494 pass in 33780 test-amd64-amd64-xl-pvh-amd 6 leak-check/basis(6)
Re: [Xen-devel] [PATCH v1 14/21] Ovmf/Xen: allow non-PCI usage of XenBusDxe
On 01/26/15 14:52, Ard Biesheuvel wrote: Well, the problem is that the XenConsoleSerialPortLib implementation also needs to issue Xen hypercalls, and needs to do so very early. In general virtual serial consoles, be they Xen or virtio, are a huge impedance mismatch (is that the right term?) for UEFI / edk2. For UEFI / edk2, the serial port library is one of the lowest level libraries, because it must be able to give you debug output as early as SEC. Fixed addresses, minimal state, minimal setup. However, the virtual serial ports are very stateful and require elaborate device setup. That matches the DXE phase alright, but nothing before. We could still make XENIO_PROTOCOL take its implementations of those hypercalls form XenHypercallLib, as XenConsoleSerialPortLib does, but I don't think it makes the code more understandable in that case. In particular, we would have two different ways of issuing hypercalls from code that is Xen-specific, one directly and one through the IO protocol. Agreed. The root cause of that is that the virtual (Xen) serial port is unsuitable for the original purpose of SerialPortLib -- be super low-level, available as soon as in SEC, without any kind of discovery, and just have minimal state. It's a debug device on which everything else relies on. (The same is true of virtio-serial, obviously.) For QEMU ARM guests, we use the emulated (PL011) serial port, which is easy to program. But you do remember the sad hoops you had jump through with the DTB because you wanted to make the base address dynamic. But I guess the following also makes sense: XenBusDxe / \ XenIo ARM vs. Intel hypercall Lib Instance | PCI vs. DTB The second architecture would keep XenIo much thinner, and it's certainly sufficient to have only one hypercall method built into the entire firmware -- you could decide that question at build time with a global library class resolution. Yes, I think this is the pragmatic choice, and I happen to be feeling very pragmatic at the moment :-) At the moment? :) No doubt. :) Cheers, Laszlo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] docs/commandline: Correct information for 'x2apic_phys' parameter
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Keir Fraser k...@xen.org CC: Jan Beulich jbeul...@suse.com CC: Tim Deegan t...@xen.org CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com --- docs/misc/xen-command-line.markdown |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index 0fc7559..2274e74 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -1378,9 +1378,11 @@ Permit use of x2apic setup for SMP environments. ### x2apic\_phys `= boolean` - Default: `true` + Default: `true` if **FADT** mandates physical mode, `false` otherwise. -Use the x2apic physical apic driver. The alternative is the x2apic cluster driver. +In the case that x2apic is in use, this option switches between physical and +clustered mode. The default, given no hint from the **FADT**, is cluster +mode. ### xsave `= boolean` -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv4 10/14] xen/gntdev: convert priv-lock to a mutex
On 26/01/15 18:57, Stefano Stabellini wrote:
@@ -443,14 +443,14 @@ static void mn_invl_range_start(struct mmu_notifier
*mn,
struct gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn);
struct grant_map *map;
-spin_lock(priv-lock);
+mutex_lock(priv-lock);
list_for_each_entry(map, priv-maps, next) {
unmap_if_in_range(map, start, end);
}
list_for_each_entry(map, priv-freeable_maps, next) {
unmap_if_in_range(map, start, end);
}
-spin_unlock(priv-lock);
+mutex_unlock(priv-lock);
}
I don't think that mmu_notifier callbacks are allowed to sleep:
https://lkml.org/lkml/2010/1/25/187
I don't think that limitation exists any more. SRCU is used and you can
sleep between tlb_gather_mmu()/tlb_finish_mmu().
Perhaps you could point to something that isn't 5 years old?
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 12/29] ArmVirtualizationPkg: implement custom MemoryInitPeiLib
This implements a MemoryInitPeiLib instance that differs from the
stock ArmPlatformPkg version only in the fact that it does not remove
the memory used by the flash device (FD). The reason is that, when using
PrePi, the DXE core is started immediately and never returns so there is
no reason to preserve any of the memory that the flash device occupied
originally, and it is preferable to release is so that the OS loader
can reuse it. This is especially important for the relocatable PrePi
configuration, which is aimed at being launched from a boot loader that
itself adheres to the Linux arm64 boot protocol.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
.../Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
| 91
.../Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
| 66 +++
2 files changed, 157 insertions(+)
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
new file mode 100644
index ..5f6cd059c47f
--- /dev/null
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c
@@ -0,0 +1,91 @@
+/** @file
+*
+* Copyright (c) 2011-2014, ARM Limited. All rights reserved.
+* Copyright (c) 2014, Linaro Limited. All rights reserved.
+*
+* This program and the accompanying materials
+* are licensed and made available under the terms and conditions of the BSD
License
+* which accompanies this distribution. The full text of the license may be
found at
+* http://opensource.org/licenses/bsd-license.php
+*
+* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+*
+**/
+
+#include PiPei.h
+
+#include Library/ArmPlatformLib.h
+#include Library/DebugLib.h
+#include Library/HobLib.h
+#include Library/MemoryAllocationLib.h
+#include Library/PcdLib.h
+
+VOID
+BuildMemoryTypeInformationHob (
+ VOID
+ );
+
+VOID
+InitMmu (
+ VOID
+ )
+{
+ ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
+ VOID *TranslationTableBase;
+ UINTN TranslationTableSize;
+ RETURN_STATUS Status;
+
+ // Get Virtual Memory Map from the Platform Library
+ ArmPlatformGetVirtualMemoryMap (MemoryTable);
+
+ //Note: Because we called PeiServicesInstallPeiMemory() before to call
InitMmu() the MMU Page Table resides in
+ // DRAM (even at the top of DRAM as it is the first permanent memory
allocation)
+ Status = ArmConfigureMmu (MemoryTable, TranslationTableBase,
TranslationTableSize);
+ if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, Error: Failed to enable MMU\n));
+ }
+}
+
+EFI_STATUS
+EFIAPI
+MemoryPeim (
+ IN EFI_PHYSICAL_ADDRESS UefiMemoryBase,
+ IN UINT64 UefiMemorySize
+ )
+{
+ EFI_RESOURCE_ATTRIBUTE_TYPE ResourceAttributes;
+
+ // Ensure PcdSystemMemorySize has been set
+ ASSERT (PcdGet64 (PcdSystemMemorySize) != 0);
+
+ //
+ // Now, the permanent memory has been installed, we can call AllocatePages()
+ //
+ ResourceAttributes = (
+ EFI_RESOURCE_ATTRIBUTE_PRESENT |
+ EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
+ EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_TESTED
+ );
+
+ BuildResourceDescriptorHob (
+ EFI_RESOURCE_SYSTEM_MEMORY,
+ ResourceAttributes,
+ PcdGet64 (PcdSystemMemoryBase),
+ PcdGet64 (PcdSystemMemorySize)
+ );
+
+ // Build Memory Allocation Hob
+ InitMmu ();
+
+ if (FeaturePcdGet (PcdPrePiProduceMemoryTypeInformationHob)) {
+// Optional feature that helps prevent EFI memory map fragmentation.
+BuildMemoryTypeInformationHob ();
+ }
+
+ return EFI_SUCCESS;
+}
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
new file mode 100644
index ..fcdae06de7c2
--- /dev/null
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf
@@ -0,0 +1,66 @@
+#/** @file
+#
+# Copyright (c) 2011-2014, ARM Ltd. All rights reserved.BR
+# Copyright (c) 2014, Linaro Ltd. All rights reserved.BR
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which
[Xen-devel] [PATCH v2 00/29] Xen/ARM guest support
This series implements support for executing Tianocore inside a Xen guest domain on 64-bit ARM systems (AArch64) The first part addresses ARM platform specifics, primarily to allow a Tianocore binary image to be runtime relocatable, and execute from DRAM. The second part refactors the XenBus support, and adds some missing device drivers that are needed to execute on ARM: a Xen PV console and a real time clock driver. Finally, patch #29 wraps it all together and implements the .dsc and .fdf platform descriptions that can be used to build the binary image. NOTES: - the Xen RTC driver is a dummy implementation, as it is a Runtime driver which is callable through Runtime Services from the OS, and this is currently not supportable under Xen, due to the need to share the shared info page between the OS and the firmware - UEFI maps the entire physical memory space as cached, and relies on Xen to use the correct stage2 mappings for regions that are backed by devices, such as the GIC or device passthrough. The reason is that the I/O console ring and grant table are backed by RAM that Xen maps as cached, which means that UEFI *must* maps those as cached as well. Instead of discovering those regions early on (i.e., before enabling the MMU) it is much easier to rely on the architecturally mandated behavior that stage2 device mappings supersede stage1 cached mappings for the same region. - this code is not yet tested on x86 (still only build tested for v2) Changes since v2: - move to PatchableInModule PCDs for the runtime self-relocating PrePi: this is semantically more correct, and will make the build system help us spot if there are remaining instances of FixedPcdGetXX() which need attention - split some prepi and xen patches to make it easier on the reviewers - split off the PCI support from XenBusDxe instead of the frankenstein DXE from v1 - implemented review comments regarding moving of files, splitting of libraries and some EDK2 optimizations suggested by Laszlo (casting, use of specific types etc) - added some acks and R-b's Ard Biesheuvel (29): ArmPkg: allow HYP timer interrupt to be omitted ArmPkg: allow patchable PCDs for memory, FD and FV addresses ArmPlatformPkg: allow patchable PCD for FD base address ArmVirtualizationPkg: add GICv3 detection to VirtFdtDxe ArmVirtualizationPkg: allow patchable PCD for device tree base address ArmVirtualizationPkg: move early UART discovery to PlatformPeim ArmVirtualizationPkg: use a HOB to store device tree blob ArmVirtualizationPkg: add padding to FDT allocation ArmPlatformPkg/PrePi: allow use of patchable PCDs ArmPlatformPkg/PrePi: allow unicore PrePi on multicore capable CPU ArmPlatformPkg/PrePi: add a relocatable version of PrePi ArmVirtualizationPkg: implement custom MemoryInitPeiLib ArmVirtualizationPkg: allow patchable PCD for FV base address ArmVirtualizationPkg: Xen/PV relocatable platformlib instance Ovmf/Xen: move Xen interface version to xen.h Ovmf/Xen: fix pointer to int cast in XenBusDxe Ovmf/Xen: refactor XenBusDxe hypercall implementation Ovmf/Xen: move XenBusDxe hypercall code to separate library Ovmf/Xen: introduce XENIO_PROTOCOL Ovmf/Xen: add separate driver for Xen PCI device Ovmf/Xen: move XenBusDxe to abstract XENIO_PROTOCOL Ovmf/Xen: implement XenHypercallLib for ARM Ovmf/Xen: add ARM and AArch64 support to XenBusDxe Ovmf/Xen: add Xen PV console SerialPortLib driver Ovmf/Xen: implement dummy RealTimeClockLib for Xen Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus root ArmVirtualizationPkg: add XenIoMmioLib ArmVirtualizationPkg/VirtFdtDxe: wire up XenBusDxe to xen,xen DT node ArmVirtualizationPkg: add platform description for Xen guests ArmPkg/ArmPkg.dec | 25 +-- ArmPkg/Drivers/TimerDxe/TimerDxe.c | 14 +- ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec | 10 +- ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc | 3 - ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc | 279 ++ ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.fdf | 337 ArmPlatformPkg/ArmVirtualizationPkg/Include/Library/XenIoMmioLib.h | 20 +++ .../Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.c | 91 ++ .../Library/ArmVirtualizationMemoryInitPeiLib/ArmVirtualizationMemoryInitPeiLib.inf | 66 +++ .../ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf | 5 - ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
[Xen-devel] [PATCH v2 08/29] ArmVirtualizationPkg: add padding to FDT allocation
Our primary user QEMU/mach-virt presents us with a FDT blob padded to 64 KB with plenty of room to set additional properties. However, in the general case, we should only add properties after making sure there is enough room available. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c index c500d5964b25..42a87309aebe 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c +++ b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c @@ -24,6 +24,15 @@ #include Guid/EarlyPL011BaseAddress.h #include Guid/FdtHob.h +// +// We may want to apply some changes to the device tree before passing it +// to the OS: for instance, if we find a PL031 RTC node and attach our +// runtime driver to it, we should disable it in the device tree by setting +// its status property to disabled. Add some padding to make sure this is +// possible. +// +#define FDT_PADDING 256 + EFI_STATUS EFIAPI PlatformPeim ( @@ -33,6 +42,7 @@ PlatformPeim ( VOID *Base; VOID *NewBase; UINTN FdtSize; + UINTN FdtPages; UINT64 *FdtHobData; UINT64 *UartHobData; INT32 Node, Prev; @@ -47,10 +57,11 @@ PlatformPeim ( ASSERT (Base != NULL); ASSERT (fdt_check_header (Base) == 0); - FdtSize = fdt_totalsize (Base); - NewBase = AllocatePages (EFI_SIZE_TO_PAGES (FdtSize)); + FdtSize = fdt_totalsize (Base) + FDT_PADDING; + FdtPages = EFI_SIZE_TO_PAGES (FdtSize); + NewBase = AllocatePages (FdtPages); ASSERT (NewBase != NULL); - CopyMem (NewBase, Base, FdtSize); + fdt_open_into (Base, NewBase, EFI_PAGES_TO_SIZE (FdtPages)); FdtHobData = BuildGuidHob (gFdtHobGuid, sizeof *FdtHobData); ASSERT (FdtHobData != NULL); -- 1.8.3.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 02/29] ArmPkg: allow patchable PCDs for memory, FD and FV addresses
In order to allow a runtime self relocating PrePi instance, change the allowable PCD types for the following PCDs: gArmTokenSpaceGuid.PcdSystemMemoryBase gArmTokenSpaceGuid.PcdSystemMemorySize gArmTokenSpaceGuid.PcdFdBaseAddress gArmTokenSpaceGuid.PcdFvBaseAddress to include PcdsPatchableInModule. This makes the build system correctly distinguish fixed PCDs from PCDs whose value may be different from the assigned value at compile time. Note that this only affects platforms that explicitly mark these PCDs as PatchableInModule in the DSC. All existing platforms that use FixedPcd will not be affected by this change. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPkg/ArmPkg.dec | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec index d7a4826d931a..b01de13e5f78 100644 --- a/ArmPkg/ArmPkg.dec +++ b/ArmPkg/ArmPkg.dec @@ -93,14 +93,6 @@ gArmTokenSpaceGuid.PcdSecureFvSize|0x0|UINT32|0x0030 # - # ARM Normal (or Non Secure) Firmware PCDs - # - gArmTokenSpaceGuid.PcdFdBaseAddress|0|UINT64|0x002B - gArmTokenSpaceGuid.PcdFdSize|0|UINT32|0x002C - gArmTokenSpaceGuid.PcdFvBaseAddress|0|UINT64|0x002D - gArmTokenSpaceGuid.PcdFvSize|0|UINT32|0x002E - - # # ARM Hypervisor Firmware PCDs # gArmTokenSpaceGuid.PcdHypFdBaseAddress|0|UINT32|0x003A @@ -127,6 +119,15 @@ # Maximum file size for TFTP servers that do not support 'tsize' extension gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x0100|UINT32|0x + # + # ARM Normal (or Non Secure) Firmware PCDs + # + gArmTokenSpaceGuid.PcdFdSize|0|UINT32|0x002C + gArmTokenSpaceGuid.PcdFvSize|0|UINT32|0x002E + +[PcdsFixedAtBuild.common, PcdsPatchableInModule.common] + gArmTokenSpaceGuid.PcdFdBaseAddress|0|UINT64|0x002B + gArmTokenSpaceGuid.PcdFvBaseAddress|0|UINT64|0x002D [PcdsFixedAtBuild.ARM] # @@ -207,16 +208,18 @@ # -# These PCDs are also defined as 'PcdsDynamic' to be redefined when using UEFI in a -# context of virtual machine. +# These PCDs are also defined as 'PcdsDynamic' or 'PcdsPatchableInModule' to be +# redefined when using UEFI in a context of virtual machine. # -[PcdsFixedAtBuild.common, PcdsDynamic.common] +[PcdsFixedAtBuild.common, PcdsDynamic.common, PcdsPatchableInModule.common] + # System Memory (DRAM): These PCDs define the region of in-built system memory # Some platforms can get DRAM extensions, these additional regions will be declared # to UEFI by ArmPlatformLib gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029 gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A +[PcdsFixedAtBuild.common, PcdsDynamic.common] # # ARM Architectural Timer # -- 1.8.3.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 11/29] ArmPlatformPkg/PrePi: add a relocatable version of PrePi
This patch introduces a relocatable PrePi, which can execute
from arbitrary offsets in RAM. This is intendend to be run
from a boot loader which passes a description of the actual
platform in a device tree, for instance.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 27 +++
ArmPlatformPkg/PrePi/MainUniCoreRelocatable.c | 38
ArmPlatformPkg/PrePi/PeiUniCoreRelocatable.inf | 111
++
ArmPlatformPkg/PrePi/Scripts/PrePi-PIE.lds | 28
4 files changed, 204 insertions(+)
diff --git a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
index 3fa6bf1f0322..54ac01c4b9c3 100644
--- a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
+++ b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
@@ -28,6 +28,33 @@ GCC_ASM_EXPORT(_ModuleEntryPoint)
StartupAddr:.8byte ASM_PFX(CEntryPoint)
ASM_PFX(_ModuleEntryPoint):
+
+#if defined (SELF_RELOCATE)
+ //
+ // If we are built as a ET_DYN PIE executable, we need to process all
+ // relative relocations regardless of whether or not we are executing from
+ // the same offset we were linked at. This is only possible if we are
+ // running from RAM.
+ //
+ adr x8, __reloc_base
+ adr x9, __reloc_start
+ adr x10, __reloc_end
+
+.Lreloc_loop:
+ cmp x9, x10
+ bhs .Lreloc_done
+
+ ldp x11, x12, [x9], #24
+ cmp x12, #0x403// R_AARCH64_RELATIVE
+ bne .Lreloc_loop
+
+ ldr x12, [x9, #-8]
+ add x12, x12, x8
+ str x12, [x11, x8]
+ b .Lreloc_loop
+.Lreloc_done:
+#endif
+
// Do early platform specific actions
blASM_PFX(ArmPlatformPeiBootAction)
diff --git a/ArmPlatformPkg/PrePi/MainUniCoreRelocatable.c
b/ArmPlatformPkg/PrePi/MainUniCoreRelocatable.c
new file mode 100644
index ..594579971a2d
--- /dev/null
+++ b/ArmPlatformPkg/PrePi/MainUniCoreRelocatable.c
@@ -0,0 +1,38 @@
+/** @file
+*
+* Copyright (c) 2011, ARM Limited. All rights reserved.
+*
+* This program and the accompanying materials
+* are licensed and made available under the terms and conditions of the BSD
License
+* which accompanies this distribution. The full text of the license may be
found at
+* http://opensource.org/licenses/bsd-license.php
+*
+* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+*
+**/
+
+#include PrePi.h
+
+VOID
+PrimaryMain (
+ IN UINTN UefiMemoryBase,
+ IN UINTN StacksBase,
+ IN UINTN GlobalVariableBase,
+ IN UINT64StartTimeStamp
+ )
+{
+ PrePiMain (UefiMemoryBase, StacksBase, GlobalVariableBase, StartTimeStamp,
FALSE);
+
+ // We must never return
+ ASSERT(FALSE);
+}
+
+VOID
+SecondaryMain (
+ IN UINTN MpId
+ )
+{
+ // We must never get into this function on UniCore system
+ ASSERT(FALSE);
+}
diff --git a/ArmPlatformPkg/PrePi/PeiUniCoreRelocatable.inf
b/ArmPlatformPkg/PrePi/PeiUniCoreRelocatable.inf
new file mode 100755
index ..155aa3288341
--- /dev/null
+++ b/ArmPlatformPkg/PrePi/PeiUniCoreRelocatable.inf
@@ -0,0 +1,111 @@
+#/** @file
+#
+# Copyright (c) 2011-2014, ARM Ltd. All rights reserved.BR
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+#
+#**/
+
+[Defines]
+ INF_VERSION= 0x00010005
+ BASE_NAME = ArmPlatformPrePiUniCoreRelocatable
+ FILE_GUID = f7d9fd14-9335-4389-80c5-334d6abfcced
+ MODULE_TYPE= SEC
+ VALID_ARCHITECTURES= AARCH64
+ VERSION_STRING = 1.0
+
+[Sources]
+ PrePi.c
+ MainUniCoreRelocatable.c
+
+[Sources.AArch64]
+ AArch64/ArchPrePi.c
+ AArch64/ModuleEntryPoint.S
+
+[Packages]
+ MdePkg/MdePkg.dec
+ MdeModulePkg/MdeModulePkg.dec
+ EmbeddedPkg/EmbeddedPkg.dec
+ ArmPkg/ArmPkg.dec
+ ArmPlatformPkg/ArmPlatformPkg.dec
+ ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
+ IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
+
+[LibraryClasses]
+ BaseLib
+ DebugLib
+ DebugAgentLib
+ ArmLib
+ IoLib
+ TimerLib
+ SerialPortLib
+ ExtractGuidedSectionLib
+ LzmaDecompressLib
+ PeCoffGetEntryPointLib
+ DebugAgentLib
+ PrePiLib
+ ArmPlatformLib
+ ArmPlatformStackLib
+ MemoryAllocationLib
+ HobLib
+ PrePiHobListPointerLib
+ PlatformPeiLib
+ MemoryInitPeiLib
+
+[Ppis]
+
[Xen-devel] [PATCH v2 10/29] ArmPlatformPkg/PrePi: allow unicore PrePi on multicore capable CPU
Under virtualization, typically, the guest is entered with only a
single CPU turned on, and any remaining CPUs are started by the OS
using PSCI. So refactor the PrePi code in such a way that we can
implement a unicore flavor which can be allowed to execute on a
MPcore CPU.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
ArmPlatformPkg/PrePi/MainMPCore.c | 2 +-
ArmPlatformPkg/PrePi/MainUniCore.c | 2 +-
ArmPlatformPkg/PrePi/PrePi.c | 9 -
ArmPlatformPkg/PrePi/PrePi.h | 3 ++-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/ArmPlatformPkg/PrePi/MainMPCore.c
b/ArmPlatformPkg/PrePi/MainMPCore.c
index bf813730d341..8e5f9947d499 100644
--- a/ArmPlatformPkg/PrePi/MainMPCore.c
+++ b/ArmPlatformPkg/PrePi/MainMPCore.c
@@ -35,7 +35,7 @@ PrimaryMain (
ArmGicSendSgiTo (PcdGet32(PcdGicDistributorBase),
ARM_GIC_ICDSGIR_FILTER_EVERYONEELSE, 0x0E, PcdGet32 (PcdGicSgiIntId));
}
- PrePiMain (UefiMemoryBase, StacksBase, GlobalVariableBase, StartTimeStamp);
+ PrePiMain (UefiMemoryBase, StacksBase, GlobalVariableBase, StartTimeStamp,
ArmIsMpCore());
// We must never return
ASSERT(FALSE);
diff --git a/ArmPlatformPkg/PrePi/MainUniCore.c
b/ArmPlatformPkg/PrePi/MainUniCore.c
index 43588a50ddb5..918ea4dcdf7b 100644
--- a/ArmPlatformPkg/PrePi/MainUniCore.c
+++ b/ArmPlatformPkg/PrePi/MainUniCore.c
@@ -27,7 +27,7 @@ PrimaryMain (
ASSERT(ArmIsMpCore() == 0);
DEBUG_CODE_END();
- PrePiMain (UefiMemoryBase, StacksBase, GlobalVariableBase, StartTimeStamp);
+ PrePiMain (UefiMemoryBase, StacksBase, GlobalVariableBase, StartTimeStamp,
ArmIsMpCore());
// We must never return
ASSERT(FALSE);
diff --git a/ArmPlatformPkg/PrePi/PrePi.c b/ArmPlatformPkg/PrePi/PrePi.c
index 0e551c518d6b..5b058dba80fa 100755
--- a/ArmPlatformPkg/PrePi/PrePi.c
+++ b/ArmPlatformPkg/PrePi/PrePi.c
@@ -94,7 +94,8 @@ PrePiMain (
IN UINTN UefiMemoryBase,
IN UINTN StacksBase,
IN UINTN GlobalVariableBase,
- IN UINT64StartTimeStamp
+ IN UINT64StartTimeStamp,
+ IN BOOLEAN IsMpCore
)
{
EFI_HOB_HANDOFF_INFO_TABLE* HobList;
@@ -138,7 +139,7 @@ PrePiMain (
ASSERT_EFI_ERROR (Status);
// Create the Stacks HOB (reserve the memory for all stacks)
- if (ArmIsMpCore ()) {
+ if (IsMpCore) {
StacksSize = PcdGet32 (PcdCPUCorePrimaryStackSize) +
((FixedPcdGet32 (PcdCoreCount) - 1) * FixedPcdGet32
(PcdCPUCoreSecondaryStackSize));
} else {
@@ -152,7 +153,7 @@ PrePiMain (
//TODO: Call CpuPei as a library
BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize));
- if (ArmIsMpCore ()) {
+ if (IsMpCore) {
// Only MP Core platform need to produce gArmMpCoreInfoPpiGuid
Status = GetPlatformPpi (gArmMpCoreInfoPpiGuid,
(VOID**)ArmMpCoreInfoPpi);
@@ -209,8 +210,6 @@ CEntryPoint (
{
UINT64 StartTimeStamp;
- ASSERT(!ArmIsMpCore() || (PcdGet32 (PcdCoreCount) 1));
-
// Initialize the platform specific controllers
ArmPlatformInitialize (MpId);
diff --git a/ArmPlatformPkg/PrePi/PrePi.h b/ArmPlatformPkg/PrePi/PrePi.h
index e67795f4490a..468569b3a28b 100644
--- a/ArmPlatformPkg/PrePi/PrePi.h
+++ b/ArmPlatformPkg/PrePi/PrePi.h
@@ -40,7 +40,8 @@ PrePiMain (
IN UINTN UefiMemoryBase,
IN UINTN StacksBase,
IN UINTN GlobalVariableBase,
- IN UINT64StartTimeStamp
+ IN UINT64StartTimeStamp,
+ IN BOOLEAN IsMpCore
);
EFI_STATUS
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 18/29] Ovmf/Xen: move XenBusDxe hypercall code to separate library
This moves all of the Xen hypercall code that was private to XenBusDxe
to a new library class XenHypercallLib. This will allow us to reimplement
it for ARM, and to export the Xen hypercall functionality to other parts
of the code, such as a Xen console SerialPortLib driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/{XenBusDxe/XenHypercall.h = Include/Library/XenHypercallLib.h} | 16
++-
OvmfPkg/{XenBusDxe = Library/XenHypercallLib}/Ia32/hypercall.nasm | 0
OvmfPkg/{XenBusDxe = Library/XenHypercallLib}/X64/hypercall.nasm | 0
OvmfPkg/{XenBusDxe = Library/XenHypercallLib}/XenHypercall.c | 37
++
OvmfPkg/Library/XenHypercallLib/XenHypercallIntel.c | 77
+++
OvmfPkg/Library/XenHypercallLib/XenHypercallLibIntel.inf| 52
OvmfPkg/OvmfPkg.dec | 4
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
OvmfPkg/OvmfPkgX64.dsc | 1 +
OvmfPkg/XenBusDxe/EventChannel.c| 3
++-
OvmfPkg/XenBusDxe/GrantTable.c | 2 +-
OvmfPkg/XenBusDxe/XenBusDxe.c | 9
+
OvmfPkg/XenBusDxe/XenBusDxe.inf | 11
+--
OvmfPkg/XenBusDxe/XenStore.c| 2 +-
15 files changed, 146 insertions(+), 70 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/XenHypercall.h
b/OvmfPkg/Include/Library/XenHypercallLib.h
similarity index 82%
rename from OvmfPkg/XenBusDxe/XenHypercall.h
rename to OvmfPkg/Include/Library/XenHypercallLib.h
index 9d49e33eb5af..dc2c5424683c 100644
--- a/OvmfPkg/XenBusDxe/XenHypercall.h
+++ b/OvmfPkg/Include/Library/XenHypercallLib.h
@@ -13,8 +13,8 @@
**/
-#ifndef __XENBUS_DXE_HYPERCALL_H__
-#define __XENBUS_DXE_HYPERCALL_H__
+#ifndef __XEN_HYPERCALL_LIB_H_
+#define __XEN_HYPERCALL_LIB_H_
/**
This function will put the two arguments in the right place (registers) and
@@ -35,18 +35,6 @@ XenHypercall2 (
);
/**
- Get the page where all hypercall are from the XenInfo hob.
-
- @param DevA XENBUS_DEVICE instance.
-
- @retval EFI_NOT_FOUND hyperpage could not be found.
- @retval EFI_SUCCESS Successfully retrieve the hyperpage pointer.
-**/
-EFI_STATUS
-XenHyperpageInit (
- );
-
-/**
Return the value of the HVM parameter Index.
@param Index The parameter to get, e.g. HVM_PARAM_STORE_EVTCHN.
diff --git a/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
b/OvmfPkg/Library/XenHypercallLib/Ia32/hypercall.nasm
similarity index 100%
rename from OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
rename to OvmfPkg/Library/XenHypercallLib/Ia32/hypercall.nasm
diff --git a/OvmfPkg/XenBusDxe/X64/hypercall.nasm
b/OvmfPkg/Library/XenHypercallLib/X64/hypercall.nasm
similarity index 100%
rename from OvmfPkg/XenBusDxe/X64/hypercall.nasm
rename to OvmfPkg/Library/XenHypercallLib/X64/hypercall.nasm
diff --git a/OvmfPkg/XenBusDxe/XenHypercall.c
b/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
similarity index 66%
rename from OvmfPkg/XenBusDxe/XenHypercall.c
rename to OvmfPkg/Library/XenHypercallLib/XenHypercall.c
index 9bcf3197633e..ecc757cf707c 100644
--- a/OvmfPkg/XenBusDxe/XenHypercall.c
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
@@ -14,32 +14,12 @@
**/
#include PiDxe.h
-#include Library/HobLib.h
-#include Guid/XenInfo.h
-
-#include XenBusDxe.h
-#include XenHypercall.h
#include IndustryStandard/Xen/hvm/params.h
#include IndustryStandard/Xen/memory.h
-STATIC VOID *Hyperpage;
-
-EFI_STATUS
-XenHyperpageInit (
- )
-{
- EFI_HOB_GUID_TYPE *GuidHob;
- EFI_XEN_INFO*XenInfo;
-
- GuidHob = GetFirstGuidHob (gEfiXenInfoGuid);
- if (GuidHob == NULL) {
-return EFI_NOT_FOUND;
- }
- XenInfo = (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
- Hyperpage = XenInfo-HyperPages;
- return EFI_SUCCESS;
-}
+#include Library/DebugLib.h
+#include Library/XenHypercallLib.h
UINT64
XenHypercallHvmGetParam (
@@ -81,16 +61,3 @@ XenHypercallEventChannelOp (
return XenHypercall2 (__HYPERVISOR_event_channel_op,
Operation, (INTN) Arguments);
}
-
-INTN
-EFIAPI
-XenHypercall2 (
- IN INTN HypercallID,
- IN OUT INTN Arg1,
- IN OUT INTN Arg2
- )
-{
- ASSERT (HyperPage != NULL);
-
- return __XenHypercall2 ((UINT8*)HyperPage + HypercallID * 32, Arg1, Arg2);
-}
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallIntel.c
b/OvmfPkg/Library/XenHypercallLib/XenHypercallIntel.c
new file mode 100644
index ..362640f6a16f
--- /dev/null
+++
[Xen-devel] [PATCH v2 16/29] Ovmf/Xen: fix pointer to int cast in XenBusDxe
On ARM, xen_pfn_t is 64 bits but the size of a pointer is only
32 bits, so casting between them needs to go via (UINTN). Also
move the xen_pfn_t cast outside the shift so that we can avoid
shifting 64-bit quantities on 32-bit architectures, which may
require runtime library support.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/XenBusDxe/GrantTable.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
index 37d3bf786c64..8405edc51bc4 100644
--- a/OvmfPkg/XenBusDxe/GrantTable.c
+++ b/OvmfPkg/XenBusDxe/GrantTable.c
@@ -160,7 +160,7 @@ XenGrantTableInit (
Parameters.domid = DOMID_SELF;
Parameters.idx = Index;
Parameters.space = XENMAPSPACE_grant_table;
-Parameters.gpfn = (((xen_pfn_t) GrantTable) EFI_PAGE_SHIFT) + Index;
+Parameters.gpfn = (xen_pfn_t) ((UINTN) GrantTable EFI_PAGE_SHIFT) +
Index;
ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_add_to_physmap,
Parameters);
if (ReturnCode != 0) {
DEBUG ((EFI_D_ERROR, Xen GrantTable, add_to_physmap hypercall error:
%d\n, ReturnCode));
@@ -182,7 +182,7 @@ XenGrantTableDeinit (
for (Index = NR_GRANT_FRAMES - 1; Index = 0; Index--) {
Parameters.domid = DOMID_SELF;
-Parameters.gpfn = (((xen_pfn_t) GrantTable) EFI_PAGE_SHIFT) + Index;
+Parameters.gpfn = (xen_pfn_t) ((UINTN) GrantTable EFI_PAGE_SHIFT) +
Index;
DEBUG ((EFI_D_INFO, Xen GrantTable, removing %X\n, Parameters.gpfn));
ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_remove_from_physmap,
Parameters);
if (ReturnCode != 0) {
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 07/29] ArmVirtualizationPkg: use a HOB to store device tree blob
Instead of using a dynamic PCD, store the device tree address in a HOB so that we can also run under a configuration that does not support dynamic PCDs. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec | 2 -- ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc | 3 --- ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf | 2 -- ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c | 11 --- ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf | 4 +--- ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c | 10 -- ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf | 3 ++- EmbeddedPkg/EmbeddedPkg.dec | 2 ++ EmbeddedPkg/Include/Guid/FdtHob.h | 26 ++ 9 files changed, 47 insertions(+), 16 deletions(-) diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec index d83117fc6abe..868488906643 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec @@ -44,8 +44,6 @@ gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x0|UINT64|0x0001 [PcdsDynamic, PcdsFixedAtBuild] - gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeBaseAddress|0x0|UINT64|0x0002 - # # ARM PSCI function invocations can be done either through hypervisor # calls (HVC) or secure monitor calls (SMC). diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc index dff4e2507058..4f8eb632143c 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc @@ -160,9 +160,6 @@ # System Memory Size -- 1 MB initially, actual size will be fetched from DT gArmTokenSpaceGuid.PcdSystemMemorySize|0x0010 - # location of the device tree blob passed by QEMU - gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeBaseAddress|0x0 - gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum|0x0 gArmTokenSpaceGuid.PcdArmArchTimerIntrNum|0x0 gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum|0x0 diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf index 43b3c6ca1bef..c57002f3e9da 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf +++ b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf @@ -33,8 +33,6 @@ ArmLib PrintLib FdtLib - SerialPortLib - HobLib [Sources.common] Virt.c diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c index 58bc2b828dcd..c500d5964b25 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c +++ b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c @@ -22,6 +22,7 @@ #include libfdt.h #include Guid/EarlyPL011BaseAddress.h +#include Guid/FdtHob.h EFI_STATUS EFIAPI @@ -32,6 +33,7 @@ PlatformPeim ( VOID *Base; VOID *NewBase; UINTN FdtSize; + UINT64 *FdtHobData; UINT64 *UartHobData; INT32 Node, Prev; CONST CHAR8*Compatible; @@ -41,15 +43,18 @@ PlatformPeim ( UINT64 UartBase; - Base = (VOID*)(UINTN)FixedPcdGet64 (PcdDeviceTreeInitialBaseAddress); + Base = (VOID*)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress); + ASSERT (Base != NULL); ASSERT (fdt_check_header (Base) == 0); FdtSize = fdt_totalsize (Base); NewBase = AllocatePages (EFI_SIZE_TO_PAGES (FdtSize)); ASSERT (NewBase != NULL); - CopyMem (NewBase, Base, FdtSize); - PcdSet64 (PcdDeviceTreeBaseAddress, (UINT64)(UINTN)NewBase); + + FdtHobData = BuildGuidHob (gFdtHobGuid, sizeof *FdtHobData); + ASSERT (FdtHobData != NULL); + *FdtHobData = (UINTN)NewBase; UartHobData = BuildGuidHob (gEarlyPL011BaseAddressGuid, sizeof *UartHobData); ASSERT (UartHobData != NULL); diff --git
Re: [Xen-devel] [PATCH for-4.5 v8 4/7] xen: Add vmware_port support
On 01/26/15 11:46, Jan Beulich wrote: On 26.01.15 at 16:58, dsl...@verizon.com wrote: On 01/22/15 03:32, Jan Beulich wrote: On 21.01.15 at 18:52, dsl...@verizon.com wrote: On 01/16/15 05:09, Jan Beulich wrote: On 03.10.14 at 00:40, dsl...@verizon.com wrote: ... As stated before - if feasible, 8 would seem the best option. The second best one would be to support all four I/O insns (assuming VMware supports all of them too) with any legal (even if pointless or redundant) prefix combination, and with the prefixes actually doing something correctly emulated. Ok, I will focus on hvm_emulate_one. So there are 3 options here: 1) Add an ASSERT() like the BUG_ON() in get_instruction_length() 2) Switch to using get_instruction_length() 3) Switch to using MAX_INST_LEN. Let me know which way to go. As said above - use get_instruction_length() if Intel confirms the necessary hardware behavior as being architectural. If they don't, 3) looks like the only viable option. So what is the procedure to getting Intel confirms the necessary hardware behaviour as being architectural? There's no procedure. Ask them explicitly (i.e. perhaps outside of this thread, where the question may end up being well hidden from their eyes), and then ping them until they give you a statement one way or another. I am assuming that: INTEL(R) VT FOR X86 (VT-X) M: Jun Nakajima jun.nakaj...@intel.com M: Eddie Dong eddie.d...@intel.com M: Kevin Tian kevin.t...@intel.com Is to correct list of people to ask. -Don Slutz Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 05/29] ArmVirtualizationPkg: allow patchable PCD for device tree base address
To allow a runtime self relocating PrePi instance to discover the base
address of the device tree at runtime, allow the use of a patchable PCD
for gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress.
We will not be using the build time patch tool in this case, but using
a patchable PCD will make the build system aware that its value is not
a compile time constant.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
| 2 +-
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
index 99411548aff6..d83117fc6abe 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
@@ -34,7 +34,7 @@
gArmVirtualizationTokenSpaceGuid = { 0x0B6F5CA7, 0x4F53, 0x445A, { 0xB7,
0x6E, 0x2E, 0x36, 0x5B, 0x80, 0x63, 0x66 } }
gEarlyPL011BaseAddressGuid = { 0xB199DEA9, 0xFD5C, 0x4A84, { 0x80,
0x82, 0x2F, 0x41, 0x70, 0x78, 0x03, 0x05 } }
-[PcdsFixedAtBuild]
+[PcdsFixedAtBuild, PcdsPatchableInModule]
#
# This is the physical address where the device tree is expected to be stored
# upon first entry into UEFI. This needs to be a FixedAtBuild PCD, so that we
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
index aa4ced4582e8..3e3074af72f1 100644
---
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
@@ -96,7 +96,7 @@ ArmPlatformInitializeSystemMemory (
ASSERT (HobData != NULL);
*HobData = 0;
- DeviceTreeBase = (VOID *)(UINTN)FixedPcdGet64
(PcdDeviceTreeInitialBaseAddress);
+ DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
ASSERT (DeviceTreeBase != NULL);
//
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 04/29] ArmVirtualizationPkg: add GICv3 detection to VirtFdtDxe
This adds support for detecting the presence of a GICv3 interrupt
controller from the device tree, and recording its distributor
base address in a PCD.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Martin olivier.mar...@arm.com
Acked-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c | 19
+++
1 file changed, 19 insertions(+)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
index 1d44f9ba02b3..31164905d34e 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
@@ -46,6 +46,7 @@ typedef enum {
PropertyTypeTimer,
PropertyTypePsci,
PropertyTypeFwCfg,
+ PropertyTypeGicV3,
} PROPERTY_TYPE;
typedef struct {
@@ -62,6 +63,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
{ PropertyTypeTimer, arm,armv8-timer },
{ PropertyTypePsci,arm,psci-0.2},
{ PropertyTypeFwCfg, qemu,fw-cfg-mmio},
+ { PropertyTypeGicV3, arm,gic-v3 },
{ PropertyTypeUnknown, }
};
@@ -256,6 +258,23 @@ InitializeVirtFdtDxe (
DEBUG ((EFI_D_INFO, Found GIC @ 0x%Lx/0x%Lx\n, DistBase, CpuBase));
break;
+case PropertyTypeGicV3:
+ //
+ // The GIC v3 DT binding describes a series of at least 3 physical base
+ // addresses, but we are only interested in the first one, which is the
+ // distributor interface. (We use the system register CPU interface, not
+ // the MMIO one)
+ //
+ ASSERT (Len = 16);
+
+ DistBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
+ ASSERT (DistBase MAX_UINT32);
+
+ PcdSet32 (PcdGicDistributorBase, (UINT32)DistBase);
+
+ DEBUG ((EFI_D_INFO, Found GIC v3 distributor @ 0x%Lx\n, DistBase));
+ break;
+
case PropertyTypeRtc:
ASSERT (Len == 16);
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 03/29] ArmPlatformPkg: allow patchable PCD for FD base address
This moves the reference to gArmTokenSpaceGuid.PcdFdBaseAddress from the [FixedPcd] to the [Pcd] section in the INF file of PrePiArmPlatformGlobalVariableLib so that its users may choose to use a patchable PCD instead. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf b/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf index 596f5595412e..37de35e7d00e 100644 --- a/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf +++ b/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf @@ -34,7 +34,6 @@ PcdLib [FixedPcd] - gArmTokenSpaceGuid.PcdFdBaseAddress gArmTokenSpaceGuid.PcdFdSize gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize @@ -43,4 +42,5 @@ [Pcd] gArmTokenSpaceGuid.PcdSystemMemoryBase gArmTokenSpaceGuid.PcdSystemMemorySize + gArmTokenSpaceGuid.PcdFdBaseAddress -- 1.8.3.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 06/29] ArmVirtualizationPkg: move early UART discovery to PlatformPeim
This is partially motivated by the desire to use PrePi in a virt
environment, and in that configuration, ArmPlatformInitializeSystemMemory()
is never called. But actually, this is a more suitable place anyway.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek ler...@redhat.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
.../ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
| 3 ---
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
| 46 ++
ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
| 48
ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf
| 3 +++
4 files changed, 53 insertions(+), 47 deletions(-)
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
index d1572882af1b..43b3c6ca1bef 100644
---
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf
@@ -62,6 +62,3 @@
gArmTokenSpaceGuid.PcdArmPrimaryCore
gArmTokenSpaceGuid.PcdFdBaseAddress
gArmTokenSpaceGuid.PcdFdSize
-
-[Guids]
- gEarlyPL011BaseAddressGuid
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
index 3e3074af72f1..17f268697583 100644
---
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
@@ -24,9 +24,6 @@
#include Pi/PiBootMode.h
#include Uefi/UefiBaseType.h
#include Uefi/UefiMultiPhase.h
-#include Pi/PiHob.h
-#include Library/HobLib.h
-#include Guid/EarlyPL011BaseAddress.h
/**
Return the current Boot Mode
@@ -77,25 +74,13 @@ ArmPlatformInitializeSystemMemory (
INT32Node, Prev;
UINT64 NewBase;
UINT64 NewSize;
- BOOLEAN HaveMemory, HaveUART;
- UINT64 *HobData;
CONST CHAR8 *Type;
- CONST CHAR8 *Compatible;
- CONST CHAR8 *CompItem;
INT32Len;
CONST UINT64 *RegProp;
- UINT64 UartBase;
NewBase = 0;
NewSize = 0;
- HaveMemory = FALSE;
- HaveUART = FALSE;
-
- HobData = BuildGuidHob (gEarlyPL011BaseAddressGuid, sizeof *HobData);
- ASSERT (HobData != NULL);
- *HobData = 0;
-
DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
ASSERT (DeviceTreeBase != NULL);
@@ -107,7 +92,7 @@ ArmPlatformInitializeSystemMemory (
//
// Look for a memory node
//
- for (Prev = 0; !(HaveMemory HaveUART); Prev = Node) {
+ for (Prev = 0;; Prev = Node) {
Node = fdt_next_node (DeviceTreeBase, Prev, NULL);
if (Node 0) {
break;
@@ -140,34 +125,7 @@ ArmPlatformInitializeSystemMemory (
DEBUG ((EFI_D_ERROR, %a: Failed to parse FDT memory node\n,
__FUNCTION__));
}
- HaveMemory = TRUE;
- continue;
-}
-
-//
-// Check for UART node
-//
-Compatible = fdt_getprop (DeviceTreeBase, Node, compatible, Len);
-
-//
-// Iterate over the NULL-separated items in the compatible string
-//
-for (CompItem = Compatible; CompItem != NULL CompItem Compatible +
Len;
- CompItem += 1 + AsciiStrLen (CompItem)) {
-
- if (AsciiStrCmp (CompItem, arm,pl011) == 0) {
-RegProp = fdt_getprop (DeviceTreeBase, Node, reg, Len);
-ASSERT (Len == 16);
-
-UartBase = fdt64_to_cpu (ReadUnaligned64 (RegProp));
-
-DEBUG ((EFI_D_INFO, %a: PL011 UART @ 0x%lx\n, __FUNCTION__,
UartBase));
-
-*HobData = UartBase;
-
-HaveUART = TRUE;
-continue;
- }
+ break;
}
}
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
index af0d6e87da9f..58bc2b828dcd 100644
---
a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
+++
b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
@@ -21,6 +21,8 @@
#include Library/PcdLib.h
#include libfdt.h
+#include Guid/EarlyPL011BaseAddress.h
+
EFI_STATUS
EFIAPI
PlatformPeim (
@@ -30,6 +32,14 @@ PlatformPeim (
VOID *Base;
VOID *NewBase;
UINTN FdtSize;
+ UINT64 *UartHobData;
+ INT32 Node, Prev;
+ CONST CHAR8*Compatible;
+ CONST CHAR8*CompItem;
+ INT32
Re: [Xen-devel] [PATCHv4 09/14] xen/grant-table: add a mechanism to safely unmap pages that are in use
On Mon, 26 Jan 2015, David Vrabel wrote:
From: Jennifer Herbert jennifer.herb...@citrix.com
Introduce gnttab_unmap_refs_async() that can be used to safely unmap
pages that may be in use (ref count 1). If the pages are in use the
unmap is deferred and retried later. This polling is not very clever
but it should be good enough if the cases where the delay is necessary
are rare.
The initial delay is 5 ms and is increased linearly on each subsequent
retry (to reduce load if the page is in use for a long time).
This is needed to allow block backends using grant mapping to safely
use network storage (block or filesystem based such as iSCSI or NFS).
The network storage driver may complete a block request whilst there
is a queued network packet retry (because the ack from the remote end
races with deciding to queue the retry). The pages for the retried
packet would be grant unmapped and the network driver (or hardware)
would access the unmapped page.
Signed-off-by: Jennifer Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/xen/grant-table.c | 44
include/xen/grant_table.h | 18 ++
2 files changed, 62 insertions(+)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 89dcca4..17972fb 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -42,6 +42,7 @@
#include linux/io.h
#include linux/delay.h
#include linux/hardirq.h
+#include linux/workqueue.h
#include xen/xen.h
#include xen/interface/xen.h
@@ -819,6 +820,49 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref
*unmap_ops,
}
EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
+#define GNTTAB_UNMAP_REFS_DELAY 5
+
+static void __gnttab_unmap_refs_async(struct gntab_unmap_queue_data* item);
+
+static void gnttab_unmap_work(struct work_struct *work)
+{
+ struct gntab_unmap_queue_data
+ *unmap_data = container_of(work,
+struct gntab_unmap_queue_data,
+gnttab_work.work);
+ if (unmap_data-age != UINT_MAX)
+ unmap_data-age++;
+ __gnttab_unmap_refs_async(unmap_data);
+}
+
+static void __gnttab_unmap_refs_async(struct gntab_unmap_queue_data* item)
+{
+ int ret;
+ int pc;
+
+ for (pc = 0; pc item-count; pc++) {
+ if (page_count(item-pages[pc]) 1) {
+ unsigned long delay = GNTTAB_UNMAP_REFS_DELAY *
(item-age + 1);
I think that the +1 here is unnecessary.
Regardess:
Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
+ schedule_delayed_work(item-gnttab_work,
+ msecs_to_jiffies(delay));
+ return;
+ }
+ }
+
+ ret = gnttab_unmap_refs(item-unmap_ops, item-kunmap_ops,
+ item-pages, item-count);
+ item-done(ret, item);
+}
+
+void gnttab_unmap_refs_async(struct gntab_unmap_queue_data* item)
+{
+ INIT_DELAYED_WORK(item-gnttab_work, gnttab_unmap_work);
+ item-age = 0;
+
+ __gnttab_unmap_refs_async(item);
+}
+EXPORT_SYMBOL_GPL(gnttab_unmap_refs_async);
+
static int gnttab_map_frames_v1(xen_pfn_t *frames, unsigned int nr_gframes)
{
int rc;
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index d3bef56..143ca5f 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -60,6 +60,22 @@ struct gnttab_free_callback {
u16 count;
};
+struct gntab_unmap_queue_data;
+
+typedef void (*gnttab_unmap_refs_done)(int result, struct
gntab_unmap_queue_data *data);
+
+struct gntab_unmap_queue_data
+{
+ struct delayed_work gnttab_work;
+ void *data;
+ gnttab_unmap_refs_done done;
+ struct gnttab_unmap_grant_ref *unmap_ops;
+ struct gnttab_unmap_grant_ref *kunmap_ops;
+ struct page **pages;
+ unsigned int count;
+ unsigned int age;
+};
+
int gnttab_init(void);
int gnttab_suspend(void);
int gnttab_resume(void);
@@ -174,6 +190,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count);
+void gnttab_unmap_refs_async(struct gntab_unmap_queue_data* item);
+
/* Perform a batch of grant map/copy operations. Retry every batch slot
* for which the hypervisor returns GNTST_eagain. This is typically due
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv4 10/14] xen/gntdev: convert priv-lock to a mutex
On Mon, 26 Jan 2015, David Vrabel wrote:
Unmapping may require sleeping and we unmap while holding priv-lock, so
convert it to a mutex.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/xen/gntdev.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index a28807a..c1a03fa 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -67,7 +67,7 @@ struct gntdev_priv {
* Only populated if populate_freeable_maps == 1 */
struct list_head freeable_maps;
/* lock protects maps and freeable_maps */
- spinlock_t lock;
+ struct mutex lock;
struct mm_struct *mm;
struct mmu_notifier mn;
};
@@ -221,9 +221,9 @@ static void gntdev_put_map(struct gntdev_priv *priv,
struct grant_map *map)
}
if (populate_freeable_maps priv) {
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
list_del(map-next);
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
}
if (map-pages !use_ptemod)
@@ -397,9 +397,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma)
* not do any unmapping, since that has been done prior to
* closing the vma, but it may still iterate the unmap_ops list.
*/
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
map-vma = NULL;
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
}
vma-vm_private_data = NULL;
gntdev_put_map(priv, map);
@@ -443,14 +443,14 @@ static void mn_invl_range_start(struct mmu_notifier *mn,
struct gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn);
struct grant_map *map;
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
list_for_each_entry(map, priv-maps, next) {
unmap_if_in_range(map, start, end);
}
list_for_each_entry(map, priv-freeable_maps, next) {
unmap_if_in_range(map, start, end);
}
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
}
I don't think that mmu_notifier callbacks are allowed to sleep:
https://lkml.org/lkml/2010/1/25/187
static void mn_invl_page(struct mmu_notifier *mn,
@@ -467,7 +467,7 @@ static void mn_release(struct mmu_notifier *mn,
struct grant_map *map;
int err;
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
list_for_each_entry(map, priv-maps, next) {
if (!map-vma)
continue;
@@ -486,7 +486,7 @@ static void mn_release(struct mmu_notifier *mn,
err = unmap_grant_pages(map, /* offset */ 0, map-count);
WARN_ON(err);
}
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
}
static struct mmu_notifier_ops gntdev_mmu_ops = {
@@ -508,7 +508,7 @@ static int gntdev_open(struct inode *inode, struct file
*flip)
INIT_LIST_HEAD(priv-maps);
INIT_LIST_HEAD(priv-freeable_maps);
- spin_lock_init(priv-lock);
+ mutex_init(priv-lock);
if (use_ptemod) {
priv-mm = get_task_mm(current);
@@ -582,10 +582,10 @@ static long gntdev_ioctl_map_grant_ref(struct
gntdev_priv *priv,
return -EFAULT;
}
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
gntdev_add_map(priv, map);
op.index = map-index PAGE_SHIFT;
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
if (copy_to_user(u, op, sizeof(op)) != 0)
return -EFAULT;
@@ -604,7 +604,7 @@ static long gntdev_ioctl_unmap_grant_ref(struct
gntdev_priv *priv,
return -EFAULT;
pr_debug(priv %p, del %d+%d\n, priv, (int)op.index, (int)op.count);
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
map = gntdev_find_map_index(priv, op.index PAGE_SHIFT, op.count);
if (map) {
list_del(map-next);
@@ -612,7 +612,7 @@ static long gntdev_ioctl_unmap_grant_ref(struct
gntdev_priv *priv,
list_add_tail(map-next, priv-freeable_maps);
err = 0;
}
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
if (map)
gntdev_put_map(priv, map);
return err;
@@ -680,7 +680,7 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv,
void __user *u)
out_flags = op.action;
out_event = op.event_channel_port;
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
list_for_each_entry(map, priv-maps, next) {
uint64_t begin = map-index PAGE_SHIFT;
@@ -708,7 +708,7 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv,
void __user *u)
rc = 0;
unlock_out:
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
/* Drop the reference to the event channel we did not
[Xen-devel] [PATCH] libxl_set_memory_target: only remove videoram from absolute targets
If the new target is relative to the current target, do not remove
videoram again: it has already been removed from the current target.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
Changes in v2:
- add videoram when setting maxmem.
---
tools/libxl/libxl.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 82227e8..cd6f42c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4764,13 +4764,17 @@ retry_transaction:
goto out;
}
+videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
+%s/memory/videoram, dompath));
+videoram = videoram_s ? atoi(videoram_s) : 0;
+
if (relative) {
if (target_memkb 0 abs(target_memkb) current_target_memkb)
new_target_memkb = 0;
else
new_target_memkb = current_target_memkb + target_memkb;
} else
-new_target_memkb = target_memkb;
+new_target_memkb = target_memkb - videoram;
if (new_target_memkb memorykb) {
LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
memory_dynamic_max must be less than or equal to
@@ -4786,12 +4790,9 @@ retry_transaction:
abort_transaction = 1;
goto out;
}
-videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
-%s/memory/videoram, dompath));
-videoram = videoram_s ? atoi(videoram_s) : 0;
if (enforce) {
-memorykb = new_target_memkb;
+memorykb = new_target_memkb + videoram;
rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb +
LIBXL_MAXMEM_CONSTANT);
if (rc != 0) {
@@ -4803,7 +4804,6 @@ retry_transaction:
}
}
-new_target_memkb -= videoram;
rc = xc_domain_set_pod_target(ctx-xch, domid,
new_target_memkb / 4, NULL, NULL, NULL);
if (rc != 0) {
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 13/14] xen/gntdev: mark userspace PTEs as special on x86 PV guests
In an x86 PV guest, get_user_pages_fast() on a userspace address range
containing foreign mappings does not work correctly because the M2P
lookup of the MFN from a userspace PTE may return the wrong page.
Force get_user_pages_fast() to fail on such addresses by marking the PTEs
as special.
If Xen has XENFEAT_gnttab_map_avail_bits (available since at least
4.0), we can do so efficiently in the grant map hypercall. Otherwise,
it needs to be done afterwards. This is both inefficient and racy
(the mapping is visible to the task before we fixup the PTEs), but
will be fine for well-behaved applications that do not use the mapping
until after the mmap() system call returns.
Guests with XENFEAT_auto_translated_physmap (ARM and x86 HVM or PVH)
do not need this since get_user_pages() has always worked correctly
for them.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/xen/gntdev.c| 32 ++--
include/xen/interface/features.h|6 ++
include/xen/interface/grant_table.h |7 +++
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 494bd06..8ea10eb 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -244,11 +244,24 @@ static int find_grant_ptes(pte_t *pte, pgtable_t token,
BUG_ON(pgnr = map-count);
pte_maddr = arbitrary_virt_to_machine(pte).maddr;
+ /*
+* Set the PTE as special to force get_user_pages_fast() fall
+* back to the slow path. If this is not supported as part of
+* the grant map, it will be done afterwards.
+*/
+ if (xen_feature(XENFEAT_gnttab_map_avail_bits))
+ flags |= (1 _GNTMAP_guest_avail0);
+
gnttab_set_map_op(map-map_ops[pgnr], pte_maddr, flags,
map-grants[pgnr].ref,
map-grants[pgnr].domid);
- gnttab_set_unmap_op(map-unmap_ops[pgnr], pte_maddr, flags,
- -1 /* handle */);
+ return 0;
+}
+
+static int set_grant_ptes_as_special(pte_t *pte, pgtable_t token,
+unsigned long addr, void *data)
+{
+ set_pte_at(current-mm, addr, pte, pte_mkspecial(*pte));
return 0;
}
@@ -842,6 +855,21 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
if (err)
goto out_put_map;
}
+ } else {
+ /*
+* If the PTEs were not made special by the grant map
+* hypercall, do so here.
+*
+* This is racy since the mapping is already visible
+* to userspace but userspace should be well-behaved
+* enough to not touch it until the mmap() call
+* returns.
+*/
+ if (!xen_feature(XENFEAT_gnttab_map_avail_bits)) {
+ apply_to_page_range(vma-vm_mm, vma-vm_start,
+ vma-vm_end - vma-vm_start,
+ set_grant_ptes_as_special, NULL);
+ }
}
return 0;
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index 131a6cc..6ad3d11 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -41,6 +41,12 @@
/* x86: Does this Xen host support the MMU_PT_UPDATE_PRESERVE_AD hypercall? */
#define XENFEAT_mmu_pt_update_preserve_ad 5
+/*
+ * If set, GNTTABOP_map_grant_ref honors flags to be placed into guest kernel
+ * available pte bits.
+ */
+#define XENFEAT_gnttab_map_avail_bits 7
+
/* x86: Does this Xen host support the HVM callback vector type? */
#define XENFEAT_hvm_callback_vector8
diff --git a/include/xen/interface/grant_table.h
b/include/xen/interface/grant_table.h
index bcce564..56806bc 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -526,6 +526,13 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_cache_flush);
#define GNTMAP_contains_pte (1_GNTMAP_contains_pte)
/*
+ * Bits to be placed in guest kernel available PTE bits (architecture
+ * dependent; only supported when XENFEAT_gnttab_map_avail_bits is set).
+ */
+#define _GNTMAP_guest_avail0(16)
+#define GNTMAP_guest_avail_mask ((uint32_t)~0 _GNTMAP_guest_avail0)
+
+/*
* Values for error status returns. All errors are -ve.
*/
#define GNTST_okay (0) /* Normal return.*/
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 12/14] xen-blkback: safely unmap grants in case they are still in use
On 01/26/2015 08:02 AM, David Vrabel wrote: On 19/01/15 15:51, David Vrabel wrote: From: Jenny Herbert jennifer.herb...@citrix.com Use gnttab_unmap_refs_async() to wait until the mapped pages are no longer in use before unmapping them. This allows blkback to use network storage which may retain refs to pages in queued skbs after the block I/O has completed. Hi Jens, This xen-blkback change depends on several Xen changes and it would be easiest if this went via the Xen tree. Are you ok with this? Yeah, that's fine. You can add my acked-by. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues
On Mon, Jan 26, 2015 at 04:36:03PM +, Andrew Cooper wrote: On 26/01/15 16:27, Konrad Rzeszutek Wilk wrote: Hey Jan, Andrew, I am hoping you can help me in directing me where I ought to go next in debugging this. This is a Lenovo Thinkpad x230 with the latest BIOS and Xen 4.6 (todays 'staging' + my patches). Initially when I installed Xen the first time it would hang when loading the efi_vars module in Linux. Debugging a bit more and I found out that the issue is that we crash when calling GetNextVariableName (works fine with GetTime/SetTime, hand't tried GetVariable). I decided to implement in the hypervisor a little loop that would call GetNextVariableName and it works on my ASUS M5A87 board nicely. (attached at the bottom for comparison) However on this laptop it keeps on crashing. I've also added a bit of code to get the binary code from the GetNextVariableName to see if it looks legit - and it looks OK (obviously different from what the ASUS has implemented). Anyhow I am bit stuck: 1) It works with Linux, so what is it that Linux does that Xen does not? 2). I can't make sense of the stack trace. The efi firmware doesn't use frame pointers, but Xen does, which causes its stack tracing to get confused. This is on my todo list to fix since the last stack trace you submitted. You could see about creating a debug xen with frame_pointer=n during the build, which will cause Xen to use the non-frame pointer aware stack trace algorithm. That would help analyse the issue. Got a bit further. See for fun my inline comments. (XEN)1:[ Xen-4.6-unstable x86_64 debug=n Not tainted ] (XEN) CPU:0 (XEN) RIP:e008:[000f] 000f (XEN) RFLAGS: 00010207 CONTEXT: hypervisor (XEN) rax: cfdba230 rbx: 830216b3aa00 rcx: 001f (XEN) rdx: d6995ed0 rsi: 00150670 rdi: 830216b3aa00 (XEN) rbp: 82d080457de8 rsp: 82d080457d50 r8: 82d080457df0 (XEN) r9: 8000 r10: 82d080457c5c r11: db002700 (XEN) r12: 82d080457df0 r13: r14: (XEN) r15: d1079000 cr0: 80050033 cr4: 001506f0 (XEN) cr3: 000216b3d000 cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=82d080457d50: (XEN)68f2 d6994d77 82d080498b30 0206 (XEN)d1079000 830216b39080 830216b3a580 82d080457df8 (XEN)000216b3d000 82d080229c7a 830216b3aa00 830216b39080 (XEN)00150670 82d080229c4a 0002 00010008 (XEN)82d080457df0 82d080457de8 82d080269c00 0400 (XEN)82d080457e40 82d080457e00 0003 830216b4a4f0 (XEN)0002 0008 0003 8300d124b000 (XEN)82d080269c00 82d0804259b6 8300d124b000 8300d124afa0 (XEN)7d2f0002 8300d123abe5 012b 00021ab35000 (XEN) 0021e600 (XEN)d124afa0 ffd080499780 00499780 012b0fff (XEN)0010 0058bf90 0008 0001006e (XEN)0003 02f8 d123a240 (XEN)d0793408 d0eff3e8 00057000 fed2 (XEN)2960 (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) Xen call trace: (XEN)[000f] 000f (XEN)[82d080229c7a] efi_debug+0x24a/0x3c0 (XEN)[82d080229c4a] efi_debug+0x21a/0x3c0 (XEN)[82d0804259b6] __start_xen+0x25b6/0x3bc0 (XEN) Which is: 0x5a6 efi_debug+550: mov0x0(%rip),%rax# 0x5ad efi_debug+557 0x5ad efi_debug+557: movq $0x400,0x28(%rsp) 0x5b6 efi_debug+566: sub$0x20,%rsp 0x5ba efi_debug+570: mov0x30(%rsp),%r8 0x5bf efi_debug+575: mov0x38(%rsp),%rcx 0x5c4 efi_debug+580: mov%rbx,%rdx 0x5c7 efi_debug+583: callq *0x50(%rax) 0x5ca efi_debug+586: add$0x20,%rsp (0x24a = 586 in decimal) And this is the EFI code: 0: 48 89 5c 24 08 mov%rbx,0x8(%rsp) 5: 48 89 6c 24 10 mov%rbp,0x10(%rsp) a: 48 89 74 24 18 mov%rsi,0x18(%rsp) f: 57 push %rdi 10: 41 54 push %r12 12: 41 55 push
Re: [Xen-devel] [PATCH RFC 0/5] Split off mini-os to a separate tree
On 26 Jan 2015, at 18:21, Martin Lucina mar...@lucina.net wrote:
a...@recoil.org said:
On 26 Jan 2015, at 17:42, Martin Lucina mar...@lucina.net wrote:
tal...@gmail.com said:
In case it's useful: for the standalone version of Mini-OS used by
Mirage, I had to include these directories too:
1. xen/include/public
2. xen/common/libfdt
3. xen/include/xen/libfdt
4. config
( https://github.com/talex5/xen/tree/minios-releases )
Ah, so that's where the Mirage fork of Mini-OS lives. I knew there was one,
but not where. Any other forks please speak up :-)
Which parts of Mini-OS does Mirage actually use? I know you have an OCaml
implementation of netfront, for instance.
Not very much of Mini-OS -- Mirage has everything from the ring protocol
up (XenStore, NetBack/Front, BlkBack/Front, Console, etc are all in OCaml).
So event channels and start of day boot, mainly.
It is useful to have the C XenBus around for start-of-day logging though,
since the emergency console isn't much use on public cloud services.
Interesting. Rump Kernels on Xen currently use the Mini-OS xenbus,
{net,blk,pci}front and console, however AFAICT most (all?) of these could
be provided by the NetBSD drivers instead. Such a setup also would not
leave much from Mini-OS.
I'm wondering if there is interest in a Nano-OS that provides just the bare
minimum needed for Unikernels to run atop cloud hypervisors (hint hint)?
I think the current approach of just including the object files that are
needed by the implementation is fine. It's just the start_kernel (weak)
symbol that needs to call the initialisers for each subsystem, and the other
object files are pretty standalone. A few more #ifdefs could be sprinkled
around perhaps, but there's no need to break down MiniOS much more than it
already is.
-anil
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions
On Fri, Jan 23, 2015 at 10:50:23AM +, Jan Beulich wrote: On 22.01.15 at 18:34, elena.ufimts...@oracle.com wrote: On Thu, Jan 22, 2015 at 04:42:52PM +0100, Roger Pau Monné wrote: El 22/01/15 a les 16.18, Elena Ufimtseva ha escrit: - jbeul...@suse.com wrote: On 22.01.15 at 12:37, roger@citrix.com wrote: El 22/01/15 a les 12.09, Jan Beulich ha escrit: On 22.01.15 at 11:59, andrew.coop...@citrix.com wrote: On 22/01/15 09:53, Jan Beulich wrote: On 21.01.15 at 21:55, elena.ufimts...@oracle.com wrote: p2m_mmio_direct should result in setting IOMMUF_readable and IOMMUF_writable flags. When pvh domain maps mmio regions, the EPT entries are not getting mapped. This leads to IOMMU Page faults for some devices, as for example USB Host controllers with embedded Debug devices. See pvh-set-need_iommu-early RFC patch discussion fgor detail. Even more so that the two patches aren't even a series, that part of the description belongs here, not in the other patch. I will appreciate your comments and ideas in regards to this change. Looking at Roger patches (xen/pvh: check permissions when adding MMIO regions) the mmio memory type is proposed to be changed from p2m_mmio_direct to p2m_access_rw. This type still does not have proper IOMMU flags mapping. A fundamental question is what business devices have to DMA their own (or other devices') MMIO space. I could remotely see a need for this for e.g. frame buffers, but I have difficulty understanding this for USB devices. Please at the very least provide details on the MMIO regions that those devices have, and which of them you observed IOMMU faults on. It would appear that, in this case, it is a USB controller lacking an appropriate RMRR description in the ACPI tables. No, RMRRs only reference RAM pages afaik. According to Linux IOMMU support document RMRRs reference regions marked as reserved in the e820 memory map: https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt Exactly. And MMIO PCI BARs in particular are never to be reflected in the E820 (not the least because they're relocatable). I don't think we are setting proper IOMMU entries for this regions at all with the current PVH Dom0 code. IMHO instead of just adding IOMMU entries for every MMIO region we should just add IOMMU entries for the RMRR regions. Yes, RMRR regions should certainly be put there as r/w entries. Jan How it will help in cases like this when this regions are not reported as RMRRs in ACPI? AFAIK even if they are properly reported as RMRRs they won't have the right IOMMU mappings, are you sure they are not reported as RMRRs? Roger. Here are some details on machine config, lspci and etc. Bare metal: lspci 00:00.0 0600: 8086:0c00 (rev 06) Subsystem: 17aa:3097 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? Kernel driver in use: hsw_uncore 00:02.0 0300: 8086:0412 (rev 06) (prog-if 00 [VGA controller]) Subsystem: 17aa:3097 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 30 Region 0: Memory at f780 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00018 Data: Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 00:03.0 0403: 8086:0c0c (rev 06) Subsystem: 17aa:3097 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 31 Region 0: Memory at f7c3 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
[Xen-devel] [PATCH v2] libxl_set_memory_target: retain the same maxmem offset on top of the current target
In libxl_set_memory_target when setting the new maxmem, retain the same
offset on top of the current target. The offset includes memory
allocated by QEMU for rom files.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
Changes in v2:
- remove LIBXL_MAXMEM_CONSTANT from LIBXL__LOG_ERRNO.
---
tools/libxl/libxl.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index cd6f42c..04062dd 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4717,6 +4717,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
domid,
char *uuid;
xs_transaction_t t;
+if (libxl_domain_info(ctx, ptr, domid) 0)
+goto out_no_transaction;
+
retry_transaction:
t = xs_transaction_start(ctx-xsh);
@@ -4791,14 +4794,13 @@ retry_transaction:
goto out;
}
-if (enforce) {
-memorykb = new_target_memkb + videoram;
-rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb +
-LIBXL_MAXMEM_CONSTANT);
+if (enforce new_target_memkb 0) {
+memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
+rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb);
if (rc != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
xc_domain_setmaxmem domid=%d memkb=%d failed
-rc=%d\n, domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
+rc=%d\n, domid, memorykb, rc);
abort_transaction = 1;
goto out;
}
@@ -4823,8 +4825,6 @@ retry_transaction:
goto out;
}
-libxl_dominfo_init(ptr);
-xcinfo2xlinfo(ctx, info, ptr);
uuid = libxl__uuid2string(gc, ptr.uuid);
libxl__xs_write(gc, t, libxl__sprintf(gc, /vm/%s/memory, uuid),
%PRIu32, new_target_memkb / 1024);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 11/14] xen/gntdev: safely unmap grants in case they are still in use
From: Jennifer Herbert jennifer.herb...@citrix.com
Use gnttab_unmap_refs_async() to wait until the mapped pages are no
longer in use before unmapping them.
This allows userspace programs to safely use Direct I/O and AIO to a
network filesystem which may retain refs to pages in queued skbs after
the filesystem I/O has completed.
Signed-off-by: Jennifer Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/xen/gntdev.c | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index c1a03fa..494bd06 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -311,9 +311,30 @@ static int map_grant_pages(struct grant_map *map)
return err;
}
+struct unmap_grant_pages_callback_data
+{
+ struct completion completion;
+ int result;
+};
+
+static void unmap_grant_callback(int result,
+struct gntab_unmap_queue_data *data)
+{
+ struct unmap_grant_pages_callback_data* d = data-data;
+
+ d-result = result;
+ complete(d-completion);
+}
+
static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
{
int i, err = 0;
+ struct gntab_unmap_queue_data unmap_data;
+ struct unmap_grant_pages_callback_data data;
+
+ init_completion(data.completion);
+ unmap_data.data = data;
+ unmap_data.done= unmap_grant_callback;
if (map-notify.flags UNMAP_NOTIFY_CLEAR_BYTE) {
int pgno = (map-notify.addr PAGE_SHIFT);
@@ -325,11 +346,16 @@ static int __unmap_grant_pages(struct grant_map *map, int
offset, int pages)
}
}
- err = gnttab_unmap_refs(map-unmap_ops + offset,
- use_ptemod ? map-kunmap_ops + offset : NULL,
map-pages + offset,
- pages);
- if (err)
- return err;
+ unmap_data.unmap_ops = map-unmap_ops + offset;
+ unmap_data.kunmap_ops = use_ptemod ? map-kunmap_ops + offset : NULL;
+ unmap_data.pages = map-pages + offset;
+ unmap_data.count = pages;
+
+ gnttab_unmap_refs_async(unmap_data);
+
+ wait_for_completion(data.completion);
+ if (data.result)
+ return data.result;
for (i = 0; i pages; i++) {
if (map-unmap_ops[offset+i].status)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 14/14] xen/gntdev: provide find_special_page VMA operation
For a PV guest, use the find_special_page op to find the right page.
To handle VMAs being split, remember the start of the original VMA so
the correct index in the pages array can be calculated.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/xen/gntdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 8ea10eb..826e731 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -93,6 +93,7 @@ struct grant_map {
struct gnttab_map_grant_ref *kmap_ops;
struct gnttab_unmap_grant_ref *kunmap_ops;
struct page **pages;
+ unsigned long pages_vm_start;
};
static int unmap_grant_pages(struct grant_map *map, int offset, int pages);
@@ -444,9 +445,18 @@ static void gntdev_vma_close(struct vm_area_struct *vma)
gntdev_put_map(priv, map);
}
+static struct page *gntdev_vma_find_special_page(struct vm_area_struct *vma,
+unsigned long addr)
+{
+ struct grant_map *map = vma-vm_private_data;
+
+ return map-pages[(addr - map-pages_vm_start) PAGE_SHIFT];
+}
+
static struct vm_operations_struct gntdev_vmops = {
.open = gntdev_vma_open,
.close = gntdev_vma_close,
+ .find_special_page = gntdev_vma_find_special_page,
};
/* -- */
@@ -870,6 +880,8 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
vma-vm_end - vma-vm_start,
set_grant_ptes_as_special, NULL);
}
+
+ map-pages_vm_start = vma-vm_start;
}
return 0;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 12/14] xen-blkback: safely unmap grants in case they are still in use
From: Jennifer Herbert jennifer.herb...@citrix.com
Use gnttab_unmap_refs_async() to wait until the mapped pages are no
longer in use before unmapping them.
This allows blkback to use network storage which may retain refs to
pages in queued skbs after the block I/O has completed.
Signed-off-by: Jennifer Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/block/xen-blkback/blkback.c | 166 ---
drivers/block/xen-blkback/common.h |3 +
2 files changed, 119 insertions(+), 50 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index 908e630..804a81a 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -47,6 +47,7 @@
#include asm/xen/hypervisor.h
#include asm/xen/hypercall.h
#include xen/balloon.h
+#include xen/grant_table.h
#include common.h
/*
@@ -262,6 +263,17 @@ static void put_persistent_gnt(struct xen_blkif *blkif,
atomic_dec(blkif-persistent_gnt_in_use);
}
+static void free_persistent_gnts_unmap_callback(int result,
+ struct gntab_unmap_queue_data
*data)
+{
+ struct completion *c = data-data;
+
+ /* BUG_ON used to reproduce existing behaviour,
+ but is this the best way to deal with this? */
+ BUG_ON(result);
+ complete(c);
+}
+
static void free_persistent_gnts(struct xen_blkif *blkif, struct rb_root *root,
unsigned int num)
{
@@ -269,8 +281,17 @@ static void free_persistent_gnts(struct xen_blkif *blkif,
struct rb_root *root,
struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
struct persistent_gnt *persistent_gnt;
struct rb_node *n;
- int ret = 0;
int segs_to_unmap = 0;
+ struct gntab_unmap_queue_data unmap_data;
+ struct completion unmap_completion;
+
+ init_completion(unmap_completion);
+
+ unmap_data.data = unmap_completion;
+ unmap_data.done = free_persistent_gnts_unmap_callback;
+ unmap_data.pages = pages;
+ unmap_data.unmap_ops = unmap;
+ unmap_data.kunmap_ops = NULL;
foreach_grant_safe(persistent_gnt, n, root, node) {
BUG_ON(persistent_gnt-handle ==
@@ -285,9 +306,11 @@ static void free_persistent_gnts(struct xen_blkif *blkif,
struct rb_root *root,
if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
!rb_next(persistent_gnt-node)) {
- ret = gnttab_unmap_refs(unmap, NULL, pages,
- segs_to_unmap);
- BUG_ON(ret);
+
+ unmap_data.count = segs_to_unmap;
+ gnttab_unmap_refs_async(unmap_data);
+ wait_for_completion(unmap_completion);
+
put_free_pages(blkif, pages, segs_to_unmap);
segs_to_unmap = 0;
}
@@ -653,18 +676,14 @@ void xen_blkbk_free_caches(struct xen_blkif *blkif)
shrink_free_pagepool(blkif, 0 /* All */);
}
-/*
- * Unmap the grant references, and also remove the M2P over-rides
- * used in the 'pending_req'.
- */
-static void xen_blkbk_unmap(struct xen_blkif *blkif,
-struct grant_page *pages[],
-int num)
+static unsigned int xen_blkbk_unmap_prepare(
+ struct xen_blkif *blkif,
+ struct grant_page **pages,
+ unsigned int num,
+ struct gnttab_unmap_grant_ref *unmap_ops,
+ struct page **unmap_pages)
{
- struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
- struct page *unmap_pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
unsigned int i, invcount = 0;
- int ret;
for (i = 0; i num; i++) {
if (pages[i]-persistent_gnt != NULL) {
@@ -674,21 +693,92 @@ static void xen_blkbk_unmap(struct xen_blkif *blkif,
if (pages[i]-handle == BLKBACK_INVALID_HANDLE)
continue;
unmap_pages[invcount] = pages[i]-page;
- gnttab_set_unmap_op(unmap[invcount], vaddr(pages[i]-page),
+ gnttab_set_unmap_op(unmap_ops[invcount], vaddr(pages[i]-page),
GNTMAP_host_map, pages[i]-handle);
pages[i]-handle = BLKBACK_INVALID_HANDLE;
- if (++invcount == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
- ret = gnttab_unmap_refs(unmap, NULL, unmap_pages,
- invcount);
+ invcount++;
+ }
+
+ return invcount;
+}
+
+static void xen_blkbk_unmap_and_respond_callback(int result, struct
gntab_unmap_queue_data *data)
+{
+ struct pending_req* pending_req = (struct pending_req*) (data-data);
+ struct xen_blkif *blkif = pending_req-blkif;
+
+ /* BUG_ON used to reproduce existing behaviour,
+
[Xen-devel] [PATCHv4 10/14] xen/gntdev: convert priv-lock to a mutex
Unmapping may require sleeping and we unmap while holding priv-lock, so
convert it to a mutex.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/xen/gntdev.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index a28807a..c1a03fa 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -67,7 +67,7 @@ struct gntdev_priv {
* Only populated if populate_freeable_maps == 1 */
struct list_head freeable_maps;
/* lock protects maps and freeable_maps */
- spinlock_t lock;
+ struct mutex lock;
struct mm_struct *mm;
struct mmu_notifier mn;
};
@@ -221,9 +221,9 @@ static void gntdev_put_map(struct gntdev_priv *priv, struct
grant_map *map)
}
if (populate_freeable_maps priv) {
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
list_del(map-next);
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
}
if (map-pages !use_ptemod)
@@ -397,9 +397,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma)
* not do any unmapping, since that has been done prior to
* closing the vma, but it may still iterate the unmap_ops list.
*/
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
map-vma = NULL;
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
}
vma-vm_private_data = NULL;
gntdev_put_map(priv, map);
@@ -443,14 +443,14 @@ static void mn_invl_range_start(struct mmu_notifier *mn,
struct gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn);
struct grant_map *map;
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
list_for_each_entry(map, priv-maps, next) {
unmap_if_in_range(map, start, end);
}
list_for_each_entry(map, priv-freeable_maps, next) {
unmap_if_in_range(map, start, end);
}
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
}
static void mn_invl_page(struct mmu_notifier *mn,
@@ -467,7 +467,7 @@ static void mn_release(struct mmu_notifier *mn,
struct grant_map *map;
int err;
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
list_for_each_entry(map, priv-maps, next) {
if (!map-vma)
continue;
@@ -486,7 +486,7 @@ static void mn_release(struct mmu_notifier *mn,
err = unmap_grant_pages(map, /* offset */ 0, map-count);
WARN_ON(err);
}
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
}
static struct mmu_notifier_ops gntdev_mmu_ops = {
@@ -508,7 +508,7 @@ static int gntdev_open(struct inode *inode, struct file
*flip)
INIT_LIST_HEAD(priv-maps);
INIT_LIST_HEAD(priv-freeable_maps);
- spin_lock_init(priv-lock);
+ mutex_init(priv-lock);
if (use_ptemod) {
priv-mm = get_task_mm(current);
@@ -582,10 +582,10 @@ static long gntdev_ioctl_map_grant_ref(struct gntdev_priv
*priv,
return -EFAULT;
}
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
gntdev_add_map(priv, map);
op.index = map-index PAGE_SHIFT;
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
if (copy_to_user(u, op, sizeof(op)) != 0)
return -EFAULT;
@@ -604,7 +604,7 @@ static long gntdev_ioctl_unmap_grant_ref(struct gntdev_priv
*priv,
return -EFAULT;
pr_debug(priv %p, del %d+%d\n, priv, (int)op.index, (int)op.count);
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
map = gntdev_find_map_index(priv, op.index PAGE_SHIFT, op.count);
if (map) {
list_del(map-next);
@@ -612,7 +612,7 @@ static long gntdev_ioctl_unmap_grant_ref(struct gntdev_priv
*priv,
list_add_tail(map-next, priv-freeable_maps);
err = 0;
}
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
if (map)
gntdev_put_map(priv, map);
return err;
@@ -680,7 +680,7 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv,
void __user *u)
out_flags = op.action;
out_event = op.event_channel_port;
- spin_lock(priv-lock);
+ mutex_lock(priv-lock);
list_for_each_entry(map, priv-maps, next) {
uint64_t begin = map-index PAGE_SHIFT;
@@ -708,7 +708,7 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv,
void __user *u)
rc = 0;
unlock_out:
- spin_unlock(priv-lock);
+ mutex_unlock(priv-lock);
/* Drop the reference to the event channel we did not save in the map */
if (out_flags UNMAP_NOTIFY_SEND_EVENT)
@@ -758,7 +758,7 @@ static int
Re: [Xen-devel] [PATCH RFC 0/5] Split off mini-os to a separate tree
tal...@gmail.com said: In case it's useful: for the standalone version of Mini-OS used by Mirage, I had to include these directories too: 1. xen/include/public 2. xen/common/libfdt 3. xen/include/xen/libfdt 4. config ( https://github.com/talex5/xen/tree/minios-releases ) Ah, so that's where the Mirage fork of Mini-OS lives. I knew there was one, but not where. Any other forks please speak up :-) Which parts of Mini-OS does Mirage actually use? I know you have an OCaml implementation of netfront, for instance. Will there be a separate mailing list for Mini-OS? That would be very useful for people who don't want to keep up with xen-devel. +1 It would be useful to coordinate work. We (Rump Kernels) have also done a bunch of changes to our fork [1], including ongoing work on namespacing Mini-OS APIs (see [2] in case you missed it). Martin [1] https://github.com/rumpkernel/rumprun-xen/tree/master/xen [2] http://thread.gmane.org/gmane.comp.rumpkernel.user/581 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 2/3] mg-branch-setup: New script
Also, update the README.dev accordingly
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
README.dev | 77 +++-
mg-branch-setup | 106 +++
2 files changed, 134 insertions(+), 49 deletions(-)
create mode 100755 mg-branch-setup
diff --git a/README.dev b/README.dev
index e9458a3..3303e77 100644
--- a/README.dev
+++ b/README.dev
@@ -69,60 +69,39 @@ former case, disables everything; in the latter, just that
branch)
Creating a new branch
=
-As osstest@osstest:
-
-$ cd branches
-
-($branch sort of matching ap-fetch-version modulo wildcards and must
-match cron invocation)
-
-$ cd ~osstest/branches
-$ umask 002
-$ git clone ../testing.git for-$branch.git
-
-If you want to bisect then:
-$ cd ../bisects
-$ git clone ../testing.git for-$branch.git
-
-$ cd ../branches
-$ ln -s /export/home/osstest/bisects/for-$branch.git
for-$branch.git/tree-bisect
-
-$ mkdir for-$branch.git/tmp
-# For manual playing only.
-
-Now can play in here. Can push random stuff and run
-cr-daily-branch --real $branch as osstest@osstest. e.g.
+* Add appropriate code to ap-*
+ (For linux-* this is not needed if the tag is in the standard namespace)
+ (ap-push should use refs/heads/foo, not just `foo', for the remote
+ ref name - so that the initial push works)
+
+* Create any necessary output tree on xenbits:
+ As xen@xenbits do mkdir and git init --bare
+ If this tree is going to contain push gate input, push something to
+ the push gate input ref.
+
+* Create the actual trees and push an initial version
+ As osstest@osstest:
+ $ cd $HOME/testing.git
+ $ OSSTEST_CONFIG=production-config \
+./mg-branch-setup BRANCH bisect INITIAL-TESTED-VERSION
+
+* Optional testing:
+ You can now play in here if you like. Can push random stuff and run
+ cr-daily-branch --real $branch as osstest@osstest. e.g.
$ OSSTEST_EMAIL_HEADER=/home/ianc/osstest-email-ijc \
OSSTEST_CONFIG=production-config ./cr-daily-branch --real $branch
-Note: Push to incoming and git reset --hard incoming
-Note2:
-$ cat ~/osstest-email-ijc
-To: ian.campb...@citrix.com
-
-Do not run cr-for-branches -- it will try to update all sorts trees
-etc.
-
-Need to create any xenbits trees which are referenced:
-
-As xen@xenbits do mkdir and git init --bare, but this might confuse
-cr-daily-branches so you would want to push something there
-(e.g. current master, easiest to do as osstest@osstest). Or git clone
---bare but might create all sorts of unwanted refs.
-
-Use ap-push to populate tree, in order to test ap-push, after using
-ap-fetch-version to populate the local repo. e.g.
-OSSTEST_CONFIG=production-config ./ap-fetch-version $branch
-OSSTEST_CONFIG=production-config ./ap-push $branch $revision
+ If you do this, do not run cr-for-branches -- it will try to update
+ all sorts trees etc.
-NOTE: $revision must be a revision *not* a tag. If you want to start
-with a known baseline then git rev-parse FOO~0 it first.
-NOTE2: ap-push should use refs/heads/foo explicitly so that this
-initial push works
+ Before enabling this in cron (eg by pushing the change to BRANCHES
+ to production pretest branch), rewind so that osstest can fast
+ forward it to the actual production version. Ie in bisects and
+ branches for-$branch.git,
+ git fetch origin incoming
+ git reset --hard FETCH_HEAD
-When pushing the patches, be sure to make sure that the
-for-$branch.git repo can fast forward to the pushed version (perhaps
-by resetting it).
+$ Add to BRANCHES setting in cr-for-branches
Force pushing a branch
==
diff --git a/mg-branch-setup b/mg-branch-setup
new file mode 100755
index 000..b0c9712
--- /dev/null
+++ b/mg-branch-setup
@@ -0,0 +1,106 @@
+#!/bin/bash
+#
+# usage:
+# ./mg-branch-setup BRANCH bisect INITIAL-TESTED-VERSION
+# ./mg-branch-setup BRANCH no-bisect
+# ./mg-branch-setup BRANCH no-check
+#
+# - checks that ap-fetch works (only if not `no-check')
+# - creates the tree in ~osstest/branches
+# - if applicable, creates the tree in ~osstest/bisects
+# - if applicable, pushes INITIAL-TESTED-VERSION with ap-push
+#
+# Does NOT
+# - add anything to the branch list in cr-for-branches
+# - create any input/output tree on xenbits
+# - run any test flights (obviously)
+
+set -e
+
+fail () { echo 2 $*; exit 1; }
+badusage () { fail 'bad usage'; }
+need_value () {
+ case $1 in
+ -*|'') badusage ;;
+ esac
+}
+
+branch=$1; shift
+need_value $branch
+
+mode=$1; shift
+
+case $mode in
+bisect)
+ fetch=true
+ push=true
+ bisect=true
+ push_version=$1; shift
+ need_value $push_version
+ ;;
+no-bisect)
+ fetch=true
+ push=false
+ bisect=false
+ ;;
+no-check)
+ fetch=false
+ push=false
+ bisect=false
+ ;;
+*)
+ badusage
+ ;;
+esac
+
+if [ $# != 0 ]; then badusage; fi
+
+umask 002
+
[Xen-devel] [OSSTEST PATCH 3/3] linux-3.16: New branch
Test this too. We fetch this from the Canonical Kernel Team (ckt)
repo, but do not encode `ckt' in the branch name, in case this becomes
a proper stable tree.
(I have set up this branch on the osstest with the mg-branch-setup
script in this version of this tree.)
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
ap-common |5 +
cr-for-branches |2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/ap-common b/ap-common
index 014dd76..f1eba6f 100644
--- a/ap-common
+++ b/ap-common
@@ -109,6 +109,11 @@ info_linux_tree () {
: ${TAG_LINUX_THIS:=linux-arm-xen}
: ${TAG_LINUX_ARM_THIS:=linux-arm-xen}
;;
+ linux-3.16)
+ # unofficial Ubuntu (Canonical) kernel team (ckt) for now
+ : ${TREE_LINUX_THIS:=git://kernel.ubuntu.com/ubuntu/linux.git}
+ : ${TAG_LINUX_THIS:=$1.y}
+ ;;
linux-3.*)
: ${TREE_LINUX_THIS:=${KERNEL_SCM}/stable/linux-stable.git}
: ${TAG_LINUX_THIS:=$1.y}
diff --git a/cr-for-branches b/cr-for-branches
index 65beb12..cbd1c74 100755
--- a/cr-for-branches
+++ b/cr-for-branches
@@ -31,7 +31,7 @@ scriptoptions=$1; shift
LOGFILE=tmp/cr-for-branches.log
export LOGFILE
-: ${BRANCHES:=osstest xen-4.0-testing xen-4.1-testing xen-4.2-testing
xen-4.3-testing xen-4.4-testing xen-4.5-testing xen-unstable qemu-mainline
qemu-upstream-unstable qemu-upstream-4.2-testing qemu-upstream-4.3-testing
qemu-upstream-4.4-testing qemu-upstream-4.5-testing linux-3.14 linux-3.10
linux-3.4 linux-arm-xen seabios ovmf ${EXTRA_BRANCHES}}
+: ${BRANCHES:=osstest xen-4.0-testing xen-4.1-testing xen-4.2-testing
xen-4.3-testing xen-4.4-testing xen-4.5-testing xen-unstable qemu-mainline
qemu-upstream-unstable qemu-upstream-4.2-testing qemu-upstream-4.3-testing
qemu-upstream-4.4-testing qemu-upstream-4.5-testing linux-3.16 linux-3.14
linux-3.10 linux-3.4 linux-arm-xen seabios ovmf ${EXTRA_BRANCHES}}
export BRANCHES
fetchwlem=$wlem
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 1/3] ap-common: Have ap-push for linux trees use refs/heads/
As per the docs in README.dev.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
ap-common |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ap-common b/ap-common
index e2c3e42..014dd76 100644
--- a/ap-common
+++ b/ap-common
@@ -136,7 +136,7 @@ info_linux_tree () {
: ${BASE_TREE_LINUX_THIS:=$BASE_TREE_LINUX}
: ${PUSH_TREE_LINUX_THIS:=$PUSH_TREE_LINUX}
: ${BASE_TAG_LINUX_THIS:=tested/$1}
- : ${PUSH_TAG_LINUX_THIS:=$BASE_TAG_LINUX_THIS}
+ : ${PUSH_TAG_LINUX_THIS:=refs/heads/$BASE_TAG_LINUX_THIS}
return 0
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 04/14] xen: remove scratch frames for ballooned pages and m2p override
The scratch frame mappings for ballooned pages and the m2p override
are broken. Remove them in preparation for replacing them with
simpler mechanisms that works.
The scratch pages did not ensure that the page was not in use. In
particular, the foreign page could still be in use by hardware. If
the guest reused the frame the hardware could read or write that
frame.
The m2p override did not handle the same frame being granted by two
different grant references. Trying an M2P override lookup in this
case is impossible.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
arch/x86/include/asm/xen/page.h | 18 +--
arch/x86/xen/p2m.c | 254 ++-
drivers/xen/balloon.c | 86 +
3 files changed, 14 insertions(+), 344 deletions(-)
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index e9f52fe..358dcd3 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -57,7 +57,6 @@ extern int set_foreign_p2m_mapping(struct
gnttab_map_grant_ref *map_ops,
extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count);
-extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long
pfn);
/*
* Helper functions to write or read unsigned long values to/from
@@ -154,21 +153,12 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
return mfn;
pfn = mfn_to_pfn_no_overrides(mfn);
- if (__pfn_to_mfn(pfn) != mfn) {
- /*
-* If this appears to be a foreign mfn (because the pfn
-* doesn't map back to the mfn), then check the local override
-* table to see if there's a better pfn to use.
-*
-* m2p_find_override_pfn returns ~0 if it doesn't find anything.
-*/
- pfn = m2p_find_override_pfn(mfn, ~0);
- }
+ if (__pfn_to_mfn(pfn) != mfn)
+ pfn = ~0;
/*
-* pfn is ~0 if there are no entries in the m2p for mfn or if the
-* entry doesn't map back to the mfn and m2p_override doesn't have a
-* valid entry for it.
+* pfn is ~0 if there are no entries in the m2p for mfn or the
+* entry doesn't map back to the mfn.
*/
if (pfn == ~0 __pfn_to_mfn(mfn) == IDENTITY_FRAME(mfn))
pfn = mfn;
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index df40b28..c9bc53f 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -84,8 +84,6 @@
#define PMDS_PER_MID_PAGE (P2M_MID_PER_PAGE / PTRS_PER_PTE)
-static void __init m2p_override_init(void);
-
unsigned long *xen_p2m_addr __read_mostly;
EXPORT_SYMBOL_GPL(xen_p2m_addr);
unsigned long xen_p2m_size __read_mostly;
@@ -402,8 +400,6 @@ void __init xen_vmalloc_p2m_tree(void)
xen_p2m_size = xen_max_p2m_pfn;
xen_inv_extra_mem();
-
- m2p_override_init();
}
unsigned long get_phys_to_machine(unsigned long pfn)
@@ -652,100 +648,21 @@ bool set_phys_to_machine(unsigned long pfn, unsigned
long mfn)
return true;
}
-#define M2P_OVERRIDE_HASH_SHIFT10
-#define M2P_OVERRIDE_HASH (1 M2P_OVERRIDE_HASH_SHIFT)
-
-static struct list_head *m2p_overrides;
-static DEFINE_SPINLOCK(m2p_override_lock);
-
-static void __init m2p_override_init(void)
-{
- unsigned i;
-
- m2p_overrides = alloc_bootmem_align(
- sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
- sizeof(unsigned long));
-
- for (i = 0; i M2P_OVERRIDE_HASH; i++)
- INIT_LIST_HEAD(m2p_overrides[i]);
-}
-
-static unsigned long mfn_hash(unsigned long mfn)
-{
- return hash_long(mfn, M2P_OVERRIDE_HASH_SHIFT);
-}
-
-/* Add an MFN override for a particular page */
-static int m2p_add_override(unsigned long mfn, struct page *page,
- struct gnttab_map_grant_ref *kmap_op)
-{
- unsigned long flags;
- unsigned long pfn;
- unsigned long uninitialized_var(address);
- unsigned level;
- pte_t *ptep = NULL;
-
- pfn = page_to_pfn(page);
- if (!PageHighMem(page)) {
- address = (unsigned long)__va(pfn PAGE_SHIFT);
- ptep = lookup_address(address, level);
- if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-m2p_add_override: pfn %lx not mapped, pfn))
- return -EINVAL;
- }
-
- if (kmap_op != NULL) {
- if (!PageHighMem(page)) {
- struct multicall_space mcs =
- xen_mc_entry(sizeof(*kmap_op));
-
- MULTI_grant_table_op(mcs.mc,
- GNTTABOP_map_grant_ref, kmap_op, 1);
-
[Xen-devel] [PATCHv4 03/14] xen/grant-table: pre-populate kernel unmap ops for xen_gnttab_unmap_refs()
When unmapping grants, instead of converting the kernel map ops to
unmap ops on the fly, pre-populate the set of unmap ops.
This allows the grant unmap for the kernel mappings to be trivially
batched in the future.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
arch/arm/include/asm/xen/page.h |2 +-
arch/arm/xen/p2m.c |2 +-
arch/x86/include/asm/xen/page.h |2 +-
arch/x86/xen/p2m.c | 21 ++---
drivers/xen/gntdev.c| 26 ++
drivers/xen/grant-table.c |4 ++--
include/xen/grant_table.h |2 +-
7 files changed, 34 insertions(+), 25 deletions(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 68c739b..2f7e6ff 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -92,7 +92,7 @@ extern int set_foreign_p2m_mapping(struct
gnttab_map_grant_ref *map_ops,
struct page **pages, unsigned int count);
extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
-struct gnttab_map_grant_ref *kmap_ops,
+struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count);
bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index 0548577..cb7a14c 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -102,7 +102,7 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
- struct gnttab_map_grant_ref *kmap_ops,
+ struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count)
{
int i;
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 5eea099..e9f52fe 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -55,7 +55,7 @@ extern int set_foreign_p2m_mapping(struct
gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count);
extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
-struct gnttab_map_grant_ref *kmap_ops,
+struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count);
extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long
pfn);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 70fb507..df40b28 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -816,7 +816,7 @@ static struct page *m2p_find_override(unsigned long mfn)
}
static int m2p_remove_override(struct page *page,
- struct gnttab_map_grant_ref *kmap_op,
+ struct gnttab_unmap_grant_ref *kunmap_op,
unsigned long mfn)
{
unsigned long flags;
@@ -840,7 +840,7 @@ static int m2p_remove_override(struct page *page,
list_del(page-lru);
spin_unlock_irqrestore(m2p_override_lock, flags);
- if (kmap_op != NULL) {
+ if (kunmap_op != NULL) {
if (!PageHighMem(page)) {
struct multicall_space mcs;
struct gnttab_unmap_and_replace *unmap_op;
@@ -855,13 +855,13 @@ static int m2p_remove_override(struct page *page,
* issued. In this case handle is going to -1 because
* it hasn't been modified yet.
*/
- if (kmap_op-handle == -1)
+ if (kunmap_op-handle == -1)
xen_mc_flush();
/*
* Now if kmap_op-handle is negative it means that the
* hypercall actually returned an error.
*/
- if (kmap_op-handle == GNTST_general_error) {
+ if (kunmap_op-handle == GNTST_general_error) {
pr_warn(m2p_remove_override: pfn %lx mfn %lx,
failed to modify kernel mappings,
pfn, mfn);
put_balloon_scratch_page();
@@ -873,9 +873,9 @@ static int m2p_remove_override(struct page *page,
mcs = __xen_mc_entry(
sizeof(struct gnttab_unmap_and_replace));
unmap_op = mcs.args;
- unmap_op-host_addr = kmap_op-host_addr;
+ unmap_op-host_addr = kunmap_op-host_addr;
[Xen-devel] [PATCHv4 05/14] x86/xen: require ballooned pages for grant maps
From: Jennifer Herbert jennifer.herb...@citrix.com
Ballooned pages are always used for grant maps which means the
original frame does not need to be saved in page-index nor restored
after the grant unmap.
This allows the workaround in netback for the conflicting use of the
(unionized) page-index and page-pfmemalloc to be removed.
Signed-off-by: Jennifer Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
arch/x86/xen/p2m.c|5 +++--
drivers/net/xen-netback/netback.c |6 --
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index c9bc53f..a8691cb 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -682,9 +682,10 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
pfn = page_to_pfn(pages[i]);
WARN_ON(PagePrivate(pages[i]));
+ WARN(pfn_to_mfn(pfn) != INVALID_P2M_ENTRY, page must be
ballooned);
+
SetPagePrivate(pages[i]);
set_page_private(pages[i], mfn);
- pages[i]-index = pfn_to_mfn(pfn);
if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn {
ret = -ENOMEM;
@@ -718,7 +719,7 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref
*unmap_ops,
set_page_private(pages[i], INVALID_P2M_ENTRY);
WARN_ON(!PagePrivate(pages[i]));
ClearPagePrivate(pages[i]);
- set_phys_to_machine(pfn, pages[i]-index);
+ set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
}
if (kunmap_ops)
ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 908e65e..6441318 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1241,12 +1241,6 @@ static void xenvif_fill_frags(struct xenvif_queue
*queue, struct sk_buff *skb)
/* Take an extra reference to offset network stack's put_page */
get_page(queue-mmap_pages[pending_idx]);
}
- /* FIXME: __skb_fill_page_desc set this to true because page-pfmemalloc
-* overlaps with index, and mapping is not set. I think mapping
-* should be set. If delivered to local stack, it would drop this
-* skb in sk_filter unless the socket has the right to use it.
-*/
- skb-pfmemalloc = false;
}
static int xenvif_get_extras(struct xenvif_queue *queue,
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 02/14] mm: add 'foreign' alias for the 'pinned' page flag
From: Jennifer Herbert jennifer.herb...@citrix.com
The foreign page flag will be used by Xen guests to mark pages that
have grant mappings of frames from other (foreign) guests.
The foreign flag is an alias for the existing (Xen-specific) pinned
flag. This is safe because pinned is only used on pages used for page
tables and these cannot also be foreign.
Signed-off-by: Jennifer Herbert jennifer.herb...@citrix.com
Acked-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: David Vrabel david.vra...@citrix.com
---
include/linux/page-flags.h |5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index e1f5fcd..5ed7bda 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -121,8 +121,12 @@ enum pageflags {
PG_fscache = PG_private_2, /* page backed by cache */
/* XEN */
+ /* Pinned in Xen as a read-only pagetable page. */
PG_pinned = PG_owner_priv_1,
+ /* Pinned as part of domain save (see xen_mm_pin_all()). */
PG_savepinned = PG_dirty,
+ /* Has a grant mapping of another (foreign) domain's page. */
+ PG_foreign = PG_owner_priv_1,
/* SLOB */
PG_slob_free = PG_private,
@@ -215,6 +219,7 @@ __PAGEFLAG(Slab, slab)
PAGEFLAG(Checked, checked) /* Used by some filesystems */
PAGEFLAG(Pinned, pinned) TESTSCFLAG(Pinned, pinned)/* Xen */
PAGEFLAG(SavePinned, savepinned); /* Xen */
+PAGEFLAG(Foreign, foreign);/* Xen */
PAGEFLAG(Reserved, reserved) __CLEARPAGEFLAG(Reserved, reserved)
PAGEFLAG(SwapBacked, swapbacked) __CLEARPAGEFLAG(SwapBacked, swapbacked)
__SETPAGEFLAG(SwapBacked, swapbacked)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 08/14] xen-netback: use foreign page information from the pages themselves
From: Jennifer Herbert jennifer.herb...@citrix.com
Use the foreign page flag in netback to get the domid and grant ref
needed for the grant copy. This signficiantly simplifies the netback
code and makes netback work with foreign pages from other backends
(e.g., blkback).
This allows blkback to use iSCSI disks provided by domUs running on
the same host.
Signed-off-by: Jennifer Herbert jennifer.herb...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Acked-by: David S. Miller da...@davemloft.net
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/net/xen-netback/netback.c | 100 -
1 file changed, 9 insertions(+), 91 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 6441318..ae3ab37 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -314,9 +314,7 @@ static struct xenvif_rx_meta *get_next_rx_buffer(struct
xenvif_queue *queue,
static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff
*skb,
struct netrx_pending_operations *npo,
struct page *page, unsigned long size,
-unsigned long offset, int *head,
-struct xenvif_queue *foreign_queue,
-grant_ref_t foreign_gref)
+unsigned long offset, int *head)
{
struct gnttab_copy *copy_gop;
struct xenvif_rx_meta *meta;
@@ -333,6 +331,8 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
*queue, struct sk_buff *skb
offset = ~PAGE_MASK;
while (size 0) {
+ struct xen_page_foreign *foreign;
+
BUG_ON(offset = PAGE_SIZE);
BUG_ON(npo-copy_off MAX_BUFFER_OFFSET);
@@ -361,9 +361,10 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
*queue, struct sk_buff *skb
copy_gop-flags = GNTCOPY_dest_gref;
copy_gop-len = bytes;
- if (foreign_queue) {
- copy_gop-source.domid = foreign_queue-vif-domid;
- copy_gop-source.u.ref = foreign_gref;
+ foreign = xen_page_foreign(page);
+ if (foreign) {
+ copy_gop-source.domid = foreign-domid;
+ copy_gop-source.u.ref = foreign-gref;
copy_gop-flags |= GNTCOPY_source_gref;
} else {
copy_gop-source.domid = DOMID_SELF;
@@ -406,35 +407,6 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
*queue, struct sk_buff *skb
}
/*
- * Find the grant ref for a given frag in a chain of struct ubuf_info's
- * skb: the skb itself
- * i: the frag's number
- * ubuf: a pointer to an element in the chain. It should not be NULL
- *
- * Returns a pointer to the element in the chain where the page were found. If
- * not found, returns NULL.
- * See the definition of callback_struct in common.h for more details about
- * the chain.
- */
-static const struct ubuf_info *xenvif_find_gref(const struct sk_buff *const
skb,
- const int i,
- const struct ubuf_info *ubuf)
-{
- struct xenvif_queue *foreign_queue = ubuf_to_queue(ubuf);
-
- do {
- u16 pending_idx = ubuf-desc;
-
- if (skb_shinfo(skb)-frags[i].page.p ==
- foreign_queue-mmap_pages[pending_idx])
- break;
- ubuf = (struct ubuf_info *) ubuf-ctx;
- } while (ubuf);
-
- return ubuf;
-}
-
-/*
* Prepare an SKB to be transmitted to the frontend.
*
* This function is responsible for allocating grant operations, meta
@@ -459,8 +431,6 @@ static int xenvif_gop_skb(struct sk_buff *skb,
int head = 1;
int old_meta_prod;
int gso_type;
- const struct ubuf_info *ubuf = skb_shinfo(skb)-destructor_arg;
- const struct ubuf_info *const head_ubuf = ubuf;
old_meta_prod = npo-meta_prod;
@@ -507,68 +477,16 @@ static int xenvif_gop_skb(struct sk_buff *skb,
len = skb_tail_pointer(skb) - data;
xenvif_gop_frag_copy(queue, skb, npo,
-virt_to_page(data), len, offset, head,
-NULL,
-0);
+virt_to_page(data), len, offset, head);
data += len;
}
for (i = 0; i nr_frags; i++) {
- /* This variable also signals whether foreign_gref has a real
-* value or not.
-*/
- struct xenvif_queue *foreign_queue = NULL;
- grant_ref_t foreign_gref;
-
- if ((skb_shinfo(skb)-tx_flags SKBTX_DEV_ZEROCOPY)
- (ubuf-callback ==
[Xen-devel] [PATCHv4 07/14] xen: mark grant mapped pages as foreign
From: Jennifer Herbert jennifer.herb...@citrix.com
Use the foreign page flag to mark pages that have a grant map. Use
page-private to store information of the grant (the granting domain
and the grant reference).
Signed-off-by: Jennifer Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
arch/x86/xen/p2m.c|7 ---
drivers/xen/grant-table.c | 43 +--
include/xen/grant_table.h | 20
3 files changed, 61 insertions(+), 9 deletions(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index a8691cb..f18fd1d 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -681,12 +681,8 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
}
pfn = page_to_pfn(pages[i]);
- WARN_ON(PagePrivate(pages[i]));
WARN(pfn_to_mfn(pfn) != INVALID_P2M_ENTRY, page must be
ballooned);
- SetPagePrivate(pages[i]);
- set_page_private(pages[i], mfn);
-
if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn {
ret = -ENOMEM;
goto out;
@@ -716,9 +712,6 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref
*unmap_ops,
goto out;
}
- set_page_private(pages[i], INVALID_P2M_ENTRY);
- WARN_ON(!PagePrivate(pages[i]));
- ClearPagePrivate(pages[i]);
set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
}
if (kunmap_ops)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b4f93c4..89dcca4 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -679,12 +679,27 @@ EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
*/
int gnttab_alloc_pages(int nr_pages, struct page **pages)
{
+ int i;
int ret;
ret = alloc_xenballooned_pages(nr_pages, pages, false);
if (ret 0)
return ret;
+ for (i = 0; i nr_pages; i++) {
+#if BITS_PER_LONG 64
+ struct xen_page_foreign *foreign;
+
+ foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
+ if (!foreign) {
+ gnttab_free_pages(nr_pages, pages);
+ return -ENOMEM;
+ }
+ set_page_private(pages[i], (unsigned long)foreign);
+#endif
+ SetPagePrivate(pages[i]);
+ }
+
return 0;
}
EXPORT_SYMBOL(gnttab_alloc_pages);
@@ -696,6 +711,16 @@ EXPORT_SYMBOL(gnttab_alloc_pages);
*/
void gnttab_free_pages(int nr_pages, struct page **pages)
{
+ int i;
+
+ for (i = 0; i nr_pages; i++) {
+ if (PagePrivate(pages[i])) {
+#if BITS_PER_LONG 64
+ kfree((void *)page_private(pages[i]));
+#endif
+ ClearPagePrivate(pages[i]);
+ }
+ }
free_xenballooned_pages(nr_pages, pages);
}
EXPORT_SYMBOL(gnttab_free_pages);
@@ -756,12 +781,22 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
if (ret)
return ret;
- /* Retry eagain maps */
- for (i = 0; i count; i++)
+ for (i = 0; i count; i++) {
+ /* Retry eagain maps */
if (map_ops[i].status == GNTST_eagain)
gnttab_retry_eagain_gop(GNTTABOP_map_grant_ref, map_ops
+ i,
map_ops[i].status, __func__);
+ if (map_ops[i].status == GNTST_okay) {
+ struct xen_page_foreign *foreign;
+
+ SetPageForeign(pages[i]);
+ foreign = xen_page_foreign(pages[i]);
+ foreign-domid = map_ops[i].dom;
+ foreign-gref = map_ops[i].ref;
+ }
+ }
+
return set_foreign_p2m_mapping(map_ops, kmap_ops, pages, count);
}
EXPORT_SYMBOL_GPL(gnttab_map_refs);
@@ -770,12 +805,16 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref
*unmap_ops,
struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count)
{
+ unsigned int i;
int ret;
ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops,
count);
if (ret)
return ret;
+ for (i = 0; i count; i++)
+ ClearPageForeign(pages[i]);
+
return clear_foreign_p2m_mapping(unmap_ops, kunmap_ops, pages, count);
}
EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 949803e..d3bef56 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -45,6 +45,8 @@
#include asm/xen/hypervisor.h
#include xen/features.h
+#include linux/mm_types.h
+#include linux/page-flags.h
#define GNTTAB_RESERVED_XENSTORE 1
@@ -185,4 +187,22 @@
[Xen-devel] [PATCHv4 06/14] xen/grant-table: add helpers for allocating pages
Add gnttab_alloc_pages() and gnttab_free_pages() to allocate/free pages
suitable to for granted maps.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/block/xen-blkback/blkback.c |8
drivers/net/xen-netback/interface.c |7 +++
drivers/xen/gntdev.c|4 ++--
drivers/xen/grant-table.c | 29 +
drivers/xen/xen-scsiback.c |6 +++---
include/xen/grant_table.h |3 +++
6 files changed, 44 insertions(+), 13 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index 63fc7f0..908e630 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -100,7 +100,7 @@ module_param(log_stats, int, 0644);
#define BLKBACK_INVALID_HANDLE (~0)
-/* Number of free pages to remove on each call to free_xenballooned_pages */
+/* Number of free pages to remove on each call to gnttab_free_pages */
#define NUM_BATCH_FREE_PAGES 10
static inline int get_free_page(struct xen_blkif *blkif, struct page **page)
@@ -111,7 +111,7 @@ static inline int get_free_page(struct xen_blkif *blkif,
struct page **page)
if (list_empty(blkif-free_pages)) {
BUG_ON(blkif-free_pages_num != 0);
spin_unlock_irqrestore(blkif-free_pages_lock, flags);
- return alloc_xenballooned_pages(1, page, false);
+ return gnttab_alloc_pages(1, page);
}
BUG_ON(blkif-free_pages_num == 0);
page[0] = list_first_entry(blkif-free_pages, struct page, lru);
@@ -151,14 +151,14 @@ static inline void shrink_free_pagepool(struct xen_blkif
*blkif, int num)
blkif-free_pages_num--;
if (++num_pages == NUM_BATCH_FREE_PAGES) {
spin_unlock_irqrestore(blkif-free_pages_lock, flags);
- free_xenballooned_pages(num_pages, page);
+ gnttab_free_pages(num_pages, page);
spin_lock_irqsave(blkif-free_pages_lock, flags);
num_pages = 0;
}
}
spin_unlock_irqrestore(blkif-free_pages_lock, flags);
if (num_pages != 0)
- free_xenballooned_pages(num_pages, page);
+ gnttab_free_pages(num_pages, page);
}
#define vaddr(page) ((unsigned long)pfn_to_kaddr(page_to_pfn(page)))
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 9259a73..2e07f84 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -483,9 +483,8 @@ int xenvif_init_queue(struct xenvif_queue *queue)
* better enable it. The long term solution would be to use just a
* bunch of valid page descriptors, without dependency on ballooning
*/
- err = alloc_xenballooned_pages(MAX_PENDING_REQS,
- queue-mmap_pages,
- false);
+ err = gnttab_alloc_pages(MAX_PENDING_REQS,
+queue-mmap_pages);
if (err) {
netdev_err(queue-vif-dev, Could not reserve mmap_pages\n);
return -ENOMEM;
@@ -662,7 +661,7 @@ void xenvif_disconnect(struct xenvif *vif)
*/
void xenvif_deinit_queue(struct xenvif_queue *queue)
{
- free_xenballooned_pages(MAX_PENDING_REQS, queue-mmap_pages);
+ gnttab_free_pages(MAX_PENDING_REQS, queue-mmap_pages);
}
void xenvif_free(struct xenvif *vif)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 32f6bfe..a28807a 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -119,7 +119,7 @@ static void gntdev_free_map(struct grant_map *map)
return;
if (map-pages)
- free_xenballooned_pages(map-count, map-pages);
+ gnttab_free_pages(map-count, map-pages);
kfree(map-pages);
kfree(map-grants);
kfree(map-map_ops);
@@ -152,7 +152,7 @@ static struct grant_map *gntdev_alloc_map(struct
gntdev_priv *priv, int count)
NULL == add-pages)
goto err;
- if (alloc_xenballooned_pages(count, add-pages, false /* lowmem */))
+ if (gnttab_alloc_pages(count, add-pages))
goto err;
for (i = 0; i count; i++) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 999d7ab..b4f93c4 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -50,6 +50,7 @@
#include xen/interface/memory.h
#include xen/hvc-console.h
#include xen/swiotlb-xen.h
+#include xen/balloon.h
#include asm/xen/hypercall.h
#include asm/xen/interface.h
@@ -671,6 +672,34 @@ void gnttab_free_auto_xlat_frames(void)
}
EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
+/**
+ * gnttab_alloc_pages - alloc pages suitable for grant mapping into
+ * @nr_pages: number of pages to alloc
+ * @pages: returns the pages
+ */
+int
[Xen-devel] [PATCHv4 00/14] xen: fix many long-standing grant mapping bugs
This series fixes a number of long-standing bugs in the handling of grant maps. Refer to the following for all the details. http://xenbits.xen.org/people/dvrabel/grant-improvements-C.pdf In summary, the important uses that this enables are: 1. Block backends can use networked storage safely. 2. Block backends can use network storage provided by other guests on the same host. 3. User space block backends can use direct I/O or asynchronous I/O. The first two patches are the core MM changes necessary. These have already been acked. Patches #3 and #4 remove existing (broken) mechanisms. This does temporarily break some previously working use cases, but it does make the subsequent additions much easier to review. As a happy side effect, performance is also likely to be improved in some areas (but I've not got any measurements yet). User space backends using grant mapping should see some good improvements from reduced overheads and better unmap batching. VIF to VIF network traffic may also see a small improvement. Finally, thanks to Jenny who did much of the implementation. Changes in v4: - Removed xen_blkbk_unmap_done(). - Fixed bug in blkback when using mixed persistent and non-persistent grants. Changes in v3: - find_page renamed to find_special_page. - Added documentation for mm changes. - Fixed mangled forward port of blkback's safe unmap patch. - Export gnttab_alloc_pages() and gnttab_free_pages(). - Fix 32-bit build. Changes in v2: - Add find_page() VMA op instead of pages field (so struct vm_area_struct doesn't increase in size. - Make foreign page tracking arch-independant and improve the API. - Alloc extra memory (for 32-bit archs) for the (domain, gref) when allocating the page (instead of during the map). - Convert gntdev's lock to a mutex. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 09/14] xen/grant-table: add a mechanism to safely unmap pages that are in use
From: Jennifer Herbert jennifer.herb...@citrix.com
Introduce gnttab_unmap_refs_async() that can be used to safely unmap
pages that may be in use (ref count 1). If the pages are in use the
unmap is deferred and retried later. This polling is not very clever
but it should be good enough if the cases where the delay is necessary
are rare.
The initial delay is 5 ms and is increased linearly on each subsequent
retry (to reduce load if the page is in use for a long time).
This is needed to allow block backends using grant mapping to safely
use network storage (block or filesystem based such as iSCSI or NFS).
The network storage driver may complete a block request whilst there
is a queued network packet retry (because the ack from the remote end
races with deciding to queue the retry). The pages for the retried
packet would be grant unmapped and the network driver (or hardware)
would access the unmapped page.
Signed-off-by: Jennifer Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/xen/grant-table.c | 44
include/xen/grant_table.h | 18 ++
2 files changed, 62 insertions(+)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 89dcca4..17972fb 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -42,6 +42,7 @@
#include linux/io.h
#include linux/delay.h
#include linux/hardirq.h
+#include linux/workqueue.h
#include xen/xen.h
#include xen/interface/xen.h
@@ -819,6 +820,49 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref
*unmap_ops,
}
EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
+#define GNTTAB_UNMAP_REFS_DELAY 5
+
+static void __gnttab_unmap_refs_async(struct gntab_unmap_queue_data* item);
+
+static void gnttab_unmap_work(struct work_struct *work)
+{
+ struct gntab_unmap_queue_data
+ *unmap_data = container_of(work,
+ struct gntab_unmap_queue_data,
+ gnttab_work.work);
+ if (unmap_data-age != UINT_MAX)
+ unmap_data-age++;
+ __gnttab_unmap_refs_async(unmap_data);
+}
+
+static void __gnttab_unmap_refs_async(struct gntab_unmap_queue_data* item)
+{
+ int ret;
+ int pc;
+
+ for (pc = 0; pc item-count; pc++) {
+ if (page_count(item-pages[pc]) 1) {
+ unsigned long delay = GNTTAB_UNMAP_REFS_DELAY *
(item-age + 1);
+ schedule_delayed_work(item-gnttab_work,
+ msecs_to_jiffies(delay));
+ return;
+ }
+ }
+
+ ret = gnttab_unmap_refs(item-unmap_ops, item-kunmap_ops,
+ item-pages, item-count);
+ item-done(ret, item);
+}
+
+void gnttab_unmap_refs_async(struct gntab_unmap_queue_data* item)
+{
+ INIT_DELAYED_WORK(item-gnttab_work, gnttab_unmap_work);
+ item-age = 0;
+
+ __gnttab_unmap_refs_async(item);
+}
+EXPORT_SYMBOL_GPL(gnttab_unmap_refs_async);
+
static int gnttab_map_frames_v1(xen_pfn_t *frames, unsigned int nr_gframes)
{
int rc;
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index d3bef56..143ca5f 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -60,6 +60,22 @@ struct gnttab_free_callback {
u16 count;
};
+struct gntab_unmap_queue_data;
+
+typedef void (*gnttab_unmap_refs_done)(int result, struct
gntab_unmap_queue_data *data);
+
+struct gntab_unmap_queue_data
+{
+ struct delayed_work gnttab_work;
+ void *data;
+ gnttab_unmap_refs_done done;
+ struct gnttab_unmap_grant_ref *unmap_ops;
+ struct gnttab_unmap_grant_ref *kunmap_ops;
+ struct page **pages;
+ unsigned int count;
+ unsigned int age;
+};
+
int gnttab_init(void);
int gnttab_suspend(void);
int gnttab_resume(void);
@@ -174,6 +190,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count);
+void gnttab_unmap_refs_async(struct gntab_unmap_queue_data* item);
+
/* Perform a batch of grant map/copy operations. Retry every batch slot
* for which the hypervisor returns GNTST_eagain. This is typically due
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions
On Mon, Jan 26, 2015 at 05:06:12PM +, Jan Beulich wrote: On 26.01.15 at 17:57, elena.ufimts...@oracle.com wrote: On Fri, Jan 23, 2015 at 10:50:23AM +, Jan Beulich wrote: On 22.01.15 at 18:34, elena.ufimts...@oracle.com wrote: (XEN) d56f - d5fff000 (reserved) So this is where one of the RMRRs sits in (and also where the faults occur according to the two numbers you sent earlier, which - as others have already said - is an indication of the reported RMRRs being incomplete), ... (XEN) d5fff000 - d600 (usable) (XEN) d700 - df20 (reserved) ... and this is the exact range of the other one. But the usable entry between them is a sign of the firmware not doing the best job in assigning resources. I don't, btw, think that blindly mapping all the reserved regions into PVH Dom0's P2M would be (or is, if that's what's happening today) correct - these regions are named reserved for a reason. In the case here it's actually RAM, not MMIO, and Dom0 (as well as Xen) has no business accessing these (for others this may be different, e.g. the LAPIC and IO-APIC ones below, but Xen learns/knows of them by means different from looking at the memory map). I understand this this. At the same time I think pv dom0 does exactly this blind mapping. I also tried to map these regions as read-only and that worked. Can be this an option for these ram regions? No - they're reserved, so there shouldn't be _any_ access to them. The only possible workaround I see as acceptable would be the already proposed addition of a command line option allowing to specify additional RMRR-like regions. Understood. And I am guessing the permissions overloading option should be available as well? For example, RW or R only. RMRRs are always mapped with RW. Why can be this a platform quirk? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 0/5] Split off mini-os to a separate tree
On 26 Jan 2015, at 17:42, Martin Lucina mar...@lucina.net wrote: tal...@gmail.com said: In case it's useful: for the standalone version of Mini-OS used by Mirage, I had to include these directories too: 1. xen/include/public 2. xen/common/libfdt 3. xen/include/xen/libfdt 4. config ( https://github.com/talex5/xen/tree/minios-releases ) Ah, so that's where the Mirage fork of Mini-OS lives. I knew there was one, but not where. Any other forks please speak up :-) Which parts of Mini-OS does Mirage actually use? I know you have an OCaml implementation of netfront, for instance. Not very much of Mini-OS -- Mirage has everything from the ring protocol up (XenStore, NetBack/Front, BlkBack/Front, Console, etc are all in OCaml). So event channels and start of day boot, mainly. It is useful to have the C XenBus around for start-of-day logging though, since the emergency console isn't much use on public cloud services. -anil ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
