While the REP MOVS acceleration appears to have helped qemu-traditional
based guests, qemu-upstream (or really the respective video BIOSes)
doesn't appear to benefit from that. Instead the acceleration added
here provides a visible performance improvement during very early HVM
guest boot.
Signed-o
Following the earlier similar change validating CR4 modifications.
Signed-off-by: Jan Beulich
---
v2: consider CR0.PG during restore when checking EFER.LMA
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1672,20 +1672,53 @@ static int hvm_save_cpu_ctxt(struct doma
return 0;
}
Remove the function set_pte_mfn() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
arch/x86/xen/mmu.c |9 -
arch/x86/xen/mmu.h |2 --
2 files changed, 11 deletions(-)
diff --git
XENMEM_{in,de}crease_reservation as well as XENMEM_populate_physmap
return the extent at which failure was detected, not error indicators.
Signed-off-by: Jan Beulich
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -747,11 +747,10 @@ long do_memory_op(unsigned long cmd, XEN
re
While for us it's not as bad as it was for Linux, their commit
13e457e0ee ("KVM: x86: Emulator does not decode clflush well", by
Nadav Amit ) nevertheless points out two
shortcomings in our code: opcode 0F AE /7 is clflush only when it uses
a memory mode (otherwise it's SFENCE) and when there's no
On 01/11/2015 11:35 PM, Rickard Strandqvist wrote:
Remove the function set_pte_mfn() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Sorry, you seem not to have checked the newest kernel.
Used by:
xen_do_set_identity_and_remap_chu
We've had reports of systems where CMCIs would surface at a relatively
high rate during certain periods of time, without them apparently
causing subsequent more severe problems (see Xeon E7-8800/4800/2800
specification clarification SC1). Give the admin a knob to lower the
impact on the system logs
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, January 09, 2015 6:35 PM
>
> >>> On 09.01.15 at 11:10, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Boot time device assignment is different: The question isn't whether
> >> an assigned device works, instead the prop
On Thu, Jan 08, Jan Beulich wrote:
> now that 4.5 is almost out the door, I'd like to get stable releases
> prepared on the other two active branches. 4.3.4 is expected to be
> the last xen.org managed release on the 4.3 branch. Aiming at RC1s
> some time next week, please indicate commits you con
flight 33341 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33341/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32448
Tests which did not succeed, bu
The trivial wrapper evtchn_set_pending() is pretty pointless, as it
only serves to invoke another wrapper evtchn_port_set_pending(). In
turn, the latter is kind of inconsistent with its siblings in that is
takes a struct vcpu * rather than a struct domain * - adjusting this
allows for more efficien
- don't bail when using the last slot of bootinfo.mem.bank[] (due to
premature incrementing of the array index)
- GUIDs should be static const (and placed into .init.* whenever
possible)
- PrintErrMsg() issues a CR/LF pair itself - no need to explicitly
append one to the message passed to the
In particular the .rodata.str2 case is relevant for the EFI boot code
(moving around 3k from permanent to init-time sections).
Signed-off-by: Jan Beulich
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -170,7 +170,10 @@ _clean_%/: FORCE
%.o: %.S Makefile
$(CC) $(AFLAGS) -c $< -o $@
-SPECIAL_
>>> On 12.01.15 at 09:47, wrote:
> On Thu, Jan 08, Jan Beulich wrote:
>
>> now that 4.5 is almost out the door, I'd like to get stable releases
>> prepared on the other two active branches. 4.3.4 is expected to be
>> the last xen.org managed release on the 4.3 branch. Aiming at RC1s
>> some time
Il 09/01/2015 18:38, Dario Faggioli ha scritto:
On Fri, 2015-01-09 at 14:42 +, Wei Liu wrote:
On Thu, Jan 08, 2015 at 03:33:17PM +0100, Fabio Fantoni wrote:
Sorry for the probably stupid question, what are the pros and cons of
default use of phy instead qdisk for raw files as domU disk?
T
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, January 09, 2015 6:46 PM
>
> >>> On 09.01.15 at 11:26, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >>> On 09.01.15 at 07:57, wrote:
> >> > 1.1) per-device 'warn' vs. global 'warn'
> >> >
> >> > Both Tim/Jan prefer
On Mon, 2015-01-12 at 10:15 +0100, Fabio Fantoni wrote:
> In the meantime, I saw this:
> http://lists.xen.org/archives/html/xen-users/2015-01/msg00047.html
> Based on the post above seems that phy will have important risk of data
> loss if I understand good, from Ian Campbell post:
> > xl also use
>>> On 12.01.15 at 09:46, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, January 09, 2015 6:35 PM
>> >>> On 09.01.15 at 11:10, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> The question isn't about migrating with devices assigned, but about
>> >> assig
Il 12/01/2015 10:31, Ian Campbell ha scritto:
On Mon, 2015-01-12 at 10:15 +0100, Fabio Fantoni wrote:
In the meantime, I saw this:
http://lists.xen.org/archives/html/xen-users/2015-01/msg00047.html
Based on the post above seems that phy will have important risk of data
loss if I understand good,
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 5:33 PM
>
> >>> On 12.01.15 at 09:46, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, January 09, 2015 6:35 PM
> >> >>> On 09.01.15 at 11:10, wrote:
> >> >> From: Jan Beulich [mailto:jbe
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Saturday, January 10, 2015 4:28 AM
>
> On Thu, Jan 08, 2015 at 06:02:04PM +, George Dunlap wrote:
> > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote:
> > On 08.01.15 at 16:59, wrote:
> > >> On Thu, Jan 8, 2015 at 1
The resource behind an event channel is domain centric rather than vcpu
centric, and free_xen_event_channel() only follows the vcpu's domain pointer.
This change allows mem_event_disable() to avoid arbitrarily referencing
d->vcpu[0] just to pass the domain.
No functional change.
Signed-off-by: A
On Fri, 2015-01-09 at 17:00 -0500, moftah moftah wrote:
> Hi Ian,
>
>
> OK, I have followed your suggestions and created a new patch
Thanks, please submit it in the form describe in the wiki page
http://wiki.xen.org/wiki/Submitting_Xen_Patches which I referenced
before.
In particular, a Signed-
>>> On 12.01.15 at 10:41, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, January 12, 2015 5:33 PM
>> >>> On 12.01.15 at 09:46, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Friday, January 09, 2015 6:35 PM
>> >> >>> On 09.01.15 at 11:10, wrote:
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 5:51 PM
>
> >>> On 12.01.15 at 10:41, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 5:33 PM
> >> >>> On 12.01.15 at 09:46, wrote:
> >> >> From: Jan Beulich [mailto:jbe
>>> On 10.01.15 at 00:04, wrote:
> On 01/09/2015 02:41 PM, Andrew Cooper wrote:
>> Having some non-OS part of the guest swap the EPT tables and
>> accidentally turn a DMA buffer read-only is not going to end well.
>>
>
> The agent can certainly do bad things, and at some level you have to assume
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Andrew Cooper
> Sent: 12 January 2015 09:47
> To: Xen-devel
> Cc: Andrew Cooper; Keir (Xen.org); Jan Beulich
> Subject: [Xen-devel] [PATCH] xen/evtchn: Alter free_xen_event_
On Mon, 2015-01-12 at 10:39 +0100, Fabio Fantoni wrote:
> Il 12/01/2015 10:31, Ian Campbell ha scritto:
> > On Mon, 2015-01-12 at 10:15 +0100, Fabio Fantoni wrote:
> >> In the meantime, I saw this:
> >> http://lists.xen.org/archives/html/xen-users/2015-01/msg00047.html
> >> Based on the post above
>>> On 12.01.15 at 10:46, wrote:
> The resource behind an event channel is domain centric rather than vcpu
> centric, and free_xen_event_channel() only follows the vcpu's domain
> pointer.
I wonder whether for symmetry alloc_unbound_xen_event_channel()
shouldn't then also take a [struct domain *
>>> On 12.01.15 at 10:56, wrote:
> the result is related to another open whether we want to block guest
> boot for such problem. If 'warn' in domain builder is acceptable, we
> don't need to change lowmem for such rare 1GB case, just throws
> a warning for unnecessary conflictions (doesn't hurt if
On 12/01/15 10:07, Jan Beulich wrote:
On 12.01.15 at 10:46, wrote:
>> The resource behind an event channel is domain centric rather than vcpu
>> centric, and free_xen_event_channel() only follows the vcpu's domain
>> pointer.
> I wonder whether for symmetry alloc_unbound_xen_event_channel()
This is RFC because explicitly changes the logic introduced by c/s b34f2c375
"xsm: label xen-consumer event channels", and is only compile tested.
Xen event channels are not internal resources. They still have one end in a
domain, and are created at the request of privileged domains. This logic
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 6:09 PM
>
> >>> On 12.01.15 at 10:56, wrote:
> > the result is related to another open whether we want to block guest
> > boot for such problem. If 'warn' in domain builder is acceptable, we
> > don't need to change l
Il 12/01/2015 11:06, Ian Campbell ha scritto:
On Mon, 2015-01-12 at 10:39 +0100, Fabio Fantoni wrote:
Il 12/01/2015 10:31, Ian Campbell ha scritto:
On Mon, 2015-01-12 at 10:15 +0100, Fabio Fantoni wrote:
In the meantime, I saw this:
http://lists.xen.org/archives/html/xen-users/2015-01/msg00047
On Mon, 2015-01-12 at 11:17 +0100, Fabio Fantoni wrote:
> Il 12/01/2015 11:06, Ian Campbell ha scritto:
> > On Mon, 2015-01-12 at 10:39 +0100, Fabio Fantoni wrote:
> >> Il 12/01/2015 10:31, Ian Campbell ha scritto:
> >>> On Mon, 2015-01-12 at 10:15 +0100, Fabio Fantoni wrote:
> In the meantime
On Mon, 2015-01-12 at 10:03 +, Andrew Cooper wrote:
> This is RFC because explicitly changes the logic introduced by c/s b34f2c375
> "xsm: label xen-consumer event channels", and is only compile tested.
>
> Xen event channels are not internal resources. They still have one end in a
> domain,
>>> On 12.01.15 at 11:12, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, January 12, 2015 6:09 PM
>>
>> >>> On 12.01.15 at 10:56, wrote:
>> > the result is related to another open whether we want to block guest
>> > boot for such problem. If 'warn' in domain builder is
On 2015/01/12 9:44, Jan Beulich wrote:
> We've had reports of systems where CMCIs would surface at a relatively
> high rate during certain periods of time, without them apparently
> causing subsequent more severe problems (see Xeon E7-8800/4800/2800
> specification clarification SC1). Give the admi
On 12/01/15 10:22, Ian Campbell wrote:
> On Mon, 2015-01-12 at 10:03 +, Andrew Cooper wrote:
>> This is RFC because explicitly changes the logic introduced by c/s b34f2c375
>> "xsm: label xen-consumer event channels", and is only compile tested.
>>
>> Xen event channels are not internal resourc
On 12/01/15 08:00, Jan Beulich wrote:
> Following the earlier similar change validating CR4 modifications.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
> ---
> v2: consider CR0.PG during restore when checking EFER.LMA
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @
On 12/01/15 08:01, Jan Beulich wrote:
> While the REP MOVS acceleration appears to have helped qemu-traditional
> based guests, qemu-upstream (or really the respective video BIOSes)
> doesn't appear to benefit from that. Instead the acceleration added
> here provides a visible performance improveme
On 12/01/15 08:57, Jan Beulich wrote:
> The trivial wrapper evtchn_set_pending() is pretty pointless, as it
> only serves to invoke another wrapper evtchn_port_set_pending(). In
> turn, the latter is kind of inconsistent with its siblings in that is
> takes a struct vcpu * rather than a struct doma
On 12/01/15 08:23, Jan Beulich wrote:
> While for us it's not as bad as it was for Linux, their commit
> 13e457e0ee ("KVM: x86: Emulator does not decode clflush well", by
> Nadav Amit ) nevertheless points out two
> shortcomings in our code: opcode 0F AE /7 is clflush only when it uses
> a memory m
On 12/01/15 08:21, Jan Beulich wrote:
> XENMEM_{in,de}crease_reservation as well as XENMEM_populate_physmap
> return the extent at which failure was detected, not error indicators.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
>
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.
On 12/01/15 05:05, Juergen Gross wrote:
> In the setup code of the linear mapped p2m list several bugs have
> been found, especially for 32 bit dom0. These patches correct the
> errors and make 32 bit dom0 bootable again.
Applied to stable/for-linus-3.19, thanks.
David
__
On 10/01/15 09:20, Vincenzo Maffione wrote:
> This patch removes some unused arrays from the netfront private
> data structures. These arrays were used in "flip" receive mode.
Reviewed-by: David Vrabel
Thanks.
David
___
Xen-devel mailing list
Xen-dev
On 09/01/15 08:02, Tian, Kevin wrote:
>> From: Tim Deegan [mailto:t...@xen.org]
>> Sent: Thursday, January 08, 2015 8:43 PM
>>
>> Hi,
>>
Not really. The IOMMU tables are also 64-bit so there must be enough
addresses to map all of RAM. There shouldn't be any need for these
mappings
On Wed, 3 Dec 2014, Don Slutz wrote:
> From: Stefano Stabellini
>
> Increase maxmem before calling xc_domain_populate_physmap_exact to
> avoid the risk of running out of guest memory. This way we can also
> avoid complex memory calculations in libxl at domain construction
> time.
>
> This patch
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 6:23 PM
>
> >>> On 12.01.15 at 11:12, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 6:09 PM
> >>
> >> >>> On 12.01.15 at 10:56, wrote:
> >> > the result is related to a
On Fri, Jan 9, 2015 at 2:43 AM, Tian, Kevin wrote:
>> From: George Dunlap
>> Sent: Thursday, January 08, 2015 8:55 PM
>>
>> On Thu, Jan 8, 2015 at 12:49 PM, George Dunlap
>> wrote:
>> > If RMRRs almost always happen up above 2G, for example, then a simple
>> > solution that wouldn't require too m
On 08/01/15 15:06, Imre Palik wrote:
> On 01/07/15 17:30, Ian Campbell wrote:
>> On Wed, 2015-01-07 at 17:16 +0100, Imre Palik wrote:
>>> From: "Palik, Imre"
>>>
>>> In Dom0's the use of the TSC clocksource (whenever it is stable enough to
>>> be used) instead of the Xen clocksource should not cau
On 12/01/15 08:57, Jan Beulich wrote:
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -152,10 +152,11 @@ static inline void evtchn_port_init(stru
> d->evtchn_port_ops->init(d, evtchn);
> }
>
> -static inline void evtchn_port_set_pending(struct vcpu *v,
> +static inl
On Wed, 24 Dec 2014, Liang Li wrote:
> Use the 'xl pci-attach $DomU $BDF' command to attach more then
> one PCI devices to the guest, then detach the devices with
> 'xl pci-detach $DomU $BDF', after that, re-attach these PCI
> devices again, an error message will be reported like following:
>
> li
El 12/01/15 a les 8.09, Bob Liu ha escrit:
>
> On 01/09/2015 11:51 PM, Roger Pau Monné wrote:
>> El 06/01/15 a les 14.19, Bob Liu ha escrit:
>>> When there is no enough free grants, gnttab_alloc_grant_references()
>>> will fail and block request queue will stop.
>>> If the system is always lack of
On 9 Jan 2015, at 18:30, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 09, 2015 at 01:51:56PM +, Lars Kurth wrote:
>> Note that I published the Acknowledgements and most 4.5 documentation is now
>> in place. Bits which you may want to check and fix
>> * Spelling of your name if it contains spe
>>> On 12.01.15 at 12:22, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, January 12, 2015 6:23 PM
>> One of my main problems with all you recent argumentation here
>> is the arbitrary use of the 1Gb boundary - there's nothing special
>> in this discussion with where the b
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 7:37 PM
>
> >>> On 12.01.15 at 12:22, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 6:23 PM
> >> One of my main problems with all you recent argumentation here
> >> is t
>>> On 12.01.15 at 12:33, wrote:
> On 12/01/15 08:57, Jan Beulich wrote:
>> --- a/xen/include/xen/event.h
>> +++ b/xen/include/xen/event.h
>> @@ -152,10 +152,11 @@ static inline void evtchn_port_init(stru
>> d->evtchn_port_ops->init(d, evtchn);
>> }
>>
>> -static inline void evtchn_por
> From: Stefano Stabellini
> Sent: Monday, January 12, 2015 7:36 PM
>
> On Wed, 24 Dec 2014, Liang Li wrote:
> > Use the 'xl pci-attach $DomU $BDF' command to attach more then
> > one PCI devices to the guest, then detach the devices with
> > 'xl pci-detach $DomU $BDF', after that, re-attach these
>>> On 12.01.15 at 12:41, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, January 12, 2015 7:37 PM
>>
>> >>> On 12.01.15 at 12:22, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Monday, January 12, 2015 6:23 PM
>> >> One of my main problems with a
On Fri, 2015-01-09 at 15:27 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 08, 2015 at 06:02:04PM +, George Dunlap wrote:
> > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote:
> > On 08.01.15 at 16:59, wrote:
> > >> On Thu, Jan 8, 2015 at 1:54 PM, Jan Beulich wrote:
> > the 1st
On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, January 12, 2015 6:23 PM
>>
>> >>> On 12.01.15 at 11:12, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Monday, January 12, 2015 6:09 PM
>> >>
>> >> >>> On
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 8:03 PM
>
> >>> On 12.01.15 at 12:41, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 7:37 PM
> >>
> >> >>> On 12.01.15 at 12:22, wrote:
> >> >> From: Jan Beulich [mailt
Ed White writes ("[PATCH 00/11] Alternate p2m: support multiple copies of host
p2m"):
> This set of patches adds support to hvm domains for EPTP switching
> by creating multiple copies of the host p2m (currently limited to 10
> copies).
Thanks for this. Did you CC me in my capacity as tools main
Ian Campbell writes ("[OSSTEST PATCH] mg-debian-installer-update: produce
deterministic output"):
> Currently rerunning mg-debian-install-update when the external files
> have changed still produces differences in the local files produced
^
Missing "not" ?
> during post-processing.
>
> Avo
On Mon, 2015-01-12 at 12:13 +, George Dunlap wrote:
> On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 6:23 PM
> >>
> >> >>> On 12.01.15 at 11:12, wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.
Ian Campbell writes ("Re: [Xen-devel] [OSSTEST PATCH]
mg-debian-installer-update: produce deterministic output"):
> We might like to consider something along these lines for the future:
A reasonable idea (although I wonder if it should be configurable).
Acked-by: Ian Jackson
Ian.
> From: George Dunlap
> Sent: Monday, January 12, 2015 8:14 PM
>
> On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 6:23 PM
> >>
> >> >>> On 12.01.15 at 11:12, wrote:
> >> >> From: Jan Beulich [mailto:jbeu
> From: Tian, Kevin
> Sent: Monday, January 12, 2015 8:29 PM
>
> > From: George Dunlap
> > Sent: Monday, January 12, 2015 8:14 PM
> >
> > On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin
> wrote:
> > >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> Sent: Monday, January 12, 2015 6:23 PM
> > >>
On Mon, 2015-01-12 at 12:27 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [OSSTEST PATCH]
> mg-debian-installer-update: produce deterministic output"):
> > We might like to consider something along these lines for the future:
>
> A reasonable idea (although I wonder if it shou
On Thu, Jan 8, 2015 at 1:11 AM, Mike Latimer wrote:
> On Wednesday, January 07, 2015 09:38:31 AM Ian Campbell wrote:
>> That's exactly what I was about to suggest as I read the penultimate
>> paragraph, i.e. keep waiting so long as some reasonable delta occurs on
>> each iteration.
>
> Thanks, Ian
xen.org writes ("[xen-4.5-testing test] 33303: regressions - FAIL"):
> flight 33303 xen-4.5-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33303/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i
>>> On 12.01.15 at 13:16, wrote:
> I've explained this several times. If there's a violation on above
> assumption
> from required devices, same for report-all and report-sel. If the violation
> is
> caused by unnecessary devices, please note I'm proposing 'warn' here so
> report-all at most j
On 12/01/15 11:36, Roger Pau Monné wrote:
> El 12/01/15 a les 8.09, Bob Liu ha escrit:
>>
>> On 01/09/2015 11:51 PM, Roger Pau Monné wrote:
>>> El 06/01/15 a les 14.19, Bob Liu ha escrit:
When there is no enough free grants, gnttab_alloc_grant_references()
will fail and block request queu
On 09/01/15 21:26, Ed White wrote:
> Currently, neither is enabled globally but may be enabled on a per-VCPU
> basis by the altp2m code.
>
> Everything can be force-disabled globally by specifying vmfunc=0 on the
> Xen command line.
>
> Remove the check for EPTE bit 63 == zero in ept_split_super_pa
Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
setup_IO_APIC(), so no irqdomains created for IOAPICs and
mp_map_pin_to_irq() fails at the very beginning.
Enhance xen_smp_prepare_cpus() to call setup_IO_AP
> > > Use the 'xl pci-attach $DomU $BDF' command to attach more than one
> > > PCI devices to the guest, then detach the devices with 'xl
> > > pci-detach $DomU $BDF', after that, re-attach these PCI devices
> > > again, an error message will be reported like following:
> > >
> > > libxl: error: li
On Fri, 2015-01-09 at 06:57 +, Tian, Kevin wrote:
> 3) report-sel vs. report-all
One thing I'm not clear on is whether you are suggesting to reserve RMRR
(either -all or -sel) for every domain by default, or whether the guest
CFG will need to explicitly opt-in, IOW is there a 3rd report-none
o
On Mon, 2015-01-12 at 08:59 +, Jan Beulich wrote:
> - don't bail when using the last slot of bootinfo.mem.bank[] (due to
> premature incrementing of the array index)
> - GUIDs should be static const (and placed into .init.* whenever
> possible)
> - PrintErrMsg() issues a CR/LF pair itself -
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, January 12, 2015 9:42 PM
>
> On Fri, 2015-01-09 at 06:57 +, Tian, Kevin wrote:
> > 3) report-sel vs. report-all
>
> One thing I'm not clear on is whether you are suggesting to reserve RMRR
> (either -all or -sel) for every
On Mon, 2015-01-12 at 00:01 -0700, Chun Yan Liu wrote:
>
> >>> On 1/8/2015 at 08:26 PM, in message
> >>> <1420719995.19787.62.ca...@citrix.com>, Ian
> Campbell wrote:
> > On Mon, 2014-12-22 at 20:42 -0700, Chun Yan Liu wrote:
> > >
> > > >>> On 12/19/2014 at 06:25 PM, in message
> > <14189
On Mon, Jan 12, 2015 at 11:25:56AM +, George Dunlap wrote:
> On Fri, Jan 9, 2015 at 2:43 AM, Tian, Kevin wrote:
> >> From: George Dunlap
> >> Sent: Thursday, January 08, 2015 8:55 PM
> >>
> >> On Thu, Jan 8, 2015 at 12:49 PM, George Dunlap
> >> wrote:
> >> > If RMRRs almost always happen up a
On Mon, 2015-01-12 at 13:53 +, Tian, Kevin wrote:
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: Monday, January 12, 2015 9:42 PM
> >
> > On Fri, 2015-01-09 at 06:57 +, Tian, Kevin wrote:
> > > 3) report-sel vs. report-all
> >
> > One thing I'm not clear on is whether y
>>> On 12.01.15 at 14:46, wrote:
> On Mon, 2015-01-12 at 08:59 +, Jan Beulich wrote:
>> - don't bail when using the last slot of bootinfo.mem.bank[] (due to
>> premature incrementing of the array index)
>> - GUIDs should be static const (and placed into .init.* whenever
>> possible)
>> - P
branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-qemuu-win7-amd64
test windows-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemu
On Mon, 2015-01-12 at 09:00 +, Jan Beulich wrote:
> In particular the .rodata.str2 case is relevant for the EFI boot code
> (moving around 3k from permanent to init-time sections).
So we go from handling .rodata.str1.{1,2,3,8}
to .rodata.str{1,2,4}.{1,2,4,8,16}?
> Signed-off-by: Jan Beulich
>>> On 12.01.15 at 15:03, wrote:
> On Mon, 2015-01-12 at 09:00 +, Jan Beulich wrote:
>> In particular the .rodata.str2 case is relevant for the EFI boot code
>> (moving around 3k from permanent to init-time sections).
>
> So we go from handling .rodata.str1.{1,2,3,8}
> to .rodata.str{1,2,4}.{
On Mon, Jan 12, 2015 at 12:28 PM, Tian, Kevin wrote:
>> From: George Dunlap
>> Sent: Monday, January 12, 2015 8:14 PM
>>
>> On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Monday, January 12, 2015 6:23 PM
>> >>
>> >> >>> On 12.01
On Mon, Jan 12, 2015 at 1:56 PM, Pasi Kärkkäinen wrote:
> On Mon, Jan 12, 2015 at 11:25:56AM +, George Dunlap wrote:
>> So qemu-traditional didn't particularly expect to know the guest
>> memory layout. qemu-upstream does; it expects to know what areas of
>> memory are guest memory and what a
On 12/01/2015 14:35, Li, Liang Z wrote:
>
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index c1bf357..f2893b2 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -736,7 +736,7 @@ static int xen_pt_initfn(PCIDevice *d)
> }
>
> out:
> -memory_listener_register(&s->memory_li
On 01/10/2015 12:03 AM, Jim Fehlig wrote:
> This reverts commit 2c78051a14acfb7aba078d569b1632dfe0ca0853.
>
> Conflicts:
> src/Makefile.am
>
> Signed-off-by: Jim Fehlig
> ---
> .gitignore| 1 -
> cfg.mk| 3 +-
> configure.ac
On Fri, Jan 9, 2015 at 12:10 PM, Jan Beulich wrote:
On 09.01.15 at 12:45, wrote:
>> At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote:
>>> >>> On 09.01.15 at 12:18, wrote:
>>> >> > +default:
>>> >> > +xfree(buf);
>>> >> > +ASSERT(!buf);
>>>
Adding some CC's, including the devel list.
On Fri, 2015-01-09 at 19:49 -0600, Doug McMillan wrote:
>
>
> configuration(?)
> I compiled booted straight from bios with xen.efi during boot I received
> several errors.
> xl info works (see attachment). XL list locks the terminal session. Checking
On 12/01/15 13:39, Jiang Liu wrote:
> Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
> breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
> setup_IO_APIC(), so no irqdomains created for IOAPICs and
> mp_map_pin_to_irq() fails at the very beginning.
>
> En
flight 33359 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33359/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 33317
Tests which did not succe
On Fri, 2015-01-09 at 22:03 -0700, Jim Fehlig wrote:
> The first attempt to implement support for parsing/formatting Xen's
> xl disk config format copied Xen's flex-based parser into libvirt, which
> has proved to be challenging in the context of autotools. But as it turns
> out, Xen provides an i
El 12/01/15 a les 14.04, David Vrabel ha escrit:
> On 12/01/15 11:36, Roger Pau Monné wrote:
>> El 12/01/15 a les 8.09, Bob Liu ha escrit:
>>>
>>> On 01/09/2015 11:51 PM, Roger Pau Monné wrote:
El 06/01/15 a les 14.19, Bob Liu ha escrit:
> When there is no enough free grants, gnttab_alloc_
flight 33348 xen-4.5-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33348/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass
test-amd64-amd64-xl-pvh-amd 9 gue
TDB provides us with a callback for this purpose. Use it in both
xenstored and xs_tdb_dump.
While at it make the existing log() macro tollerate memory failures.
Signed-off-by: Ian Campbell
---
v2: Use &tdb_logger consistently.
Did not: move location of talloc_free, since talloc_free(NULL)
Do the usual stuffs for adding a new branch (ap-* cr-* etc).
Modify ts-xen-build so that it builds Xen with the specified ovmf tree
and revision.
Only build and test on x86 by modifying make-flight and mfi-common.
New branch is added to cr-daily-branch. It exports the tree and
changeset used for
1 - 100 of 225 matches
Mail list logo
