>>> On 22.09.15 at 16:02, wrote:
> --- xen/include/public/arch-x86/pmu.h
> +++ xen/include/public/arch-x86/pmu.h
I fixed this up for you this time, but in the future please make sure
you send patches in conventional format (applicable with patch's -p1
or whatever tool's equivalent).
Thanks, Jan
>>> On 25.09.15 at 04:29, wrote:
> Bit 0:29 in Fault Event Control Register are 'Reserved and Preserved',
> software cannot write 0 to it unconditionally. Software must preserve
> the value read for writes.
>
> Signed-off-by: Quan Xu
> Acked-by: Yang Zhang
I think this should also be applied t
Bit 0:29 in Fault Event Control Register are 'Reserved and Preserved',
software cannot write 0 to it unconditionally. Software must preserve
the value read for writes.
Signed-off-by: Quan Xu
Reported-by: Jan Beulich
---
xen/drivers/passthrough/vtd/iommu.c | 5 -
1 file changed, 4 insertions
On Fri, 2015-09-25 at 06:44 +0200, Juergen Gross wrote:
> On 09/24/2015 05:43 PM, Dario Faggioli wrote:
> > It seems this have had to be done as part of 7e6b926a
> > ("cpupools: Make interface more consistent"), which
> > renamed the function but not the counter.
> >
> > In fact, because of cpupoo
especially if that is also from a different cpupool than the
processor of the vCPU that triggered the tickling.
In fact, it is possible that we get as far as calling vcpu_unblock()-->
vcpu_wake()-->csched_vcpu_wake()-->__runq_tickle() for the vCPU 'vc',
but all while running on a pCPU that is diff
flight 62299 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62299/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 60684
build-i386
On 09/24/2015 05:24 PM, Dario Faggioli wrote:
[Unrelated to anything technical, dropping some Cc-s]
On Thu, 2015-09-24 at 16:26 +0100, Ross Lagerwall wrote:
On 09/24/2015 03:53 PM, Marek Marczykowski-Górecki wrote:
(XEN) Xen call trace:
(XEN)[] ca9e6f98
(XEN)
Hey Wei,
On Fri, 2015-09-25 at 09:46 +0200, Dario Faggioli wrote:
> For instance, this can happen when an HVM domain runs in a cpupool,
> with a different scheduler than the default one, and issues IOREQs
> to Dom0, running in Pool-0 with the default scheduler.
> In fact, right in this case, the
We were going to take this for 4.6 too but with the moratorium ongoing we
should wait until Monday. I'll try and remember.
On Fri, 2015-09-25 at 07:11 +, patch...@xen.org wrote:
> commit 8d6ff9ef259e296e6aee32ad8840cc5081280e0d
> Author: Mike Belopuhov
> AuthorDate: Fri Sep 25 09:04:24 20
On Thu, 2015-09-24 at 23:19 +0100, Stefano Stabellini wrote:
> On Thu, 24 Sep 2015, Ian Campbell wrote:
> > On Thu, 2015-09-24 at 20:33 +0100, Stefano Stabellini wrote:
> > > On Thu, 24 Sep 2015, Ian Campbell wrote:
> > > > On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:
> > > > > On W
On Thu, 2015-09-24 at 19:28 +0200, Andreas Sundstrom wrote:
> On 2015-09-23 16:18, Ian Campbell wrote:
> > On Wed, 2015-09-23 at 12:47 +, Andreas Sundstrom wrote:
> > > Citerar Ian Campbell :
> > >
> > > > Along those lines, if the _host_ has buckets of RAM then might it
> > > > be
> > > > wor
On Thu, 2015-09-24 at 18:29 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
(Happily too because it always knackers tab completion for my local test
-foo.sh scripts ;-))
___
Xen-devel mailing list
Xen-devel@lists.xen.or
On Thu, 2015-09-24 at 18:29 +0100, Ian Jackson wrote:
> In POSIX, `.' (the shell builtin) respects PATH, and does not search
> `.' (the current directory).
>
> Change all the invocations which refer to files which are part of
> osstest to say `. ./foo' instead of simply `. foo'.
>
> I have checke
On Thu, Sep 24, 2015 at 12:07:27PM +0100, Ian Campbell wrote:
> On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
> > @@ -8410,20 +8415,29 @@ static void psr_cat_print_one_domain_cbm(uint32_t
> > domid, uint32_t socketid)
> > printf("%5d%25s", domid, domain_name);
> > free(domain_name);
>
On Thu, 2015-09-24 at 18:29 +0100, Ian Jackson wrote:
> I have read through the wheezy
> bash(1) manpage and searched for posix, and the following behavioural
> differences are described:
>
> * Differences in interative startup (not relevant to us).
> * Minor (irrelevant) differences in which
El 24/09/15 a les 9.57, Jan Beulich ha escrit:
On 23.09.15 at 17:45, wrote:
>> El 16/09/15 a les 12.05, Jan Beulich ha escrit:
>> On 04.09.15 at 14:08, wrote:
>>> Also - aren't all the changes to this file (and perhaps othersfurther
>>> down) bug fixes in their own right?
>>
>> Whether t
On Thu, Sep 24, 2015 at 12:22:47PM +0100, Ian Campbell wrote:
> On Thu, 2015-09-24 at 12:07 +0100, Ian Campbell wrote:
> > @@ -8517,8 +8535,19 @@ int main_psr_cat_cbm_set(int argc, char **argv)
> > > libxl_string_list_dispose(&socket_list);
> > > free(value);
> > > break;
On Fri, 2015-09-25 at 17:04 +0800, He Chen wrote:
> On Thu, Sep 24, 2015 at 12:22:47PM +0100, Ian Campbell wrote:
> > On Thu, 2015-09-24 at 12:07 +0100, Ian Campbell wrote:
> > > @@ -8517,8 +8535,19 @@ int main_psr_cat_cbm_set(int argc, char
> > > **argv)
> > > > libxl_string_list_dispose(
On Fri, 2015-09-25 at 16:43 +0800, He Chen wrote:
> On Thu, Sep 24, 2015 at 12:07:27PM +0100, Ian Campbell wrote:
> > On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
> > > @@ -8410,20 +8415,29 @@ static void
> > > psr_cat_print_one_domain_cbm(uint32_t
> > > domid, uint32_t socketid)
> > > pr
On Thu, Sep 24, 2015 at 12:22:02PM +0100, Ian Campbell wrote:
> On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
> > Add new CDP options with CAT commands in xl interface man page.
> > Add description of CDP in xl-psr.markdown.
>
> It would have been fine to include this in the previous patch by
> Quoting the relevant bits of code for clarity:
> libxl_psr_cbm_type type = LIBXL_PSR_CBM_TYPE_L3_CBM;
> ...
> case 'd':
> type = LIBXL_PSR_CBM_TYPE_L3_DATA;
> opt_data = 1;
> break;
> case 'c':
> type = LIBXL_PSR_CBM_TYPE_L3_CODE;
> opt_cod
More specifically:
1) rename vcpu_destroy to vcpu_remove
It seems this have had to be done as part of 7e6b926a
("cpupools: Make interface more consistent"), which
renamed the function but not the counter.
In fact, because of cpupools, vcpus are not only removed
from a scheduler when they are des
On 24/09/15 09:11, Jan Beulich wrote:
On 23.09.15 at 20:34, wrote:
On 22/09/15 14:10, Jan Beulich wrote:
+for ( offs = 2; offs < 8; offs <<= 1 )
+{
+bool_t read = 1;
+
+for ( i = RTC_REG_D + 1; i < 0x80; ++i )
+{
+uint8_t normal, alt;
+un
flight 38030 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38030/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail
never pass
test-armhf-ar
On Fri, 2015-09-25 at 17:29 +0800, He Chen wrote:
> On Thu, Sep 24, 2015 at 12:22:02PM +0100, Ian Campbell wrote:
> > On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
> > > Add new CDP options with CAT commands in xl interface man page.
> > > Add description of CDP in xl-psr.markdown.
> >
> > It
Currently there is a number of issues preventing PVHVM Xen guests from
doing successful kexec/kdump:
- Bound event channels.
- Registered vcpu_info.
- PIRQ/emuirq mappings.
- shared_info frame after XENMAPSPACE_shared_info operation.
- Active grant mappings.
Basically, newly booted kernel stumbles
On Fri, Sep 25, 2015 at 10:58:58AM +0100, Ian Campbell wrote:
> On Fri, 2015-09-25 at 17:29 +0800, He Chen wrote:
> > On Thu, Sep 24, 2015 at 12:22:02PM +0100, Ian Campbell wrote:
> > > On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
> > > > Add new CDP options with CAT commands in xl interface m
On 09/25/2015 11:53 AM, Dario Faggioli wrote:
More specifically:
1) rename vcpu_destroy to vcpu_remove
It seems this have had to be done as part of 7e6b926a
("cpupools: Make interface more consistent"), which
renamed the function but not the counter.
In fact, because of cpupools, vcpus are not
If an osstest instance is running flights with
OSSTEST_BASELINES_ONLY=y (e.g. on a secondary site, like the Citrix
Cambridge instance) then it will also be running a regular osstest
flight to merge from the upstream osstest and does not want to also do
baseline testing.
I expect this will be the n
Robert has passed me a v13 of this series (via an emailed `git
bundle'!) which I am now working on. I'm currently polishing an
initial subset for a push to osstest pretest today. In that context:
Ian Campbell writes ("Re: [OSSTest Nested v12 01/21] Optimize and re-format
previous code of 'subme
On Fri, 2015-09-25 at 17:53 +0800, He Chen wrote:
> > Quoting the relevant bits of code for clarity:
> > libxl_psr_cbm_type type = LIBXL_PSR_CBM_TYPE_L3_CBM;
> > ...
> > case 'd':
> > type = LIBXL_PSR_CBM_TYPE_L3_DATA;
> > opt_data = 1;
> > break;
> > case '
Ian Jackson writes ("Re: [OSSTest Nested v12 03/21] Allow runvars to specify
guest disk and ram size (turning previous values into defaults)"):
> Robert Ho writes ("[OSSTest Nested v12 03/21] Allow runvars to specify guest
> disk and ram size (turning previous values into defaults)"):
>
On Fri, 2015-09-25 at 18:16 +0800, He Chen wrote:
>
[...]
> > And if cdp is not enabled:
> >
[...]
> Right above.
>
> > xl psr-cat-cbm-set -c -d 0xd00dfeed
> >
> > *ERRROR*
> > [now: cbm=]
> >
>
> In current code, it is valid since -c & -d have the same behaviour as
> neither of them.
> So,
flight 62288 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62288/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate.2 fail REGR. vs.
62168
Regressions wh
On Tue, 2015-09-22 at 17:17 +0100, Lars Kurth wrote:
> Hi everyone,
>
> most of http://wiki.xenproject.org/wiki/Outreach_Program_Projects has
> been scrubbed and out-of-date projects removed.
>
> However, now we do have very few Hypervisor projects and NO XAPI
> projects.
>
There has been som
Ian Jackson writes ("Re: [OSSTest Nested v12 05/21] Honour $xopts{ExtraConfig}
and use it to enable nestedhvm"):
> Having thought about this, I think it would be better if the guest var
> were called `nestedhvm_enable'. Sorry to ask for this change now, but
> could you change that please (and the
On Fri, Sep 25, 2015 at 01:16:38AM -0600, Jan Beulich wrote:
> >>> On 25.09.15 at 04:29, wrote:
> > Bit 0:29 in Fault Event Control Register are 'Reserved and Preserved',
> > software cannot write 0 to it unconditionally. Software must preserve
> > the value read for writes.
> >
> > Signed-off-by
>>> On 25.09.15 at 11:55, wrote:
> It is safe for the SMM handler to use CMOS if it returns the index
> register back to how it found it. Furthermore, I am willing to bet that
> there real SMM handlers out there which do do this.
So what options do you see then here? Don't do anything (drop th
On Fri, Sep 25, 2015 at 10:10:45AM +0200, Dario Faggioli wrote:
> Hey Wei,
>
> On Fri, 2015-09-25 at 09:46 +0200, Dario Faggioli wrote:
>
> > For instance, this can happen when an HVM domain runs in a cpupool,
> > with a different scheduler than the default one, and issues IOREQs
> > to Dom0, run
>>> On 25.09.15 at 10:17, wrote:
> We were going to take this for 4.6 too but with the moratorium ongoing we
> should wait until Monday. I'll try and remember.
I have it on my todo list for whenever the moratorium is over.
Jan
___
Xen-devel mailing l
All,
with 4.5.2 being due in about 4 weeks please indicate to the respective
maintainers backports you see missing from but consider relevant for
the 4.5 stable branch. Please note that according to the outcome of a
recent discussion we're intending to do this release without any RC.
Thanks, Jan
Ian Campbell writes ("[PATCH OSSTEST] Do not run baseline tests on osstest
branch."):
> If an osstest instance is running flights with
> OSSTEST_BASELINES_ONLY=y (e.g. on a secondary site, like the Citrix
> Cambridge instance) then it will also be running a regular osstest
> flight to merge from t
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 62352 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62352/
Failures :-/
From: Robert Ho
We are going to want to do this for nested HVM L1s too.
No functional change.
Signed-off-by: Robert Ho
Signed-off-by: Ian Jackson
---
v14: Squashed two patches into this one.
---
Osstest/TestSupport.pm |6 ++
ts-host-install|2 +-
2 files changed, 7 insert
We are going to want to do this for nested HVM L1s too.
No functional change.
Signed-off-by: Ian Jackson
---
v14: Split this nfc patch out from other changes
Drop changes to whitespace usage
Rename new function from `core_dump_setup'
Drop introduction of an unnecessary mkdir -p
--
Signed-off-by: Ian Jackson
Tested-by: Robert Ho
---
tcl/osstestlib.tcl |7 +++
1 file changed, 7 insertions(+)
diff --git a/tcl/osstestlib.tcl b/tcl/osstestlib.tcl
index 61a6a09..b5a52d3 100644
--- a/tcl/osstestlib.tcl
+++ b/tcl/osstestlib.tcl
@@ -75,6 +75,13 @@ proc lshift {listvar} {
From: Robert Ho
Allow runvars to specify guest disk and ram size, turning previous
values into defaults:
The default disk size for the guest is `1M' which is not going to
be sufficient for nested HVM tests. We are going to want to use a
larger disk size for the nested L1. The appropriate d
From: Robert Ho
In b77a6a2522d8 "Changes to support '/boot' leading paths of kernel,
xen, in grub", this pattern was erroneously changed.
Revert that aspect of that commit, so that we once again require Xen
image versions to start with a digit.
Signed-off-by: Robert Ho
Signed-off-by: Ian Jacks
Move this into host_install_postboot_complete. All hosts subject to
host_install_postboot_complete should have the coredump settings too.
No functional change.
Signed-off-by: Ian Jackson
---
v14: New patch.
Dropped patch which adds core_dump_setup call to ts-nested-setup
---
Osstest/TestS
From: Robert Ho
* space between ')' and '{'; and after '='
* omit unnecessary 'define' and '!defined' usage
* break long '{}' into several lines
Signed-off-by: Robert Ho
Signed-off-by: Ian Jackson
---
v14: Drop removal of MenuEntryPath setting in grub2 submenu parse
---
Osstest/Debian.pm |
This is the first part of Robert Hu's osstest patch series to support
nested HVM tests. (v13 was passed to me as a git branch `under the
table' by Robert.) I have rewritten the commit messages, refactored a
few patches, and reordered the series slightly.
I have made only very minimal code change
From: Robert Ho
Comment out the CDROM entry in the installed system's sources.list.
The installation ISO is not generally present in the virtual CDROM
while the guest is running, so this entry is nonfunctional.
Removing it causes the L1 HVM guest VM to use the http entry instead.
The result is t
From: Robert Ho
There are not yet any jobs which set this.
Signed-off-by: Robert Ho
Signed-off-by: Ian Jackson
---
v14: Use guest_var_boolean
---
ts-debian-hvm-install |5 +
1 file changed, 5 insertions(+)
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index f2fc31b..2c75
osstest service owner writes ("[xen-unstable-smoke baseline test] 62352:
tolerable FAIL"):
> "Old" tested version had not actually been tested; therefore in this
> flight we test it, rather than a new candidate. The baseline, if
> any, is the most recent actually tested revision.
>
> flight 6235
Per-VCPU pause flags in sched.h are defined as bit positions and as
values derived from the bit defines. There is only one user of a value
which can be easily converted to use a bit number as well.
Remove the value definitions and do the conversion for the only user.
Signed-off-by: Juergen Gross
Doing some clean-ups all somehow related to xen/include/xen/sched.h.
Juergen Gross (5):
libelf: use enum instead of hard coded values in elf_dom_parms.pae
xen: make use of new pae enum in hypervisor
libxc: make use of new pae enum in libxc
xen: remove unused macros from sched.h
xen: cle
The macros num_cpupool_cpus() and domain_is_locked() aren't used by
anyone. Remove them.
Signed-off-by: Juergen Gross
---
xen/include/xen/sched.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 20d3865..b5190b5 100644
--- a/xen/includ
Instead of using own defines for the possible values of pae_kernel
make use of the new libelf enum.
Signed-off-by: Juergen Gross
---
xen/arch/x86/domain_build.c | 6 +++---
xen/include/xen/sched.h | 4
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/domain_bu
Instead of using hard coded values for the possible values of parms.pae
make use of the new libelf enum.
Signed-off-by: Juergen Gross
---
tools/libxc/xc_dom_binloader.c | 2 +-
tools/libxc/xc_dom_elfloader.c | 8
tools/libxc/xc_dom_x86.c | 6 +++---
tools/libxc/xg_private.h
Use an enum for elf_dom_parms.pae instead of just hard coding the
values when setting the information.
Signed-off-by: Juergen Gross
---
xen/common/libelf/libelf-dominfo.c | 8
xen/include/xen/libelf.h | 9 -
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git
On Fri, 2015-09-25 at 13:54 +0200, Juergen Gross wrote:
> Instead of using hard coded values for the possible values of parms.pae
> make use of the new libelf enum.
>
> Signed-off-by: Juergen Gross
Acked-by: Ian Campbell
I'll assume this will be picked up by Jan along with the x86 hypervisor
s
On 25/09/15 12:54, Juergen Gross wrote:
Doing some clean-ups all somehow related to xen/include/xen/sched.h.
Juergen Gross (5):
libelf: use enum instead of hard coded values in elf_dom_parms.pae
xen: make use of new pae enum in hypervisor
libxc: make use of new pae enum in libxc
xen
On Fri, 2015-06-19 at 13:41 +0100, Julien Grall wrote:
> When the property "clock-frequency" is present in the DT timer node, it
> means that the bootloader/firmware didn't correctly configure the
> CNTFRQ/CNTFRQ_EL0 on each processor.
>
> The best solution would be to fix the offending firmware/b
Ian,
On Fri, 2015-09-25 at 05:16 -0600, Jan Beulich wrote:
> All,
>
> with 4.5.2 being due in about 4 weeks please indicate to the respective
> maintainers backports you see missing from but consider relevant for
> the 4.5 stable branch. Please note that according to the outcome of a
> recent dis
On Mon, 2015-09-21 at 12:54 +0100, Ian Campbell wrote:
> On Fri, 2015-09-18 at 11:30 +0100, Wei Liu wrote:
>
> > > > H I forgot my Signed-off-by :(.
> > > >
> > > > Signed-off-by: Julien Grall
> > >
> > > Acked-by: Ian Campbell
> > >
> > > This is a no brainer for 4.6 (and further) IMHO a
On 25/09/15 13:17, Ian Campbell wrote:
> Ian,
>
> On Fri, 2015-09-25 at 05:16 -0600, Jan Beulich wrote:
>> All,
>>
>> with 4.5.2 being due in about 4 weeks please indicate to the respective
>> maintainers backports you see missing from but consider relevant for
>> the 4.5 stable branch. Please not
Ian,
On Fri, 2015-09-25 at 05:16 -0600, Jan Beulich wrote:
> All,
>
> with 4.5.2 being due in about 4 weeks please indicate to the respective
> maintainers backports you see missing from but consider relevant for
> the 4.5 stable branch. Please note that according to the outcome of a
> recent dis
On Tue, Sep 08, 2015 at 02:03:59PM +0100, Ian Campbell wrote:
> On Thu, 2015-08-06 at 18:03 +0100, Anthony PERARD wrote:
> > This script also install packages needed and clone every OpenStack trees to
> > be use by devstack to deploy OpenStack.
>
> How about:
>
> This script installs any necessar
On Tue, Sep 08, 2015 at 03:36:17PM +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v2 4/6] ts-openstack-devstack:
> Deploy OpenStack on a host"):
> > On Thu, 2015-08-06 at 18:03 +0100, Anthony PERARD wrote:
> > > This script also install packages needed and clone every OpenSta
On Fri, 2015-09-25 at 13:35 +0100, Anthony PERARD wrote:
> > > [...]
> > > + my $openstack_git_base = git_massage_url('git://git.openstack.org');
> > > [...]
> > > +GIT_BASE="$openstack_git_base"
> >
> > Does this suggest that it might try and clone anything which it can't find
> > (i.e. which w
On Tue, Sep 08, 2015 at 02:06:11PM +0100, Ian Campbell wrote:
> On Thu, 2015-08-06 at 18:03 +0100, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD
> > ---
> > sg-run-job | 1 +
> > ts-openstack-tempest | 35 +++
> > 2 files changed, 36 insertions
On GICv2, the GIC virtual CPU interface is at minimum 8KB. Due some to
some necessary quirk for GIC using 64KB stride, we are mapping the
region in 2 time.
The first mapping is 4KB and the second one is 8KB, i.e 12KB in total.
Although the minimum supported size (and widely used) is 8KB. This means
On Tue, Sep 08, 2015 at 02:14:27PM +0100, Ian Campbell wrote:
> On Thu, 2015-08-06 at 18:03 +0100, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD
> > ---
> > ap-common| 9 +
> > ap-fetch-version | 4
> > ap-fetch-version-old | 5 +
> > ap-print-url
On Fri, 2015-09-25 at 14:04 +0100, Anthony PERARD wrote:
> > > +
> > > +sub tempest() {
> > > + # The regex is the default one + avoid the two tests know to not work
> > > + # which are two variations of test_volume_boot_pattern.
> > > + target_cmd($ho, <
> > > +$builddir/tempest/run_tempest
Citerar Ian Campbell :
On Thu, 2015-09-24 at 19:28 +0200, Andreas Sundstrom wrote:
On 2015-09-23 16:18, Ian Campbell wrote:
> On Wed, 2015-09-23 at 12:47 +, Andreas Sundstrom wrote:
> > Citerar Ian Campbell :
> >
> > > Along those lines, if the _host_ has buckets of RAM then might it
> > >
On Fri, 2015-09-25 at 14:10 +0100, Julien Grall wrote:
FYI your Subject resulted in git am making a commit titled:
] xen/arm: vgic-v2: Map the GIC virtual CPU interface with the correct size
You probably just forgot that --subject-prefix has the []'s added
automatically, but if it was deliberate
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Friday, September 25, 2015 6:55 PM
> To: Jan Beulich
> Cc: Wei Liu; Xu, Quan; Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH resend] vt-d: Fix IM bit mask and unmask of
> Fault
Ian Campbell writes ("Re: [PATCH OSSTEST v2 5/6] ts-openstack-tempest: Run
Tempest to check OpenStack"):
> On Fri, 2015-09-25 at 14:04 +0100, Anthony PERARD wrote:
> > I think the genereted $builddir end up been the same as in the previous
> > script, because it's generated based on the flight nam
On Fri, Sep 25, 2015 at 11:59:52AM +0200, Vitaly Kuznetsov wrote:
> Currently there is a number of issues preventing PVHVM Xen guests from
> doing successful kexec/kdump:
> - Bound event channels.
> - Registered vcpu_info.
> - PIRQ/emuirq mappings.
> - shared_info frame after XENMAPSPACE_shared_inf
On Fri, Sep 25, 2015 at 05:16:24AM -0600, Jan Beulich wrote:
> All,
>
> with 4.5.2 being due in about 4 weeks please indicate to the respective
> maintainers backports you see missing from but consider relevant for
> the 4.5 stable branch. Please note that according to the outcome of a
> recent di
>>> On 09.09.15 at 10:56, wrote:
On 08.09.15 at 15:21, wrote:
>> I got Xen booting now with VT-d enabled, lot's of errors and the system is
>> unstable. xl dmesg output:
>
> Lots of errors? I don't see much - can you point out the errors you see?
> There are two interesting things:
>
>> (X
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/include/asm-arm/domain.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c3f5a95..1a5bfd7 100644
--- a/xen/include/asm-arm/domain.
From: Julien Grall
Rather than letting each handler to retrieve the register used by the
I/O access, add a new parameter to pass the register in parameter.
This will help to implement generic register manipulation on I/O access
such as sign-extension and endianess.
Read handlers need to modify
Xen is currently directly storing the value of register GICD_IPRIORITYR
in the rank. This makes emulation of the register access very simple
but makes the code to get the priority for a given IRQ more complex.
While the priority of an IRQ is retrieved everytime an IRQ is injected
to the guest, the
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/include/asm-arm/domain.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c3f5a95..1a5bfd7 100644
--- a/xen/include/asm-arm/domain.
Xen is currently directly storing the value of register GICD_ITARGETSR
(for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
emulation of the registers access very simple but makes the code to get
the target vCPU for a given IRQ more complex.
While the target vCPU of an IRQ is retri
Hi all,
This series aims to fix the 32-bit access on 64-bit register. Some guest
OS such as FreeBSD and Linux (only in the ITS) use 32-bit access and will
crash at boot time.
I took the opportunity to go further and optimize the way Xen is storing
registers such as GICD_IPRIORITYR, GICD_ITARGETR
Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.
All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.
For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulating 32-bit access for t
and use them in the vGIC emulation.
The GIC registers may support different access sizes. Rather than open
coding the access for every registers, provide a set of helpers to access
them.
The caller will have to call vgic_regN_* where N is the size of the
emulated registers.
The new helpers suppo
and use them in the vGIC emulation.
The GIC registers may support different access sizes. Rather than open
coding the access for every registers, provide a set of helpers to access
them.
The caller will have to call vgic_regN_* where N is the size of the
emulated registers.
The new helpers suppo
Xen is currently directly storing the value of register GICD_IPRIORITYR
in the rank. This makes emulation of the register access very simple
but makes the code to get the priority for a given IRQ more complex.
While the priority of an IRQ is retrieved everytime an IRQ is injected
to the guest, the
From: Julien Grall
Rather than letting each handler to retrieve the register used by the
I/O access, add a new parameter to pass the register in parameter.
This will help to implement generic register manipulation on I/O access
such as sign-extension and endianess.
Read handlers need to modify
From: Julien Grall
This typedef is a left-over of the previous MMIO emulation
implementation.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/include/asm-arm/mmio.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/include/asm-arm/mmio.h b/xen/include/asm-
From: Julien Grall
This typedef is a left-over of the previous MMIO emulation
implementation.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/include/asm-arm/mmio.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/include/asm-arm/mmio.h b/xen/include/asm-
Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.
All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.
For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulating 32-bit access for t
The guest may try to load data from the emulated MMIO region using
instruction with Sign-Extension (i.e ldrs*). This can happen for any
access smaller than the register size (byte/half-word for aarch32,
byte/half-word/word for aarch64).
The support of sign-extension was limited for byte access in
The guest may try to load data from the emulated MMIO region using
instruction with Sign-Extension (i.e ldrs*). This can happen for any
access smaller than the register size (byte/half-word for aarch32,
byte/half-word/word for aarch64).
The support of sign-extension was limited for byte access in
Hi all,
This series aims to fix the 32-bit access on 64-bit register. Some guest
OS such as FreeBSD and Linux (only in the ITS) use 32-bit access and will
crash at boot time.
I took the opportunity to go further and optimize the way Xen is storing
registers such as GICD_IPRIORITYR, GICD_ITARGETR
Please ignore this version, I've sent it to the wrong mailing list.
Sorry for the noise.
On 25/09/15 15:50, Julien Grall wrote:
> Hi all,
>
> This series aims to fix the 32-bit access on 64-bit register. Some guest
> OS such as FreeBSD and Linux (only in the ITS) use 32-bit access and will
> cra
Xen is currently directly storing the value of register GICD_ITARGETSR
(for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
emulation of the registers access very simple but makes the code to get
the target vCPU for a given IRQ more complex.
While the target vCPU of an IRQ is retri
1 - 100 of 183 matches
Mail list logo
