>>> On 20.11.14 at 02:23, wrote:
> On 11/17/2014 23:54, Jan Beulich wrote:
>> Another thing - now that serial logging appears to be working for
>> you, did you try whether the host, once hung, still reacts to serial
>> input (perhaps force input to go to Xen right at boot via the
>> "conswitch=" o
>>> On 20.11.14 at 08:45, wrote:
> Yang and I did some discussion here. We understand your point to
> avoid introducing new interface if we can leverage existing code.
> However it's not a trivial effort to move device assignment before
> populating p2m, and there is no other benefit of doing so
>>> On 19.11.14 at 17:44, wrote:
> On Fri, Nov 14, 2014 at 11:11:46AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Nov 14, 2014 at 03:13:42PM +, Jan Beulich wrote:
>> > >>> On 12.11.14 at 03:23, wrote:
>> > > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
>> > > +{
>> >
On 2014/11/20 15:31, Jan Beulich wrote:
On 19.11.14 at 02:26, wrote:
So without lookuping devices[i], how can we call func() for each sbdf as
you mentioned?
You've got both rmrr and bdf in the body of for_each_rmrr_device().
After all - as I said - you just open-coded it.
Yeah, so change th
Hi Ian,
Both of your two points are valid. There is no need to install
virt-manager. And the patch to start a qemu process in /etc/init.d/xen
seems to be enough for launching instances from horizon. I have updated the
wiki page. Please review it at
http://wiki.xenproject.org/wiki/Xen_via_libvirt
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, November 20, 2014 4:04 PM
>
> >>> On 20.11.14 at 08:45, wrote:
> > Yang and I did some discussion here. We understand your point to
> > avoid introducing new interface if we can leverage existing code.
> > However it's not a trivial
>>> On 19.11.14 at 16:12, wrote:
> This is getting more interesting. It seems that something is
> overwriting the pci-back configuration data.
>
> Starting from a fresh reboot I checked the Dom0 pci configuration and
> got this:
>
> root@smartin-xen:~# lspci -s 00:19.0 -x
> 00:19.0 Et
>>> On 20.11.14 at 09:12, wrote:
> On 2014/11/20 15:31, Jan Beulich wrote:
> On 19.11.14 at 02:26, wrote:
>>> int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>> {
>>> struct acpi_rmrr_unit *rmrr;
>>> int rc = 0;
>>> unsigned int i;
>>> u16 b
On Wed, 2014-11-19 at 12:46 -0700, Donald D. Dugger wrote:
> Currently the quirk code for SandyBridge uses the VTd timeout value when
You've got a typo in the subject ("SnadyBridge").
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen
On Wed, 2014-11-19 at 16:18 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 04:51:42PM +, Ian Campbell wrote:
> > On Tue, 2014-11-18 at 16:44 +, Ian Campbell wrote:
> > > These patches:
> >
> > ... which are also at
> > git://xenbits.xen.org/people/ianc/xen.git mcdivi
The already documented configure patch was not applied.
Adjust documentation to describe existing behaviour.
Signed-off-by: Olaf Hering
---
INSTALL | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/INSTALL b/INSTALL
index 6bb9d23..656c90a 100644
--- a/INSTA
On Mon, 2014-11-17 at 13:00 +, Stefano Stabellini wrote:
> On Mon, 17 Nov 2014, Ian Campbell wrote:
> > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > By the way, how many NICs can I apply to a VM?
> > >
> > > On xen-4.4.0, Using qemu-dm, I can apply 8 NIC to a VM, but using
> > >
On Wed, 2014-11-19 at 11:57 -0700, Xing Lin wrote:
> Hi Ian,
>
>
> Both of your two points are valid. There is no need to install
> virt-manager. And the patch to start a qemu process in /etc/init.d/xen
> seems to be enough for launching instances from horizon. I have
> updated the wiki page. Pl
Hi,
I have found myself a PSR-capable server and have been having a play
with Xen-4.5
At a first pass, I can get some numbers out:
[root@blob ~]# xl psr-cmt-attach 0
[root@blob ~]# xl psr-cmt-show cache_occupancy
Total RMID: 71
NameIDSocket 0
1: tighten page table owner checking in do_mmu_update()
2: don't ignore foreigndom input on various MMUEXT ops
3: HVM: don't crash guest upon problems occurring in user mode
Reason to request considering this for 4.5: Tightened argument
checking (as done in the first two patches) reduces the chanc
MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
a bad page table domain being specified.
Also pt_owner can't be NULL when reaching the "out" label, so the
respective check can be dropped.
Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
--- a/xen/arch/x86/mm.c
+++ b/xen/arch
Instead properly fail requests that shouldn't be issued on foreign
domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
operation to work that way.
In the course of doing this the need to always clear "okay" even when
wanting an error code other than -EINVAL became unwieldy, so the
resp
This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode") to further cases, including the
failed VM entry one that XSA-110 was needed to be issued for.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
On Thu, Nov 20, 2014 at 09:58:37AM +, Andrew Cooper wrote:
> Hi,
>
> I have found myself a PSR-capable server and have been having a play
> with Xen-4.5
>
> At a first pass, I can get some numbers out:
>
> [root@blob ~]# xl psr-cmt-attach 0
> [root@blob ~]# xl psr-cmt-show cache_occupancy
>
On 20/11/14 10:15, Chao Peng wrote:
> On Thu, Nov 20, 2014 at 09:58:37AM +, Andrew Cooper wrote:
>> Hi,
>>
>> I have found myself a PSR-capable server and have been having a play
>> with Xen-4.5
>>
>> At a first pass, I can get some numbers out:
>>
>> [root@blob ~]# xl psr-cmt-attach 0
>> [root
Have a second struct acpi_rmrr_unit pointer, starting out as NULL
and getting set to the current one when the callback returns a
positive value. Skip further iterations as long as both pointers
match.
Great!
int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
{
struct
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> 19 лист. 2014 20:32, користувач "Stefano Stabellini"
> написав:
> >
> > On Wed, 19 Nov 2014, Julien Grall wrote:
> > > On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > > > That's right, the maintenance interrupt handler is not called, but it
>
On 20/11/14 10:11, Jan Beulich wrote:
> MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
> a bad page table domain being specified.
>
> Also pt_owner can't be NULL when reaching the "out" label, so the
> respective check can be dropped.
Yes it can.
Failing
if ( (pg_owner =
On 20/11/14 10:29, Andrew Cooper wrote:
> On 20/11/14 10:11, Jan Beulich wrote:
>> MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
>> a bad page table domain being specified.
>>
>> Also pt_owner can't be NULL when reaching the "out" label, so the
>> respective check can be dropp
>>> On 19.11.14 at 23:21, wrote:
> @@ -97,13 +97,15 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci
> *pirq_dpci)
> }
>
> /*
> - * Reset the pirq_dpci->dom parameter to NULL.
> + * Cancels an outstanding pirq_dpci (if scheduled). Also if clear is set,
> + * reset pirq_dpci->dom paramete
On Thu, 20 Nov 2014, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 12, 2014 at 11:40:53AM +, Stefano Stabellini wrote:
> > > xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> > > handle as argument, not a physical address.
> >
On Thu, 20 Nov 2014, Russell King - ARM Linux wrote:
> On Tue, Nov 18, 2014 at 04:49:21PM +, Stefano Stabellini wrote:
> > ping?
>
> Sending something which wants my attention _To:_ me is always a good idea :)
I'll keep that in mind :-)
> The patch is fine in itself, but I have a niggle abo
On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 12, 2014 at 11:40:53AM +, Stefano Stabellini wrote:
> > xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
> > handle as argument, not a physical address.
>
> Ouch. Should this also go on stable tree?
Good idea
At 11:12 +0100 on 20 Nov (1416478351), Jan Beulich wrote:
> Instead properly fail requests that shouldn't be issued on foreign
> domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
> operation to work that way.
>
> In the course of doing this the need to always clear "okay" even when
>
UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more LR registers. The effect is a busy loop around the
interrupt handler in Xen
(http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
Signed-off-by: Stefano Stabellini
Reported-and-Tested-by: An
>>> On 19.11.14 at 23:21, wrote:
Leaving aside the question of whether this is the right approach, in
case it is a couple of comments:
> @@ -85,7 +91,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci
> *pirq_dpci)
> */
> bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci *pirq_dpci)
>
Hi Stefano,
On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everything get
On 11/20/2014 11:02 AM, Julien Grall wrote:
> Hi Stefano,
>
> On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
>> UIE being set can cause maintenance interrupts to occur when Xen writes
>> to one or more LR registers. The effect is a busy loop around the
>> interrupt handler in Xen
>> (http://mar
On 20/11/14 10:13, Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to further cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x
On Thu, 20 Nov 2014, Julien Grall wrote:
> Hi Stefano,
>
> On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
> > UIE being set can cause maintenance interrupts to occur when Xen writes
> > to one or more LR registers. The effect is a busy loop around the
> > interrupt handler in Xen
> > (http://ma
>>> On 20.11.14 at 12:06, wrote:
> On 20/11/14 10:13, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
>> static uint64_t osvw_length, osvw_status;
>> static DEFINE_SPINLOCK(osvw_lock);
>>
On 11/20/2014 10:28 AM, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> 19 лист. 2014 20:32, користувач "Stefano Stabellini"
>> написав:
>>>
>>> On Wed, 19 Nov 2014, Julien Grall wrote:
On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> That's right, the ma
>>> On 19.11.14 at 08:35, wrote:
> On Tue, Nov 18, Ian Jackson wrote:
>
>> How about
>>
>>It should be possible to repeatedly build identical sources
>>and get identical binaries, even on different hosts at different
>>build times. This fails [etc. etc. ...]
>>
>>Provide variab
Hi Ian,
On 11/19/2014 03:28 PM, Ian Campbell wrote:
> Signed-off-by: Ian Campbell
> ---
> v2: Remove pointless/unused baud rate setting.
>
> A bunch of other entries have these, but cleaning them up is out of scope
> here I think.
Agreed.
Reviewed-by: Julien Grall
Regards,
> ---
> xen/a
>>> On 19.11.14 at 17:02, wrote:
> On a Xen PV guest the DMA addresses and physical addresses are not 1:1
> (such as Xen PV guests) and the generic dma_get_required_mask() does
> not return the correct mask (since it uses max_pfn).
>
> Some device drivers (such as mptsas, mpt2sas) use
> dma_get_r
Hi Ian,
On 11/19/2014 03:28 PM, Ian Campbell wrote:
> EARLY_PRINTK_BAUD doesn't do anything unless EARLY_PRINTK_INIT_UART is set.
>
> Furthermore only the pl011 driver implements the init routine at all, so the
> entries which use 8250 and specified a BAUD were doubly wrong.
NIT: and exynos4210
Il 13/11/2014 13:22, Fabio Fantoni ha scritto:
Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
Il 08/07/2014 12:06, Fabio Fantoni ha scritto:
Il 08/07/2
Hi Ian,
On 11/19/2014 03:28 PM, Ian Campbell wrote:
> The callers pass the end as the pfn immediately *after* the last page to be
> mapped, therefore adding one is incorrect and causes an additional page to be
> mapped.
>
> At the same time correct the printing of the mfn values, zero-padding the
Hi Ian,
On 11/19/2014 03:28 PM, Ian Campbell wrote:
> Currently we only establish specific mappings for pcie0, which is
> used on the Mustang platform. However at least McDivitt uses pcie3.
> So wire up all the others, based on whether the corresponding DT node
> is marked as available.
>
> This
It should be possible to repeatedly build identical sources and get
identical binaries, even on different hosts at different build times.
This fails for xen.gz and xen.efi because current time and buildhost
get included in the binaries.
Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and XEN_BUIL
>>> On 19.11.14 at 20:46, wrote:
> @@ -237,6 +248,42 @@
> }
> }
>
> +static void __init parse_snb_timeout(const char *s)
> +{
> + int not;
> +
> + switch (*s) {
> +
> + case '\0':
> + snb_igd_timeout = SNB_IGD_TIMEOUT_LEGACY;
> + break;
> +
> + case
On Thu, 20 Nov 2014, Ian Campbell wrote:
> On Mon, 2014-11-17 at 13:00 +, Stefano Stabellini wrote:
> > On Mon, 17 Nov 2014, Ian Campbell wrote:
> > > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > > By the way, how many NICs can I apply to a VM?
> > > >
> > > > On xen-4.4.0, Using
On 19/11/14 17:51, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, David Vrabel wrote:
>>
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +unsigned long max_mfn;
>> +
>> +max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>
> As Jan pointed out, I think
On Thu, 2014-11-20 at 11:39 +, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 13:00 +, Stefano Stabellini wrote:
> > > On Mon, 17 Nov 2014, Ian Campbell wrote:
> > > > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > > > By the way,
On systems where DMA addresses and physical addresses are not 1:1
(such as Xen PV guests), the generic dma_get_required_mask() will not
return the correct mask (since it uses max_pfn).
Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow t
Use dma_ops->get_required_mask() if provided, defaulting to
dma_get_requried_mask_from_max_pfn().
This is needed on systems (such as Xen PV guests) where the DMA
address and the physical address are not equal.
ARCH_HAS_DMA_GET_REQUIRED_MASK is defined in asm/device.h instead of
asm/dma-mapping.h
A generic dma_get_required_mask() is useful even for architectures (such
as ia64) that define ARCH_HAS_GET_REQUIRED_MASK.
Signed-off-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
drivers/base/platform.c | 10 --
include/linux/dma-mapping.h |1 +
2 files changed, 9 inser
Signed-off-by: David Vrabel
Reviewed-by: Stefano Stabellini
Cc: Tony Luck
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
---
arch/ia64/include/asm/machvec.h |2 +-
arch/ia64/include/asm/machvec_init.h |1 -
arch/ia64/pci/pci.c | 20
3 files c
On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).
Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to
Lars Kurth writes ("[Xen-devel] [Vote] Confirm Konrad Rzeszutek Wilk as Xen
project Hypervisor Committer (please vote by Nov 30th)"):
> The voting form is at https://docs.google.com/forms/d/
> 1Hpoda2VjdMMGDsz1zh01tkHPR1vUsVeUVAR0DWhlgik/viewform but if you want to vote
> in public feel free to ju
At 16:26 + on 17 Nov (1416237976), Lars Kurth wrote:
> last week Ian Jackson nominated Konrad as Xen Project Hypervisor committer.
>
> Our governance process requires a formal vote by existing committers
> to confirm Konrad and for me to set up a voting form. Existing
> committers are: Keir Fr
At 11:13 +0100 on 20 Nov (1416478386), Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to further cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
>
> Signed-off-by: Jan Beulich
>>> On 20.11.14 at 12:34, wrote:
> At 11:13 +0100 on 20 Nov (1416478386), Jan Beulich wrote:
>> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
>> exit occurred in guest kernel mode") to further cases, including the
>> failed VM entry one that XSA-110 was needed to be issue
Make cr-daily-branch honour an environment or setting variable
EXTRA_SGR_ARGS. In branch-settings.linux-next set it appropriately to
arrange that the linux-next test reports consider linux-linus tests as
interesting as well as just linux-next ones.
(We already use a flight from linux-linus for se
flight 31688 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31688/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 31647
Tests whic
Xen Security Advisory XSA-113
Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling
*** EMBARGOED UNTIL 2014-11-27 12:00 UTC ***
ISSUE DESCRIPTION
=
An error handling path in the processing of MMU_MACHPHYS_UPDATE failed
to drop
On 20/11/14 10:23, Andrew Cooper wrote:
> On 20/11/14 10:15, Chao Peng wrote:
>> On Thu, Nov 20, 2014 at 09:58:37AM +, Andrew Cooper wrote:
>>> Hi,
>>>
>>> I have found myself a PSR-capable server and have been having a play
>>> with Xen-4.5
>>>
>>> At a first pass, I can get some numbers out:
This change can be ignored. Details below.
On Tue, 18 Nov 2014 10:26:31 -0500
Don Koch wrote:
> If we restore an xsave area from an older xen that has a larger
> size than the xcr0 bit call for, it is possible to have non-zero
> data in the unused area if an xsave has ever been done that used
>
>>> On 18.11.14 at 20:20, wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -540,6 +540,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> int i, j, e820_warn = 0, bytes = 0;
> bool_t acpi_boot_table_init_done = 0;
> struct domain *dom0;
> +struct a
> From: Tian, Kevin
> Sent: Thursday, November 20, 2014 4:51 PM
>
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Thursday, November 20, 2014 4:04 PM
> >
> > >>> On 20.11.14 at 08:45, wrote:
> > > Yang and I did some discussion here. We understand your point to
> > > avoid introducing
>>> On 20.11.14 at 15:35, wrote:
> On Tue, 18 Nov 2014 10:26:31 -0500
> Don Koch wrote:
>
>> If we restore an xsave area from an older xen that has a larger
>> size than the xcr0 bit call for, it is possible to have non-zero
>> data in the unused area if an xsave has ever been done that used
>>
>>> On 20.11.14 at 15:40, wrote:
>> From: Tian, Kevin
>> Sent: Thursday, November 20, 2014 4:51 PM
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: Thursday, November 20, 2014 4:04 PM
>> > >>> On 20.11.14 at 08:45, wrote:
>> > > Current option sounds a reasonable one, i.e. passing a
On Thu, 20 Nov 2014, Ian Campbell wrote:
> On Thu, 2014-11-20 at 11:39 +, Stefano Stabellini wrote:
> > On Thu, 20 Nov 2014, Ian Campbell wrote:
> > > On Mon, 2014-11-17 at 13:00 +, Stefano Stabellini wrote:
> > > > On Mon, 17 Nov 2014, Ian Campbell wrote:
> > > > > On Sat, 2014-11-15 at 10
On Thu, 2014-11-20 at 14:46 +, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Ian Campbell wrote:
> > There is, it's the romfile option to -device e.g.
> > -device $NICMODEL,vlan=0,romfile=$ROMFILE
> >
> > where NICMODEL is e100, rtl8139, virtio-blah
> > and ROMFILE is e.g.
create ^
title it qemu-upstream: limitation on 4 emulated NICs prevents guest from
starting unless PV override is used.
thanks
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi Jan,
On 11/20/2014 02:37 PM, Jan Beulich wrote:
On 18.11.14 at 20:20, wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -540,6 +540,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>> int i, j, e820_warn = 0, bytes = 0;
>> bool_t acpi_boot_table_
Processing commands for x...@bugs.xenproject.org:
> create ^
Created new bug #46 rooted at `<1416474814.29243.59.ca...@citrix.com>'
Title: `Re: [Xen-devel] Number of NICs per VM with qemu-upstream (Was: Re: Re:
[Xen-users] libvirt /usr/local/lib/xen/bin/qemu-dm did
not work on xen-4.4)'
> titl
For 'dom0_max_vcpus' and 'hvm_debug', markdown was interpreting the text as
regular text, and reflowing it as a regular paragraph, leading to a single
line as output. Reformat them as code blocks inside blockquote blocks, which
causes them to take their precise whitespace layout.
For 'psr', the b
On Wed, 2014-11-19 at 16:25 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 11:26:32AM +, Ian Jackson wrote:
> > Hi Konrad, I have another release ack request:
> >
> > Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully
> > updated"):
> > > Currently libxl__domain
On Tue, 2014-11-18 at 15:57 -0500, Zhigang Wang wrote:
> Before this patch, pv guest video_memkb is -1, which is an invalid value.
> And it will cause the xenstore 'memory/targe' calculation wrong:
>
> memory/target = info->target_memkb - info->video_memkb
>
> Signed-off-by: Zhigang Wang
Ac
On Wed, 2014-11-19 at 21:24 +, Wei Liu wrote:
> On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > > Before this patch, pv guest video_memkb is -1, which is an invalid value.
> > > And it will cause the xe
At 16:37 +0100 on 20 Nov (1416497837), Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to a few more cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
>
> Signed-off-by: Jan Beuli
On 20/11/14 15:37, Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to a few more cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
>
> Signed-off-by: Jan Beulich
Reviewed-by: And
This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode") to a few more cases, including the
failed VM entry one that XSA-110 was needed to be issued for.
Signed-off-by: Jan Beulich
---
v2: - s/crash_or_gp/crash_or_fault/
- drop changes to sv
On Mon, 2014-11-17 at 12:36 +, George Dunlap wrote:
> On 11/14/2014 11:12 AM, Ian Campbell wrote:
> > On Thu, 2014-11-13 at 19:04 +, George Dunlap wrote:
> >> Return proper error codes on failure so that scripts can tell whether
> >> the command completed properly or not.
> >>
> >> Also whi
On Thu, Nov 20, 2014 at 03:29:51PM +, Ian Campbell wrote:
> On Wed, 2014-11-19 at 21:24 +, Wei Liu wrote:
> > On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
> > > > Before this patch, pv guest video_
The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
is freed by xc_dom_release. However the various xc_try_*_decode routines (other
than the gzip one) just use plain malloc/realloc and therefore the buffer ends
up leaked.
The memory pool currently supports mmap'd buffers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/20/2014 03:47 PM, Ian Campbell wrote:
> On Mon, 2014-11-17 at 12:36 +, George Dunlap wrote:
>> On 11/14/2014 11:12 AM, Ian Campbell wrote:
>>> On Thu, 2014-11-13 at 19:04 +, George Dunlap wrote:
Return proper error codes on failure
On Thu, 20 Nov 2014, Julien Grall wrote:
> On 11/20/2014 11:02 AM, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
> >> UIE being set can cause maintenance interrupts to occur when Xen writes
> >> to one or more LR registers. The effect is a busy loop
On Thu, 2014-11-20 at 15:51 +, George Dunlap wrote:
> On 11/20/2014 03:47 PM, Ian Campbell wrote:
> > On Mon, 2014-11-17 at 12:36 +, George Dunlap wrote:
> >> On 11/14/2014 11:12 AM, Ian Campbell wrote:
> >>> On Thu, 2014-11-13 at 19:04 +, George Dunlap wrote:
> Return proper error
On Wed, 2014-11-19 at 14:45 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 10:10:58AM +, Ian Campbell wrote:
> > (CCing some more maintainers and the release manager)
> >
> > On Wed, 2014-11-12 at 15:43 +, Ian Campbell wrote:
> > > On Wed, 2014-11-12 at 09:38 -0600, Clark La
On Tue, 2014-11-18 at 13:19 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 18, 2014 at 05:44:20PM +, Ian Jackson wrote:
> > Euan Harris writes ("[PATCH] libxl: Document device parameter of
> > libxl_device__add functions"):
> > > The device parameter of libxl_device__add is an in/out parame
On Wed, 2014-11-19 at 06:11 -0500, Konrad Rzeszutek Wilk wrote:
> On November 19, 2014 6:05:33 AM EST, Andrew Cooper
> wrote:
> >On 19/11/14 11:04, Ian Campbell wrote:
> >> Signed-off-by: Ian Campbell
> >
> >Reviewed-by: Andrew Cooper
>
> Release-Acked-by: Konrad Rzeszutek Wilk (konrad.w...@or
On Wed, 2014-11-19 at 16:28 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 09:21:23PM +, Wei Liu wrote:
> > On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Nov 17, 2014 at 12:10:34PM +, Wei Liu wrote:
> > > > The existence check is to make
On Wed, 2014-11-19 at 16:27 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 03:27:48PM +, Ian Campbell wrote:
> > These patches:
> >
> > * fix up an off by one bug in the xgene mapping of additional PCI
> > bus resources, which would cause an additional extra page t
On Thu, 2014-11-20 at 15:22 +, Andrew Cooper wrote:
> For 'dom0_max_vcpus' and 'hvm_debug', markdown was interpreting the text as
> regular text, and reflowing it as a regular paragraph, leading to a single
> line as output. Reformat them as code blocks inside blockquote blocks, which
> causes
On Mon, 2014-11-17 at 15:19 +, Andrew Cooper wrote:
> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
> parse bootloader configuration files.
>
> c/s d1b93ea itself changed an an interface which previously used exclusively
> integers, to using strings in the case o
On Thu, Nov 20, 2014 at 03:48:47PM +, Ian Campbell wrote:
> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
> is freed by xc_dom_release. However the various xc_try_*_decode routines
> (other
> than the gzip one) just use plain malloc/realloc and therefore the buf
I think I'll debug this a bit later - unfortunately, now don't have
time for this. But I want to get rid of spurious interrupt here.
BTW - Stefano are you going to post the patch that we created
yesterday ? Will Ian accept it?
Regards,
Andrii
On Thu, Nov 20, 2014 at 1:15 PM, Julien Grall wrote:
On Wed, Nov 12, 2014 at 5:31 PM, George Dunlap
wrote:
> Return proper error codes on failure so that scripts can tell whether
> the command completed properly or not.
How about changing this to something like:
---
Return proper error codes on failure so that scripts can tell whether
the command
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/20/2014 03:56 PM, Ian Campbell wrote:
> On Thu, 2014-11-20 at 15:51 +, George Dunlap wrote:
>> On 11/20/2014 03:47 PM, Ian Campbell wrote:
>>> On Mon, 2014-11-17 at 12:36 +, George Dunlap wrote:
On 11/14/2014 11:12 AM, Ian Campbell
On Tue, 2014-11-18 at 20:03 +, Julien Grall wrote:
> By default, the script get_maintainer.pl will remove duplicates email as soon
> as it appends the list of maintainers of a new file, and therefore override
> the role of the developper.
>
> On complex patch (see [1]), this will result to omm
On 20/11/14 16:00, Ian Campbell wrote:
> On Mon, 2014-11-17 at 15:19 +, Andrew Cooper wrote:
>> c/s d1b93ea causes substantial functional regressions in pygrub's ability to
>> parse bootloader configuration files.
>>
>> c/s d1b93ea itself changed an an interface which previously used exclusivel
Hi Ian,
On 11/20/2014 04:08 PM, Ian Campbell wrote:
> On Tue, 2014-11-18 at 20:03 +, Julien Grall wrote:
>> By default, the script get_maintainer.pl will remove duplicates email as soon
>> as it appends the list of maintainers of a new file, and therefore override
>> the role of the developper
On Thu, 20 Nov 2014, Ian Campbell wrote:
> On Thu, 2014-11-20 at 14:46 +, Stefano Stabellini wrote:
> > On Thu, 20 Nov 2014, Ian Campbell wrote:
> > > There is, it's the romfile option to -device e.g.
> > > -device $NICMODEL,vlan=0,romfile=$ROMFILE
> > >
> > > where NICMODEL i
1 - 100 of 145 matches
Mail list logo
