>>> On 17.07.15 at 21:43, wrote:
> We are working on addressing review comments in this order (and you will see
> this pattern in our review responses):
>
> * Category 1 - Address review comments that affect ABI - these are of course
> required and will be addressed first.
>
> * Category 2 - A
On 07/17/2015 06:18 PM, Ian Jackson wrote:
Wei Liu writes ("Re: [Xen-devel] Request a freeze exception for COLO in v4.6"):
Ian and Ian, anything to add? What are your opinions?
I think COLO is an exciting and important feature.
Unfortunately I agree with Wei that at this stage taking both s
On 18/07/2015 13:07, osstest service owner wrote:
> flight 59681 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/59681/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemut-stubdom-deb
On 20/07/2015 02:28, Tian, Kevin wrote:
>> From: Ting-Wei Lan [mailto:lant...@gmail.com]
>> Sent: Saturday, July 18, 2015 3:06 AM
>>
>> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
>> devices, It is possible to encounter graphics issues that make screen
>> unreadable or
On Mon, Jul 20, 2015 at 09:18:48AM +0100, Andrew Cooper wrote:
> On 18/07/2015 13:07, osstest service owner wrote:
> > flight 59681 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/59681/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> >
On 19/07/2015 16:53, Julien Grall wrote:
> Hi,
>
> On 17/07/2015 20:05, Ting-Wei Lan wrote:
>> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
>> devices, It is possible to encounter graphics issues that make screen
>> unreadable or crash the system. It was reported in free
On 20/07/2015 09:24, Wei Liu wrote:
> On Mon, Jul 20, 2015 at 09:18:48AM +0100, Andrew Cooper wrote:
>> On 18/07/2015 13:07, osstest service owner wrote:
>>> flight 59681 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/59681/
>>>
>>> Regressions :-(
>>>
>>> Tests which
>>> On 17.07.15 at 21:05, wrote:
> @@ -87,6 +88,8 @@ static void __init parse_iommu_param(char *s)
> force_iommu = val;
> else if ( !strcmp(s, "workaround_bios_bug") )
> iommu_workaround_bios_bug = val;
> +else if ( !strcmp(s, "igfx_off") )
> +
On Sun, 2015-07-19 at 10:19 +, osstest service owner wrote:
> flight 59721 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/59721/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-q
flight 59759 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59759/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt3 host-install(3) broken REGR. vs. 58965
build-i386-rumpuserx
On Sat, Jul 18, 2015 at 11:25:48PM +, osstest service owner wrote:
> flight 59699 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/59699/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i3
>>> On 20.07.15 at 10:48, wrote:
> On Sun, 2015-07-19 at 10:19 +, osstest service owner wrote:
>> flight 59721 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/59721/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests whi
>>> On 19.07.15 at 11:33, wrote:
> blktap2 fails to build with gcc5 because it fails to recognize that
> there can be just one active connection (enforced in ctl_accept).
>
> Rearrange the code to handle just a single connection.
> Adjust two strerror calls to use errno instead -1 as input.
>
>
On Mon, Jul 20, Jan Beulich wrote:
> >>> On 19.07.15 at 11:33, wrote:
> > [ 198s] block-log.c:549:23: error: array subscript is above array bounds
> > [-Werror=array-bounds]
> > [ 198s] if (s->connections[i].id == id)
> > [ 198s]^
>
> So what makes the compiler r
In fact, right now, if the "vcpus=" list (where the
user specifies what vcpus should be part of a vnode)
has multiple elements, things don't work.
E.g., the following examples all result in failure
to create the guest:
[ "pnode=0","size=512","vcpus=0,2","vdistances=10,20" ]
[ "pnode=0","size=51
On Mon, Jul 20, 2015 at 6:01 AM, Xuehan Xu wrote:
> Hi, everyone.
>
> I don't quite follow the design philosophy of blktap. Since every virtual
> disk is backed by a tapdisk process, when there are hundreds of domU running
> and doing I/O operation simultaneously, which means that hundreds of tapd
Hello Konrad Rzeszutek Wilk,
The patch 7f9140626c75: "xen/mmu: Copy and revector the P2M tree."
from Jul 26, 2012, leads to the following static checker warning:
arch/x86/xen/mmu.c:1105 xen_cleanhighmap()
warn: potential pointer math issue ('level2_kernel_pgt' is pointer to
unsig
On Fri, Jul 17, 2015 at 05:51:17PM +0100, Andrew Cooper wrote:
> This is an aid to debugging
>
> Signed-off-by: Andrew Cooper
> CC: Ian Campbell
> CC: Ian Jackson
> CC: Wei Liu
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
h
On Fri, Jul 17, 2015 at 05:51:14PM +0100, Andrew Cooper wrote:
> And three improvements to debugging.
>
> Note that there is still a bug in libxl__toolstack_save() which
> valgrind identified, but I do not wish to block this bugfix on that
>
> Andrew Cooper (4):
> tools/libxc: Identify the path
On Fri, Jul 17, 2015 at 06:00:48PM +0100, Ian Jackson wrote:
> This limit of 11 has been in this function since it was written, but
> serves no purpose. The extra arguments are fed one by one to
> parse_nic_config, and it is possible to have as many as you like.
>
> Signed-off-by: Ian Jackson
A
On Fri, Jul 17, 2015 at 06:00:51PM +0100, Ian Jackson wrote:
> This ended with a literal sentinel. Use COMMON_LONG_OPTIONS (which
> mentions --help) instead.
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists
On Fri, Jul 17, 2015 at 05:51:16PM +0100, Andrew Cooper wrote:
> This is a substantial aid to debugging
>
> Signed-off-by: Andrew Cooper
> CC: Ian Campbell
> CC: Ian Jackson
> CC: Wei Liu
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@list
On Mon, Jul 20, 2015 at 11:16:34AM +0200, Olaf Hering wrote:
> On Mon, Jul 20, Jan Beulich wrote:
>
> > >>> On 19.07.15 at 11:33, wrote:
> > > [ 198s] block-log.c:549:23: error: array subscript is above array bounds
> > > [-Werror=array-bounds]
> > > [ 198s] if (s->connections[i].id == id
On Fri, Jul 17, 2015 at 06:00:49PM +0100, Ian Jackson wrote:
> xl subcommands ought all to take -h. def_getopt and hence
> SWITCH_FOREACH_OPT already handles 'h' by calling helpstr. None of
> the call sites see the 'h'.
>
> In this patch:
>
> * Change SWITCH_FOREACH_OPT to always add a "h" to
>>> On 20.07.15 at 11:16, wrote:
> On Mon, Jul 20, Jan Beulich wrote:
>
>> >>> On 19.07.15 at 11:33, wrote:
>> > [ 198s] block-log.c:549:23: error: array subscript is above array bounds
> [-Werror=array-bounds]
>> > [ 198s] if (s->connections[i].id == id)
>> > [ 198s]
On 20/07/15 10:56, Wei Liu wrote:
> On Fri, Jul 17, 2015 at 05:51:14PM +0100, Andrew Cooper wrote:
>> And three improvements to debugging.
>>
>> Note that there is still a bug in libxl__toolstack_save() which
>> valgrind identified, but I do not wish to block this bugfix on that
>>
>> Andrew Cooper
On 10/07/15 15:42, Juergen Gross wrote:
> When dom0 is being ballooned balloon_process() will hold the balloon
> mutex until it is finished. This will block e.g. creation of new
> domains as the device backends for the new domain need some
> autoballooned pages for the ring buffers.
>
> Avoid this
On 20/07/15 09:27, Andrew Cooper wrote:
> On 19/07/2015 16:53, Julien Grall wrote:
>> Hi,
>>
>> On 17/07/2015 20:05, Ting-Wei Lan wrote:
>>> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
>>> devices, It is possible to encounter graphics issues that make screen
>>> unreada
On Mon, 20 Jul 2015, Jan Beulich wrote:
> >>> On 19.07.15 at 11:33, wrote:
> > blktap2 fails to build with gcc5 because it fails to recognize that
> > there can be just one active connection (enforced in ctl_accept).
> >
> > Rearrange the code to handle just a single connection.
> > Adjust two
On Mon, Jul 20, 2015 at 7:16 AM, Tiejun Chen wrote:
> v10:
>
> * Patch #6: hvmloader/pci: Try to avoid placing BARs in RMRRs
> This is from George' draft patch which implements an acceptable
> solution in current cycle. Here I just implemented check_overlap_all() and
> some cleanups.
>
> * P
All handling of device model files is now at the libxl level. Remove
XC_DEVICE_MODEL_RESTORE_FILE and introduce LIBXL_DEVICE_MODEL_RESTORE_FILE in
its place.
Signed-off-by: Andrew Cooper
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/include/xenguest.h |8
tools/l
Add further instructions to the libxc "Future Extensions" section, and
provide such a section for libxl.
In addition, drop the "In experimental __func__" IPRINTF()s from the
libxc implementations.
Finally, a correction to libxl's "Not Yet Included" section which
should have been amended in c/s 7e
As there is now only the one implementation.
Signed-off-by: Andrew Cooper
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/include/xenguest.h | 14 --
tools/libxc/xc_nomigrate.c | 20
tools/libxc/xc_sr_restore.c | 14 +++---
All of these are UNUSED_VALUE defects where a default vaule is
unconditionally overwritten. They are not particularly interesting,
bug wise, but keeping these defects at bay helps prevent real bugs
going unnoticed in the volume.
No functional change.
Signed-off-by: Andrew Cooper
CC: Ian Campbel
This series is some cleanup following the integration of migration v2
into the codebase. It removes the legacy migration implementation
(compatability is provided with the python conversion script), and
adjusts the migration v2 docs/implementation to no longer be
experimental.
There are no major
Update the libxc spec to indicate more sternly that TOOLSTACK records
should no longer be used.
Also, trim further toolstack infrastructure which should have gone in
c/s 39bf4e9 "tools/libxl: Drop all knowledge of toolstack callbacks"
Signed-off-by: Andrew Cooper
CC: Ian Campbell
CC: Ian Jackso
於 一，2015-07-20 於 09:21 +0100，Andrew Cooper 提到：
> On 20/07/2015 02:28, Tian, Kevin wrote:
> > > From: Ting-Wei Lan [mailto:lant...@gmail.com]
> > > Sent: Saturday, July 18, 2015 3:06 AM
> > >
> > > When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel
> > > Ironlake
> > > devices, It is
On 07/20/2015 12:15 PM, David Vrabel wrote:
On 10/07/15 15:42, Juergen Gross wrote:
When dom0 is being ballooned balloon_process() will hold the balloon
mutex until it is finished. This will block e.g. creation of new
domains as the device backends for the new domain need some
autoballooned page
On Mon, Jul 20, 2015 at 7:16 AM, Tiejun Chen wrote:
> Try to avoid placing PCI BARs over RMRRs:
>
> - If mmio_hole_size is not specified, and the existing MMIO range has
> RMRRs in it, and there is space to expand the hole in lowmem without
> moving more memory, then make the MMIO hole as larg
El 07/07/15 a les 17.48, Wei Liu ha escrit:
> This node is used by toolstack (libxl, hotplug script) and blkback.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Roger Pau Monne
> Cc: David Vrabel
> Cc: Konrad Rzeszutek Wilk
> Cc: George Dunlap
>
> I notice this
>>> On 20.07.15 at 08:16, wrote:
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -38,6 +38,43 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
> enum virtual_vga virtual_vga = VGA_none;
> unsigned long igd_opregion_pgbase = 0;
>
> +/* Check if any confli
On Wed, 15 Jul 2015, Fabio Fantoni wrote:
> On production system using xen 4.5 I had occasional qemu crash using spice,
> from qemu log:
> > qemu-system-i386: spice-qemu-char.c:173: spice_chr_add_watch: Assertion
> > `cond == G_IO_OUT' failed.
> It was solved upstream with this patch:
> http://git.
On 07/17/2015 03:35 PM, Dario Faggioli wrote:
The function is called both when we want to remove a cpu
from a cpupool, and during cpu teardown, for suspend or
shutdown. If, however, the boot cpu (cpu 0, most of the
times) is not present in the default cpupool, during
suspend or shutdown, Xen cras
When dom0 is being ballooned balloon_process() will hold the balloon
mutex until it is finished. This will block e.g. creation of new
domains as the device backends for the new domain need some
autoballooned pages for the ring buffers.
Avoid this by releasing the balloon mutex from time to time du
Please ignore, forgot stg refresh...
Juergen
On 07/20/2015 01:46 PM, Juergen Gross wrote:
When dom0 is being ballooned balloon_process() will hold the balloon
mutex until it is finished. This will block e.g. creation of new
domains as the device backends for the new domain need some
autoballoon
When dom0 is being ballooned balloon_process() will hold the balloon
mutex until it is finished. This will block e.g. creation of new
domains as the device backends for the new domain need some
autoballooned pages for the ring buffers.
Avoid this by releasing the balloon mutex from time to time du
On Sat, 2015-07-18 at 11:13 +0100, Julien Grall wrote:
> Hi Ian,
>
> On 15/07/2015 10:32, Ian Campbell wrote:
> >> and save 2 byte if not more with the alignment per irq_desc.
> >
> > If this is a concern then I would say we would either want a separate
> > array of per-pLPI information which we d
>>> On 20.07.15 at 08:16, wrote:
> +/* If there was no highmem region, just create one. */
> +if ( i == memory_map.nr_map )
> +{
> +memory_map.map[i].addr = ((uint64_t)1 << 32);
> +memory_map.map[i].size = add_high_mem;
> +memory_map.map[
On Mon, 2015-07-20 at 13:41 +0200, Juergen Gross wrote:
> On 07/17/2015 03:35 PM, Dario Faggioli wrote:
> > @@ -644,25 +673,66 @@ int cpu_disable_scheduler(unsigned int cpu)
> > cpumask_setall(v->cpu_hard_affinity);
> > }
> >
> > -if ( v->processor == cp
On 07/20/2015 01:59 PM, Dario Faggioli wrote:
On Mon, 2015-07-20 at 13:41 +0200, Juergen Gross wrote:
On 07/17/2015 03:35 PM, Dario Faggioli wrote:
@@ -644,25 +673,66 @@ int cpu_disable_scheduler(unsigned int cpu)
cpumask_setall(v->cpu_hard_affinity);
}
-
On 17/07/15 20:05, Ting-Wei Lan wrote:
> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
> devices, It is possible to encounter graphics issues that make screen
> unreadable or crash the system. It was reported in freedesktop bugzilla:
>
> https://bugs.freedesktop.org/show_
On 17/07/15 05:51, Juergen Gross wrote:
> Support 64 bit pv-domains with more than 512GB of memory.
>
> Following test have been done:
> - 64 bit dom0 on 8GB machine
> - 64 bit dom0 on 1TB machine (resolving p2m/E820-map conflict)
> - 32 bit dom0 on 8GB machine
> - 64 bit dom0 on 8GB machine with
On Sat, 2015-07-18 at 11:13 +0100, Julien Grall wrote:
> Hi Ian,
>
> On 15/07/2015 10:32, Ian Campbell wrote:
> >> and save 2 byte if not more with the alignment per irq_desc.
> >
> > If this is a concern then I would say we would either want a separate
> > array of per-pLPI information which we d
On Mon, 2015-07-20 at 09:48 +0100, Ian Campbell wrote:
> > version targeted for testing:
> > xen 21d9b079e53805b68047d60d28cde224d09bbb40
> > baseline version:
> > xen c40317f11b3f05e7c06a2213560c8471081f2662
Based on feedback from Wei and Jan I've now gone ahea
>>> On 20.07.15 at 14:12, wrote:
> On 17/07/15 20:05, Ting-Wei Lan wrote:
>> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
>> devices, It is possible to encounter graphics issues that make screen
>> unreadable or crash the system. It was reported in freedesktop bugzilla:
Hi Chris,
On 17/07/15 21:48, Chris (Christopher) Brand wrote:
> nr_mods is set in add_boot_module() to the number of module
> array elements used. This function also ensures that nr_mods
> never exceeds MAX_MODULES (the size of the array). When looping
> through the array, the correct maximum inde
On 20/07/15 13:24, Jan Beulich wrote:
On 20.07.15 at 14:12, wrote:
>> On 17/07/15 20:05, Ting-Wei Lan wrote:
>>> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
>>> devices, It is possible to encounter graphics issues that make screen
>>> unreadable or crash the syste
One brief request -- if you do end up sending this series again, can
you please rebase to staging? This is the second time I've had to
manually fix up some patches so that they apply.
Sorry for this inconvenience.
Thanks
Tiejun
___
Xen-devel mailin
On 07/20/2015 12:30 PM, Jan Beulich wrote:
On 20.07.15 at 08:16, wrote:
>> --- a/tools/firmware/hvmloader/pci.c
>> +++ b/tools/firmware/hvmloader/pci.c
>> @@ -38,6 +38,43 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>> enum virtual_vga virtual_vga = VGA_none;
>> unsigned long igd_o
On Thu, 9 Jul 2015, Ian Campbell wrote:
> On Mon, 2015-06-22 at 16:16 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini
>
> In general I'm very suspicious of a 200 line patch with _no_ commit
> message at all.
>
> What about the details of the stuff around overriding the ver
On Mon, Jul 20, 2015 at 7:16 AM, Tiejun Chen wrote:
> Now use the hypervisor-supplied memory map to build our final e820 table:
> * Add regions for BIOS ranges and other special mappings not in the
> hypervisor map
> * Add in the hypervisor supplied regions
> * Adjust the lowmem and highmem regi
Hi Ian,
On Fri, Jul 10, 2015 at 9:00 PM, Ian Campbell wrote:
> On Fri, 2015-07-10 at 13:12 +0530, vijay.kil...@gmail.com wrote:
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 3ebadcf..92d2be9 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -68,11 +68,18 @@ e
On 20/07/15 12:49, Juergen Gross wrote:
> When dom0 is being ballooned balloon_process() will hold the balloon
> mutex until it is finished. This will block e.g. creation of new
> domains as the device backends for the new domain need some
> autoballooned pages for the ring buffers.
>
> Avoid this
Ian -- various questions for you here.
On Mon, 2015-07-20 at 13:56 +0100, Stefano Stabellini wrote:
> On Thu, 9 Jul 2015, Ian Campbell wrote:
> > On Mon, 2015-06-22 at 16:16 +0100, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini
> > [...]
>
> I didn't do a good job with the com
v10:
* Instead of correcting e820, I'd like to correct memory_map.map[]
and then copy them into e820 directly. I think this can make sure
hvm_info, memory_map.map[] and e820 are on the same page.
Actually, now that you mention it -- this should probably happen
instead when we update hvm_i
On 20/07/15 14:07, Vijay Kilari wrote:
> AUI, you are refering to
>
> http://xenbits.xen.org/people/ianc/vits/draftG.html#virtual-lpi-injection
>
> If we want to extract, its_device, and VITT information before calling
> vgic_vcpu_inject_lpi(),
> it cannot be done in do_IRQ() as irq.c cannot hav
On 16/07/15 20:34, Colin King wrote:
> From: Colin Ian King
>
> xen_has_pv_devices has no parameters, so use the normal void
> parameter convention to make it match the prototype in the
> header file include/xen/platform_pci.h
Applied to for-linus-4.3, thanks.
David
___
Tiejun Chen writes ("[v10][PATCH 11/16] tools/libxl: detect and avoid conflicts
with RDM"):
> While building a VM, HVM domain builder provides struct hvm_info_table{}
> to help hvmloader. Currently it includes two fields to construct guest
> e820 table by hvmloader, low_mem_pgend and high_mem_pgen
Tiejun Chen writes ("[v10][PATCH 13/16] libxl: construct e820 map with RDM
information for HVM guest"):
> Here we'll construct a basic guest e820 table via
> XENMEM_set_memory_map. This table includes lowmem, highmem
> and RDMs if they exist, and hvmloader would need this info
> later.
>
> Note t
On 15/07/15 10:52, Konstantin Khlebnikov wrote:
> This code is used only when CONFIG_PREEMPT=n and only in non-atomic context:
> xen_in_preemptible_hcall is set only in privcmd_ioctl_hypercall().
> Thus preempt_count is zero and should_resched() is equal to need_resched().
Applied to for-linus-4.3
On Thu, 9 Jul 2015, Ian Campbell wrote:
> On Mon, 2015-06-22 at 16:16 +0100, Stefano Stabellini wrote:
> > Determine the most recent raisin revision that needs to be tested, by
> > comparing
> > with the already tested xen-tested-master branch. Push to
> > raisin.git:xen-tested-master when the bu
On 17/07/15 16:38, Jan Beulich wrote:
On 17.07.15 at 17:19, wrote:
>> On 17/07/15 15:20, Jan Beulich wrote:
>>> If not, then method 2 would seem quite a bit less troublesome than
>>> method 1, yet method 3 would (even if more involved in terms of
>>> changes to be done) perhaps result in the
Tiejun Chen writes ("[v10][PATCH 16/16] tools: parse to enable new rdm policy
parameters"):
> This patch parses to enable user configurable parameters to specify
> RDM resource and according policies which are defined previously,
>
> Global RDM parameter:
> rdm = "strategy=host,policy=strict/
On Mon, Jul 20, 2015 at 12:11:35PM +0800, Arvin Wang wrote:
> hi,all
>
> I adjusted time back to year 1900 in windows guest vm. And when i
> rebooted the vm, it failed.
>
> It seems that the value of adjustment exceed the range. Any suggestions?
You are using Xend which is deprecated and no
On Mon, 2015-07-20 at 14:41 +0100, Stefano Stabellini wrote:
> On Thu, 9 Jul 2015, Ian Campbell wrote:
> > On Mon, 2015-06-22 at 16:16 +0100, Stefano Stabellini wrote:
> > > Determine the most recent raisin revision that needs to be tested, by
> > > comparing
> > > with the already tested xen-test
On Mon, Jul 20, 2015 at 2:23 PM, Chen, Tiejun wrote:
>>> v10:
>>>
>>> * Instead of correcting e820, I'd like to correct memory_map.map[]
>>>and then copy them into e820 directly. I think this can make sure
>>>hvm_info, memory_map.map[] and e820 are on the same page.
>>
>>
>> Actually, now
>>> On 20.07.15 at 14:34, wrote:
> On 20/07/15 13:24, Jan Beulich wrote:
> On 20.07.15 at 14:12, wrote:
>>> On 17/07/15 20:05, Ting-Wei Lan wrote:
When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
devices, It is possible to encounter graphics issues that make
Ian Campbell writes ("Re: [PATCH v7 1/2] OSSTEST: introduce a raisin build
test"):
> Unfortunately ts-xen-build-prep will not have access to the repo, since
> it won't be cloned. Also when reusing a host (which happens for builds)
> I think this step is skipped (Ian J: can you confirm or deny that
Actually, now that you mention it -- this should probably happen
instead when we update hvm_info->{low,high}_mem_pgend.
I also considered this point previously but I thought just right now we only
update hvm_info->low/high_mem_pgend inside pci_setup(). But you can't
guarantee this would be a so
Hi Ian,
On 07/07/15 16:19, Ian Campbell wrote:
> On Tue, 2015-07-07 at 13:20 +0100, Julien Grall wrote:
>> Hi Ian,
>>
>> On 25/06/15 12:23, Ian Campbell wrote:
>>> On Thu, 2015-06-25 at 11:21 +0100, Wei Liu wrote:
On Mon, May 11, 2015 at 12:55:34PM +0100, Julien Grall wrote:
> Hi all,
>>>
>>> On 20.07.15 at 15:43, wrote:
> On 17/07/15 16:38, Jan Beulich wrote:
> On 17.07.15 at 17:19, wrote:
>>> On 17/07/15 15:20, Jan Beulich wrote:
If not, then method 2 would seem quite a bit less troublesome than
method 1, yet method 3 would (even if more involved in terms of
c
For clarity:
I am not acking this patch, primarily because I am not happy with the
code in xlu_rdm_parse which is (a) the result of repeated
clone-and-hack and (b) consists of ad-hoc string pointer fiddling.
Yes, I knew you mentioned this previously but I also remember our last
deal was someth
Hi all,
I have been travelling on Friday and wanted to appeal for calm on this
particular issue. Let's try and focus on making as much progress as we can on
the patch series which have freeze exceptions (or partial freeze exception)
this week. Continuing a debate on what may have gone wrong wit
+/* Find the lowest RMRR higher than base. */
+static int find_next_rmrr(uint32_t base)
+{
+unsigned int i;
+int next_rmrr = -1;
+uint64_t min_base = (1ull << 32);
+
+for ( i = 0; i < memory_map.nr_map ; i++ )
+{
+if ( memory_map.map[i].type == E820_RESERVED &&
+
On Mon, 2015-07-20 at 14:57 +0100, Julien Grall wrote:
> Hi Ian,
This is a tools backport, so needs to be Ian J not me.
> On 07/07/15 16:19, Ian Campbell wrote:
> > On Tue, 2015-07-07 at 13:20 +0100, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 25/06/15 12:23, Ian Campbell wrote:
> >>> On Thu, 2
On Fri, 2015-07-17 at 14:17 -0400, Boris Ostrovsky wrote:
> On 07/17/2015 03:27 AM, Dario Faggioli wrote:
> > In the meanwhile, what should we do? Document this? How? "don't use
> > vNUMA with PV guest in SMT enabled systems" seems a bit harsh... Is
> > there a workaround we can put in place/sugge
On 20/07/15 14:58, Jan Beulich wrote:
On 20.07.15 at 15:43, wrote:
On 17/07/15 16:38, Jan Beulich wrote:
On 17.07.15 at 17:19, wrote:
On 17/07/15 15:20, Jan Beulich wrote:
If not, then method 2 would seem quite a bit less troublesome than
method 1, yet method 3 would (even if more involve
On 07/20/2015 03:06 PM, Chen, Tiejun wrote:
+/* Find the lowest RMRR higher than base. */
+static int find_next_rmrr(uint32_t base)
+{
+unsigned int i;
+int next_rmrr = -1;
+uint64_t min_base = (1ull << 32);
+
+for ( i = 0; i < memory_map.nr_m
On Fri, Jul 17, 2015 at 05:04:03PM +0100, Ian Campbell wrote:
> On Thu, 2015-07-16 at 12:18 +0100, Anthony PERARD wrote:
> > +cd $builddir/devstack
> > +>local.conf
> > +echo >>local.conf '[[local|localrc]]'
> > +echo >>local.conf ADMIN_PASSWORD=`pwgen 20 1`
> > +echo >>local.co
On 20/07/15 14:55, Jan Beulich wrote:
On 20.07.15 at 14:34, wrote:
>> On 20/07/15 13:24, Jan Beulich wrote:
>> On 20.07.15 at 14:12, wrote:
On 17/07/15 20:05, Ting-Wei Lan wrote:
> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
> devices, It is poss
RFCs dropped (with some debugging code removed). Everything
except for patch 7 has been submitted before.
1: PCI: add config space write abstract intercept logic
2: MSI-X: track host and guest mask-all requests separately
3: MSI-X: be more careful during teardown
4: MSI-X: access MSI-X table only
On Fri, Jul 17, 2015 at 05:10:18PM +0100, Ian Campbell wrote:
> On Thu, 2015-07-16 at 12:18 +0100, Anthony PERARD wrote:
>
> > +sub deploy() {
> > + # This clone many repos and may take sometime until the GitProxyCache is
> > + # filled
>
> Can we find those repos and therefore record the versi
>>> On 20.07.15 at 16:10, wrote:
> Hmm... although I suppose that doesn't catch the possibility of a memory
> range crossing the 4G boundary.
I think we can safely ignore that - both real and virtual hardware have
special regions right below 4Gb, so neither RAM not RMRRs can be
reasonably placed
El 16/07/15 a les 18.58, Ian Campbell ha escrit:
> The removal of the udev rules highlighted that although it has been
> replaced by "xl devd" there isn't an initscript to replace it.
>
> To enable this add a --pidfile option to xl devd.
>
> Tested on Linux by running the script in dom0 and check
This is to be used by MSI code, and later to also be hooked up to
MMCFG accesses by Dom0.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1108,6 +1108,12 @@ void pci_cleanup_msi(struct pci_dev *pde
msi_free_irqs(pdev);
}
+int p
On 13/07/15 10:55, Bob Liu wrote:
> Note: This patch is based on original work of Arianna's internship for
> GNOME's Outreach Program for Women.
>
> Only one hardware queue is used now, so there is no performance change.
>
> The legacy non-mq code is deleted completely which is the same as other
Host uses of the bits will be added subsequently, and must not be
overridden by guests (including Dom0, namely when acting on behalf of
a guest).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -843,6 +843,12 @@ static int msix_capabili
When a device gets detached from a guest, pciback will clear its
command register, thus disabling both memory and I/O decoding. The
disabled memory decoding, however, has an effect on the MSI-X table
accesses the hypervisor does: These won't have the intended effect
anymore. Even worse, for PCIe de
As done in Linux by f598282f51 ("PCI: Fix the NIU MSI-X problem in a
better way") and its broken predecessor, make sure we don't access the
MSI-X table without having enabled MSI-X first, using the mask-all flag
instead to prevent interrupts from occurring.
Signed-off-by: Jan Beulich
Reviewed-by:
... by monitoring writes to the mask register.
This allows reverting the main effect of the XSA-129 patches in qemu.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1303,6 +1303,37 @@ int pci_msi_conf_write_intercept(struct
return 1;
}
+entr
1 - 100 of 212 matches
Mail list logo
