On 26.03.2020 14:56, Andrew Cooper wrote:
> On 26/03/2020 13:44, Pu Wen wrote:
>> According to chapter "Appendix B Layout of VMCB" in the new version
>> (v3.32) AMD64 APM[1], bit 1 of the VMCB offset 68h is defined as
>> GUEST_INTERRUPT_MASK.
>>
>> In current xen codes, it use whole u64 interrupt_s
On 27.03.20 00:24, Igor Druzhinin wrote:
On 26/03/2020 09:19, Juergen Gross wrote:
Some keyhandlers are calling process_pending_softirqs() while holding
a rcu_read_lock(). This is wrong, as process_pending_softirqs() might
activate rcu calls which should not happen inside a rcu_read_lock().
For
On 27.03.2020 09:10, Jürgen Groß wrote:
> On 27.03.20 00:24, Igor Druzhinin wrote:
>> On 26/03/2020 09:19, Juergen Gross wrote:
>>> Some keyhandlers are calling process_pending_softirqs() while holding
>>> a rcu_read_lock(). This is wrong, as process_pending_softirqs() might
>>> activate rcu calls
On 27.03.20 09:35, Jan Beulich wrote:
On 27.03.2020 09:10, Jürgen Groß wrote:
On 27.03.20 00:24, Igor Druzhinin wrote:
On 26/03/2020 09:19, Juergen Gross wrote:
Some keyhandlers are calling process_pending_softirqs() while holding
a rcu_read_lock(). This is wrong, as process_pending_softirqs()
> -Original Message-
> From: Roman Shaposhnik
> Sent: 26 March 2020 22:03
> To: Roger Pau Monné
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ; Paul
> Durrant ;
> Kevin Tian ; Andrew Cooper
> Subject: Re: [Xen-devel] PCIe IOMMU ACS support
>
> On Wed, Mar 25, 2020 at 4:05 AM Roger
On Fri, Mar 27, 2020 at 02:21:46AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne
> > Sent: Thursday, March 26, 2020 11:27 PM
> >
> > Updating SVI is required when an interrupt has been injected using the
> > Ack on exit VMEXIT feature, so that the in service interrupt in the
> > GUEST_INTR_
On 27/03/2020 08:35, Jan Beulich wrote:
> On 27.03.2020 09:10, Jürgen Groß wrote:
>> On 27.03.20 00:24, Igor Druzhinin wrote:
>>> On 26/03/2020 09:19, Juergen Gross wrote:
Some keyhandlers are calling process_pending_softirqs() while holding
a rcu_read_lock(). This is wrong, as process_pe
With commit cef21210fb133 ("rcu: don't process callbacks when holding
a rcu_read_lock()") the comment in process_pending_softirqs() about
not entering the scheduler should have been moved.
Signed-off-by: Juergen Gross
---
xen/common/softirq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 27.03.2020 11:31, Juergen Gross wrote:
> With commit cef21210fb133 ("rcu: don't process callbacks when holding
> a rcu_read_lock()") the comment in process_pending_softirqs() about
> not entering the scheduler should have been moved.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
On 22.03.2020 17:14, jul...@xen.org wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1138,7 +1138,7 @@ static int
> get_page_from_l2e(
> l2_pgentry_t l2e, mfn_t l2mfn, struct domain *d, unsigned int flags)
> {
> -unsigned long mfn = l2e_get_pfn(l2e);
> +mfn_t mfn = l2
Forgot to cc xen-devel
Begin forwarded message:
From: George Dunlap mailto:george.dun...@citrix.com>>
Subject: [ANNOUNCE] Call for agenda items for April 2020 Community Call @ 15:00
UTC
Date: March 26, 2020 at 6:54:31 PM GMT
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/ed
flight 149049 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149049/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
133580
test-armhf-
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> _mfn(addr >> PAGE_SHIFT) is equivalent to maddr_to_mfn(addr).
>
> Signed-off-by: Julien Grall
Acked-by: Jan Beulich
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> Signed-off-by: Julien Grall
Acked-by: Jan Beulich
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> p2m_pt_audit_p2m() has one place where the same message may be printed
> twice via printk and P2M_PRINTK.
>
> Remove the one printed using printk to stay consistent with the rest of
> the code.
>
> Signed-off-by: Julien Grall
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> We tend to avoid splitting message on multiple line, so it is easier to
> find it.
>
> Signed-off-by: Julien Grall
Acked-by: Jan Beulich
The LLVM repos have switched from http to https, and trying to access
using http will get redirected to https. Add the apt-transport-https
package to the x86 Debian containers that use the LLVM repos, in order
to support the https transport method.
Note that on Arm we only test with gcc, so don't
find_equiv_cpu_id() loops until it finds a 0 installed_cpu entry. Well formed
AMD microcode containers have this property.
Extend the checking in install_equiv_cpu_table() to reject tables which don't
have a sentinal at the end.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC:
Of the substantial number of things which can go wrong during microcode load,
this is not one. Loading occurs entirely within the boundary of a single
WRMSR instruction. Its certainly not a BUG()-worthy condition.
Xen has legitimate reasons to not want interrupts enabled at this point, but
that
flight 149052 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
146121
Regressions w
Currently, each cpu_request_microcode() allocates a struct microcode_patch,
which is a single pointer to a separate allocated structure. This is
wasteful.
Fixing this is complicated because the common microcode_free_patch() code is
responsible for freeing struct microcode_patch, despite this bein
This supercedes the remnants of the Part 1 series, using Jan's suggested
alternative for making struct microcode_patch opaque.
Andrew Cooper (7):
x86/ucode: Remove unnecessary indirection in struct microcode_patch
x86/ucode/intel: Adjust microcode_sanity_check() to not take void *
x86/ucode/
Rewrite the size checks in a way which doesn't depend on Xen being compiled as
64bit.
Introduce a check missing from the old code, that total_size is a multiple of
1024 bytes, and drop unnecessary defines/macros/structures.
No practical change in behaviour.
Signed-off-by: Andrew Cooper
---
CC:
Every caller actually passes a struct microcode_header_intel *, but it is more
helpful to us longterm to take struct microcode_patch *. Implement the
helpers with proper types, and leave a comment explaining the Pentium Pro/II
behaviour with empty {data,total}size fields.
No functional change.
S
With all the necessary cleanup now in place, fold struct
microcode_header_intel into struct microcode_patch and drop the struct
microcode_intel temporary ifdef-ary.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v2:
* Rebase over struc
Implement a new get_ext_sigtable() helper to abstract the logic for
identifying whether an extended signature table exists. As part of this,
rename microcode_intel.bits to data and change its type so it can be usefully
used in combination with the datasize header field.
Also, replace the sigmatch
microcode_sanity_check()'s callers actually call it with a mixture of
microcode_intel(/patch) and microcode_header_intel pointers, which is fragile.
Rework it to take struct microcode_patch *, which in turn requires
microcode_update_match()'s type to be altered.
No functional change - compiled bi
cpu_request_microcode() needs to scan its container and duplicate one blob,
but the get_next_ucode_from_buffer() helper duplicates every blob in turn.
Furthermore, the length checking is only safe from overflow in 64bit builds.
Delete get_next_ucode_from_buffer() and alter the purpose of the saved
On 27.03.2020 12:59, Andrew Cooper wrote:
> find_equiv_cpu_id() loops until it finds a 0 installed_cpu entry. Well formed
> AMD microcode containers have this property.
With this, would you mind adding "potential" to the subject?
> Extend the checking in install_equiv_cpu_table() to reject table
On 27.03.2020 13:19, Andrew Cooper wrote:
> Of the substantial number of things which can go wrong during microcode load,
> this is not one. Loading occurs entirely within the boundary of a single
> WRMSR instruction. Its certainly not a BUG()-worthy condition.
>
> Xen has legitimate reasons to
On 26/03/2020 15:05, Jan Beulich wrote:
> On 26.03.2020 15:50, Andrew Cooper wrote:
>> On a perhaps tangential note, what (if anything) are you plans regarding
>> backport here?
>>
>> These defines are ok for a transitional period across a series (and
>> probably means I'll need to get the AMD side
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> set_gpfn_from_mfn() is currently implement in a 2 part macros. The
> second macro is only called within the first macro, so they can be
> folded together.
>
> Furthermore, this is now converted to a static inline making the code
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> One of the printk format in audit_p2m() may be difficult to read as it
> is not clear what is the first number.
>
> Furthermore, the format can now take advantage of %pd.
>
> Signed-off-by: Julien Grall
Acked-by: Jan Beulich
Updating SVI is required when an interrupt has been injected using the
Ack on exit VMEXIT feature, so that the in service interrupt in the
GUEST_INTR_STATUS matches the vector that is signaled in
VM_EXIT_INTR_INFO.
Updating RVI however is not tied to the Ack on exit feature, as it
signals the next
Force an update of the EOI exit bitmap in nvmx_update_apicv, because
the one performed in vmx_intr_assist might not be reached if the
interrupt is intercepted by nvmx_intr_intercept returning true.
Extract the code to update the exit bitmap from vmx_intr_assist into a
helper and use it in nvmx_upd
Hello,
osstest identified a regression caused by my earlier attempt to fix
interrupt injection when using nested VMX. This series aims to fix the
regression, and should unblock several osstest branches.
The following report is from osstest with this series applied:
http://logs.test-lab.xenprojec
On 22.03.2020 17:14, jul...@xen.org wrote:
> @@ -983,19 +984,20 @@ long p2m_pt_audit_p2m(struct p2m_domain *p2m)
> /* check for 1GB super page */
> if ( l3e_get_flags(l3e[i3]) & _PAGE_PSE )
> {
> -mfn = l3e_get_pfn(l3e[i3]);
> -
On Fri, Mar 27, 2020 at 12:49:47PM +0100, Roger Pau Monne wrote:
> The LLVM repos have switched from http to https, and trying to access
> using http will get redirected to https. Add the apt-transport-https
> package to the x86 Debian containers that use the LLVM repos, in order
> to support the h
On 26/03/2020 14:00, Jan Beulich wrote:
> The nest paging enable is actually just a single bit within the 64-bit
> VMCB field, which is particularly relevant for uses like the one in
> nsvm_vcpu_vmentry().
Lucky for us, these are configuration options, not returned data, so at
least the field won'
From: Paul Durrant
This patch details proposes extra migration data and xenstore protocol
extensions to support non-cooperative live migration of guests.
NOTE: doc/misc/xenstore.txt is also amended to replace the term
for the INTRODUCE operation with the , since this is what
it actu
Paul Durrant (2):
docs/designs: Add a design document for non-cooperative live migration
docs/designs: Add a design document for migration of xenstore data
docs/designs/non-cooperative-migration.md | 280 ++
docs/designs/xenstore-migration.md| 256 +
From: Paul Durrant
It has become apparent to some large cloud providers that the current
model of cooperative migration of guests under Xen is not usable as it
relies on software running inside the guest, which is likely beyond the
provider's control.
This patch introduces a proposal for non-coop
On 26/03/2020 17:29, Dario Faggioli wrote:
> We need python3 (and the respective -devel package), these days.
>
> Signed-off-by: Dario Faggioli
> ---
> Cc: Doug Goldstein
> ---
> .../build/suse/opensuse-tumbleweed.dockerfile |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
On 22.03.2020 17:14, jul...@xen.org wrote:
> --- a/xen/arch/x86/hvm/domain.c
> +++ b/xen/arch/x86/hvm/domain.c
> @@ -296,8 +296,10 @@ int arch_set_info_hvm_guest(struct vcpu *v, const
> vcpu_hvm_context_t *ctx)
> if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) )
> {
>
flight 149087 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149087/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Jan,
On 27/03/2020 13:50, Jan Beulich wrote:
On 22.03.2020 17:14, jul...@xen.org wrote:
--- a/xen/arch/x86/hvm/domain.c
+++ b/xen/arch/x86/hvm/domain.c
@@ -296,8 +296,10 @@ int arch_set_info_hvm_guest(struct vcpu *v, const
vcpu_hvm_context_t *ctx)
if ( hvm_paging_enabled(v) && !paging
The imposed limit of 1023 is too low for a three digit value of vcpus.
Remove the arbitrary value of 1023 and let Xen decide about the upper limit.
Signed-off-by: Olaf Hering
---
docs/man/xl.cfg.5.pod.in | 8 +++-
tools/libxl/libxl_create.c | 2 +-
2 files changed, 4 insertions(+), 6 delet
Olaf Hering writes ("[PATCH v1] libxl: remove limit for default number of event
channels"):
> The imposed limit of 1023 is too low for a three digit value of vcpus.
> Remove the arbitrary value of 1023 and let Xen decide about the upper limit.
This seems likely to be right, but: what is the defau
On Fri, Mar 27, Ian Jackson wrote:
> This seems likely to be right, but: what is the default in Xen ? Is
> it sufficiently tight to stop a guest using too many resources ?
The value of d->max_evtchns will be either 4k or 128k.
AFAICS no extra resources are allocated with the changed value.
Olaf
On 27.03.2020 15:37, Olaf Hering wrote:
> On Fri, Mar 27, Ian Jackson wrote:
>
>> This seems likely to be right, but: what is the default in Xen ? Is
>> it sufficiently tight to stop a guest using too many resources ?
>
> The value of d->max_evtchns will be either 4k or 128k.
> AFAICS no extra r
Hi,
On 27/03/2020 14:37, Olaf Hering wrote:
On Fri, Mar 27, Ian Jackson wrote:
This seems likely to be right, but: what is the default in Xen ? Is
it sufficiently tight to stop a guest using too many resources ?
The value of d->max_evtchns will be either 4k or 128k.
AFAICS no extra resource
Hi Paul,
On 27/03/2020 13:46, Paul Durrant wrote:
From: Paul Durrant
It has become apparent to some large cloud providers that the current
model of cooperative migration of guests under Xen is not usable as it
relies on software running inside the guest, which is likely beyond the
provider's c
On 27/03/2020 13:46, Paul Durrant wrote:
+The semantics of this are similar to the domain issuing
+TRANSACTION_START and receiving the specified as the response.
+The main difference is that the transaction will be immediately marked as
+'conflicting' such that when the domain isses TRANSACTI
> -Original Message-
> From: Julien Grall
> Sent: 27 March 2020 16:58
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich
> ; Konrad Rzeszutek Wilk ; Stefano
> Stabellini
> ; Wei Liu
> Subject: Re: [PA
flight 149096 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149096/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 149074 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149074/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
Nothing looks at this yet.
Signed-off-by: Ian Jackson
---
ts-logs-capture | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/ts-logs-capture b/ts-logs-capture
index d16372f2..88b19658 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -39,7 +39,7 @@ if (!$ho) {
ex
We'll need this in a moment.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 1c13e2af..5fb78468 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -114
This allows us to add some stuff to add to each pattern, and each
filename. This will be useful in a moment.
None of the call sites pass this yet.
Signed-off-by: Ian Jackson
---
ts-logs-capture | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/ts-logs-capture b/ts
Signed-off-by: Ian Jackson
---
README.dev | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README.dev b/README.dev
index e32889b7..2cbca109 100644
--- a/README.dev
+++ b/README.dev
@@ -115,7 +115,7 @@ and boot Xen:
$ hn=mudcake
$ flight=`./make-hosts-flight play xen-uns
Now @general_logs contains logs we want from guests as well as hosts.
Signed-off-by: Ian Jackson
---
ts-logs-capture | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/ts-logs-capture b/ts-logs-capture
index ae37d492..418155ce 100755
--- a/ts-logs-capture
+++ b/ts-lo
We are going to fetch logs out of guests. @general_logs will contain
the relevant patterns. Right now we just introduce the variable and
split the list. The categorisation is roughly right...
Signed-off-by: Ian Jackson
---
ts-logs-capture | 7 +--
1 file changed, 5 insertions(+), 2 deleti
This involves shutting the guests down. We use this shell rune
because xl doesn't provide a good way to ensure there are no guests
running.
Signed-off-by: Ian Jackson
---
ts-logs-capture | 30 ++
1 file changed, 30 insertions(+)
diff --git a/ts-logs-capture b/ts-log
On 24/03/2020 12:30, Jan Beulich wrote:
> --- a/tools/tests/x86_emulator/evex-disp8.c
> +++ b/tools/tests/x86_emulator/evex-disp8.c
> @@ -550,6 +550,12 @@ static const struct test avx512_4vnniw_5
> INSN(p4dpwssds, f2, 0f38, 53, el_4, d, vl),
> };
>
> +static const struct test avx512_bf16_al
Signed-off-by: Ian Jackson
---
ts-examine-hostprops-save | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ts-examine-hostprops-save b/ts-examine-hostprops-save
index e50ea7fb..3995a7a7 100755
--- a/ts-examine-hostprops-save
+++ b/ts-examine-hostprops-save
@@ -31,8 +31,8 @@
This tools is analogous to 'xen-hvmctx' which presents HVM context.
Subsequent patches will add 'dump' functions when new records are
introduced.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
.gitignore | 1 +
tools/misc/Makefile | 4 ++
tools/misc/xen-ctx.c |
Domain context is state held in the hypervisor that does not come under
the category of 'HVM state' but is instead 'PV state' that is common
between PV guests and enlightened HVM guests (i.e. those that have PV
drivers) such as event channel state, grant entry state, etc.
To allow enlightened HVM
... in the save/restore code.
This patch replaces direct mapping of the shared_info_frame (retrieved
using XEN_DOMCTL_getdomaininfo) with save/load of the domain context
SHARED_INFO record.
No modifications are made to the definition of the migration stream at
this point. Subsequent patches will
Paul Durrant (5):
xen/common: introduce a new framework for save/restore of 'domain'
context
xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext
tools/misc: add xen-ctx to present domain context
common/domain: add a domain context record for shared_info...
tools/libxc: make u
These domctls provide a mechanism to get and set domain context from
the toolstack.
Signed-off-by: Paul Durrant
---
Cc: Daniel De Graaf
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
---
tools/flask/policy/modules/x
... and update xen-ctx to dump some information describing the record.
NOTE: To allow a sensible definition of the record in public/save.h
this patch also adds a definition of the Xen ABI's de-facto page
size into public/xen.h.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei
From: Julien Grall
bad_ioapic_register() is return a bool, so we should switch to
true/false.
Signed-off-by: Julien Grall
---
xen/arch/x86/io_apic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index e98e08e9c8..9868933
From: Julien Grall
Since commit 9facd54a45 "x86/ioapic: Add register level checks to detect
bogus io-apic entries", Xen is able to cope with IO APICs not mapped in
the fixmap.
Therefore the whole logic to allocate a fake page for some IO APICs is
unnecessary.
With the logic removed, the code ca
From: Julien Grall
The function init_ioapic_mappings() is doing more than initialization
mappings. It is also initialization the number of IRQs/GSIs supported.
So rename the function to init_ioapic(). This will allow us to re-use
the name in a follow-up patch.
Signed-off-by: Julien Grall
---
From: Julien Grall
Hi all,
The main goal of this small series is to simplify ioapic_init().
Cheers,
Julien Grall (3):
xen/x86: ioapic: Use true/false in bad_ioapic_register()
xen/x86: ioapic: Rename init_ioapic_mappings() to init_ioapic()
xen/x86: ioapic: Simplify ioapic_init()
xen/arc
flight 149071 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149071/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 695d90b9b156573d0dafb20afecea09dc9a914f4
baseline version:
ovmf f52b30e73ddee9a3a609a
For each UNIT, sched_set_affinity is called before unit->priv is updated
to the new cpupool private UNIT data structure. The issue is
sched_set_affinity will call the adjust_affinity method of the cpupool.
If defined, the new cpupool may use unit->priv (e.g. credit), which at
this point still refer
flight 149110 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149110/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Fri, Mar 27, 2020 at 2:12 AM Paul Durrant wrote:
>
> > -Original Message-
> > From: Roman Shaposhnik
> > Sent: 26 March 2020 22:03
> > To: Roger Pau Monné
> > Cc: xen-devel@lists.xenproject.org; Jan Beulich ; Paul
> > Durrant ;
> > Kevin Tian ; Andrew Cooper
> > Subject: Re: [Xen-de
flight 149072 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149072/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
148666
Tests which did
flight 149068 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149068/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 16 guest-localmigrate fail REGR. vs. 148925
Tests which did no
Assignment to a typed pointer is sufficient in C.
No cast is needed.
Signed-off-by: Simran Singhal
---
xen/arch/x86/acpi/cpufreq/powernow.c | 2 +-
xen/arch/x86/cpu/vpmu.c | 2 +-
xen/arch/x86/hpet.c | 2 +-
xen/arch/x86/hvm/save.c | 2 +-
xen/arch/x86/
82 matches
Mail list logo
