flight 44363 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44363/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-pvops 3 host-install(3) broken like 44342
build-armhf
Commit 4d27280572 ("x86/xsaves: fix overwriting between non-lazy/lazy
xsaves") switched to always saving full state when using compacted
format (which is the only one XSAVES allows). It didn't, however, also
adjust the restore side: In order to save full state, we also need to
make sure we always l
>>> On 22.04.16 at 18:08, wrote:
> On 22/04/16 15:17, Jan Beulich wrote:
>> As both INVLPG and INVLPGA have basically the same exception rules
>> (leaving aside that INVLPGA requires SVME enabled, which so far isn't
>> being taken care of,
>
> We also don't appear to handle the ASID in %ecx corre
Hi all.
Is there anybody to give me an answer?
Thanks.
From: tutu sky
Sent: Friday, April 22, 2016 8:22 AM
To: Xen-devel@lists.xen.org
Subject: running a task (thread) directly on hardware
Hi,
In linux kernel we can use affinity settings to ask sched
>>> On 22.04.16 at 19:35, wrote:
> Jan Beulich writes ("[PATCH] MAINTAINERS: ARM docs to be maintained by ARM
> maintainers"):
>> I've been getting increasingly annoyed by people not applying common
>> sense to these docs updates.
>>
>> Signed-off-by: Jan Beulich
>
> I have queued this for com
>>> On 22.04.16 at 20:03, wrote:
> On 04/22/2016 02:47 AM, tip-bot for Jan Beulich wrote:
>> Commit-ID: 103f6112f253017d7062cd74d17f4a514ed4485c
>> Gitweb:
> http://git.kernel.org/tip/103f6112f253017d7062cd74d17f4a514ed4485c
>> Author: Jan Beulich
>> AuthorDate: Thu, 21 Apr 2016 00:27:
On Mon, 25 Apr 2016, Jan Beulich wrote:
> >>> On 22.04.16 at 20:03, wrote:
> >> +#define hugepages_supported() cpu_has_pse
> >>
> >
> > Please don't use the cpu_has_* macros anymore, they are going away soon.
> >
> > In this case it should be static_cpu_has(X86_FEATURE_PSE).
>
> I can certain
>>> On 22.04.16 at 19:26, wrote:
>> >+/* Defines an outstanding patching action. */
>> >+struct xsplice_work
>> >+{
>> >+atomic_t semaphore; /* Used for rendezvous. */
>> >+atomic_t irq_semaphore; /* Used to signal all IRQs disabled. */
>>
>> Why do you, btw, need two of the
>>> On 24.04.16 at 23:41, wrote:
> I spoke over the weekend with Dan Jacobowitz (who in the past worked
> on binutils) who mentioned that ELF visibility is what one should
> pay attention to. And that we shouldn't need to look at LOCAL symbols
> at all if we are resolving between objects.
Well,
>>> On 25.04.16 at 08:41, wrote:
> On 04/22/2016 10:10 PM, Konrad Rzeszutek Wilk wrote:
>>> As per my earlier reply to Konrad, there must be more to this. I.e.
>>> "normal" local symbols won't get dropped together with relocations
>>> referencing them getting resolved.
>>
>> Correct. These .LCx sy
Hi Julien,
On 23 April 2016 at 02:29, Julien Grall wrote:
> Hi Wei,
>
>
> On 21/04/16 09:24, Wei Chen wrote:
>
>> This patch adds v2m extension support in GIC-v2 driver. The GICv2 driver
>> detects the MSI frames from device tree and creates corresponding device
>> tree nodes in Domain0's DTB. I
>>> On 22.04.16 at 17:21, wrote:
> Here is what I came up using your idea. Do you want me to add 'Suggested-by'
> Jan on it?
I'll leave that up to you; it was really just a vague idea that I gave...
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -74,6 +74,9 @@ efi-y := $(shell
> >> >>> On 30.03.16 at 09:28, wrote:
> >> > 2016-03-29 18:39 GMT+08:00 Jan Beulich :
> >> >> ---
> >> >> I assume this also addresses the issue which
> >> >>
> >> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03189.
> >> html
> >> >> attempted to deal with in a not really accepta
Hi Julien, Stefano
I met an issue when passthrough a device to DomU, and have no clear idea what's
wrong.
"
(XEN) smmu: /iommu@5c80: Unhandled context fault: iova=0x42188000,
fsynr=0x433, cb=0
(XEN) smmu: /iommu@5c80: Unhandled context fault: iova=0x42188020,
fsynr=0x433, cb=0
"
fsynr i
On April 25, 2016 4:41pm, Li, Liang Z wrote:
> > >> >>> On 30.03.16 at 09:28, wrote:
> > >> > 2016-03-29 18:39 GMT+08:00 Jan Beulich :
> > >> >> ---
> > >> >> I assume this also addresses the issue which
> > >> >>
> > >> http://lists.xenproject.org/archives/html/xen-devel/2016-
> 01/msg03189.
> >
Hi Julien,
On 20.04.2016 15:26, Julien Grall wrote:
Hello Dirk,
On 19/04/16 06:59, Dirk Behme wrote:
In some mailing list discussion
http://lists.xen.org/archives/html/xen-devel/2016-04/msg00214.html
some details about the interrupt handling of Xen were given.
Add that so it's not forgotten.
>>> On 25.04.16 at 07:35, wrote:
> flight 92645 xen-4.3-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/92645/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386-pvops
>>> On 22.04.16 at 20:06, wrote:
> On Wed, Apr 20, 2016 at 02:18:48PM +0100, Ross Lagerwall wrote:
>> On 04/13/2016 10:09 PM, Konrad Rzeszutek Wilk wrote:
>> snip
>> >+static int xsplice_action(xen_sysctl_xsplice_action_t *action)
>> >+{
>> >+struct payload *data;
>> >+char n[XEN_XSPLICE_N
On 04/25/2016 10:03 AM, Jan Beulich wrote:
On 22.04.16 at 20:06, wrote:
On Wed, Apr 20, 2016 at 02:18:48PM +0100, Ross Lagerwall wrote:
On 04/13/2016 10:09 PM, Konrad Rzeszutek Wilk wrote:
snip
+static int xsplice_action(xen_sysctl_xsplice_action_t *action)
+{
+struct payload *data;
+
>>> On 18.04.16 at 16:00, wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -558,14 +558,16 @@ static void iommu_flush_all(void)
> }
> }
>
> -static void __intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> -int dma_old_
>>> On 18.04.16 at 16:00, wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -243,21 +243,33 @@ int iommu_map_page(struct domain *d, unsigned long gfn,
> unsigned long mfn,
> unsigned int flags)
> {
> struct hvm_iommu *hd = domain
flight 92652 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92652/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
On Fri, Apr 22, 2016 at 8:01 PM, Fabrice Delente wrote:
> Hello,
>
> This command allowed me to vnc into any virtual machine from anywhere
> on my network.
>
> This doesn't work anymore, I can only vnc into a VM if I am on the
> server itself: being on the server, 'vncviewer 127.0.0.1:5905' works,
This patch adds v2m extension support in GIC-v2 driver. The GICv2 driver
detects the MSI frames from device tree and creates corresponding device
tree nodes in Domain0's DTB. It also provides one hw_ops callback to map
v2m MMIO regions to domain0 and route v2m SPIs to domain0.
With this GICv2m ext
Hi Ian,
On 22/04/16 18:29, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH v2] docs/arm64: update the documention for loading
XSM support"):
The new version looks good to me:
Acked-by: Julien Grall
Can a native speaker (Ian, Konrad, George) double-check the wording)?
I found it rather
Hello Wei,
could you please send email replies in plain text (rather than html)?
Thanks,
Stefano
On Mon, 25 Apr 2016, Wei Chen wrote:
> Hi Julien,
>
> On 23 April 2016 at 02:29, Julien Grall wrote:
> Hi Wei,
>
> On 21/04/16 09:24, Wei Chen wrote:
> This patch adds v2m
>>> On 18.04.16 at 16:00, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info *page,
> unsigned long type,
> int preemptible)
> {
> unsigned long nx, x, y = page->u.inuse.type_info;
> -
I have made several tests, I could finally get the old behavior back,
but I had to put
vnc=1
vnclisten="0.0.0.0"
vncpasswd="x"
in each of my config files, instead of
vfb = [ 'type=vnc,vnc=1,vnclisten=0.0.0.0,vncpasswd=x' ]
so this vfb=[] must not be supported anymore?
netstat -nl showe
Sorry, I forget to change to the plain text mode.
On 25 April 2016 at 17:45, Stefano Stabellini wrote:
> Hello Wei,
>
> could you please send email replies in plain text (rather than html)?
>
> Thanks,
>
> Stefano
>
> On Mon, 25 Apr 2016, Wei Chen wrote:
>> Hi Julien,
>>
>> On 23 April 2016 at 02
>>> On 18.04.16 at 16:00, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1366,8 +1366,9 @@ gnttab_unmap_grant_ref(
>
> return 0;
>
> -fault:
> -gnttab_flush_tlb(current->domain);
> + fault:
> +if ( current->domain->is_shut_down )
> +gnt
Hi Julien
On 23 April 2016 at 02:29, Julien Grall wrote:
> Hi Wei,
>
>
> On 21/04/16 09:24, Wei Chen wrote:
>>
>> This patch adds v2m extension support in GIC-v2 driver. The GICv2 driver
>> detects the MSI frames from device tree and creates corresponding device
>> tree nodes in Domain0's DTB. It
On Mon, Apr 25, 2016 at 11:52:29AM +0200, Fabrice Delente wrote:
> I have made several tests, I could finally get the old behavior back,
> but I had to put
>
> vnc=1
> vnclisten="0.0.0.0"
> vncpasswd="x"
>
> in each of my config files, instead of
>
> vfb = [ 'type=vnc,vnc=1,vnclisten=0.0.0.0
Hello,
i'm trying to boot dom0 linux on exynos5422 platform on A15 (big cpu cluster).
From the past mailing lists on this link:
http://lists.xen.org/archives/html/xen-devel/2016-02/msg02275.html)
I'm not sure that is well defined how to change A7's for A15's.
Should change be in DTS or should
Here is the config file for one of machines:
builder = 'hvm'
memory = 2048
videoram = 8
vcpus = 1
name = "antivirus"
vif = [ 'bridge=xen-bridge' ]
disk = [ 'phy:/dev/vg0/antivirus,hda,w' ]# ,
'file:/root/windows7pro64bits.iso,hdc:cdrom,r' ]
acpi = 1
#device_model = 'qemu-dm'
boot = "c" # d"
sdl =
>>> On 18.04.16 at 16:00, wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -617,11 +617,12 @@ static void intel_iommu_iotlb_flush_all(struct domain
> *d)
> }
>
> /* clear one page's page table */
> -static void dma_pte_clear_one(struct domain
On Fri, 22 Apr 2016, Mark Rutland wrote:
> On Wed, Apr 20, 2016 at 10:34:41AM +0100, Stefano Stabellini wrote:
> > Hello Mark,
> >
> > do you think that this patch addresses your previous comments
> > (http://marc.info/?l=devicetree&m=145926913008544&w=2) appropriately?
> >
> > Thanks,
> >
> > S
>>> On 18.04.16 at 16:00, wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -678,8 +678,9 @@ static int xenmem_add_to_physmap(struct domain *d,
> if ( need_iommu(d) )
> {
> this_cpu(iommu_dont_flush_iotlb) = 0;
> -iommu_iotlb_flush(d, xatp->idx - done,
On Thu, 21 Apr 2016, Juergen Gross wrote:
> On 16/04/16 03:23, Stefano Stabellini wrote:
> > On slow platforms with unreliable TSC, such as QEMU emulated machines,
> > it is possible for the kernel to request the next event in the past. In
> > that case, in the current implementation of xen_vcpuop_
On Mon, Apr 25, 2016 at 12:03:00PM +0200, Fabrice Delente wrote:
> Here is the config file for one of machines:
>
> builder = 'hvm'
Oh right, so this is HVM guest.
A snippet from the manpage of xl.cfg for vfb=[] options:
This option does not control the emulated graphics card presented to an
OK, thanks for everything, I had overlooked that part.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Mon, 18 Apr 2016, Julien Grall wrote:
> UP guest usually uses TLB instruction to flush only on the local CPU. The
> TLB flush won't be broadcasted across all the CPUs within the same
> innershareable domain.
>
> When the vCPU is migrated between different CPUs, it may be rescheduled
> to a prev
A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users
of this HVMOP can specify which kind of operation is supposed
to be emulated in a parameter named flags. Current
Previously p2m type p2m_mmio_write_dm was introduced for write-
protected memory pages whose write operations are supposed to be
forwarded to and emulated by an ioreq server. Yet limitations of
rangeset restrict the number of guest pages to be write-protected.
This patch replaces the p2m type p2m_
For clarity this patch breaks the code to set/get memory types out
of do_hvm_op() into dedicated functions: hvmop_set/get_mem_type().
Also, for clarity, checks for whether a memory type change is allowed
are broken out into a separate function called by hvmop_set_mem_type().
There is no intentiona
XenGT leverages ioreq server to track and forward the accesses to GPU
I/O resources, e.g. the PPGTT(per-process graphic translation tables).
Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges
to be emulated. To select an ioreq server, the rangeset is searched to
see if the I/O
On Mon, Apr 25, 2016 at 11:35 AM, Wei Liu wrote:
> On Mon, Apr 25, 2016 at 12:03:00PM +0200, Fabrice Delente wrote:
>> Here is the config file for one of machines:
>>
>> builder = 'hvm'
>
> Oh right, so this is HVM guest.
>
> A snippet from the manpage of xl.cfg for vfb=[] options:
>
> This opti
On 25/04/16 09:56, Dirk Behme wrote:
Hi Julien,
Hello Dirk,
On 20.04.2016 15:26, Julien Grall wrote:
On 19/04/16 06:59, Dirk Behme wrote:
In some mailing list discussion
http://lists.xen.org/archives/html/xen-devel/2016-04/msg00214.html
some details about the interrupt handling of Xen w
Backport several fixes to mini-os in order to fix stubdom in 4.6.
Patches pulled in:
xenbus: notify the other end when necessary
Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483
Clean arch/x86/time.c
Fix time update
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Jan Beulich
---
On Mon, Apr 04, 2016 at 11:28:00AM +0100, Wei Liu wrote:
> On Fri, Apr 01, 2016 at 08:26:16PM +0200, Samuel Thibault wrote:
> > 7c8f3483 introduced a break within a loop in netfront.c such that
> > cons and nr_consumed were no longer always being incremented. The
> > offset at cons will be processe
flight 92651 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92651/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail pass in 92543
test-armhf-armhf-xl-rtds 15 gu
>>> On 25.04.16 at 13:12, wrote:
> Backport several fixes to mini-os in order to fix stubdom in 4.6.
>
> Patches pulled in:
>
> xenbus: notify the other end when necessary
> Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483
> Clean arch/x86/time.c
> Fix time update
>
> Signed-off-b
From: Jan Beulich
For vtsc=1 PV guests, rdtsc is trapped and calculated from get_s_time()
using gtime_to_gtsc. Similarly the tsc_timestamp, part of struct
vcpu_time_info, is calculated from stime_local_stamp using
gtime_to_gtsc.
However gtime_to_gtsc can return 0, if time < vtsc_offset, which ca
On Mon, Apr 25, 2016 at 05:15:57AM -0600, Jan Beulich wrote:
> >>> On 25.04.16 at 13:12, wrote:
> > Backport several fixes to mini-os in order to fix stubdom in 4.6.
> >
> > Patches pulled in:
> >
> > xenbus: notify the other end when necessary
> > Mini-OS: netfront: fix off-by-one error introdu
>>> On 22.04.16 at 18:35, wrote:
> On 22/04/16 08:20, Jan Beulich wrote:
>> When a guest unmasks MSI-X interrupts before enabling MSI-X on the
>> device, so far nothing updates the {host,guest}_masked internal state;
>> this to date only gets done when MSI-X is already enabled. This is why
>> half
flight 92667 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92667/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 14 guest-saverestore fail REGR. vs. 91479
test-amd64-amd64-libvirt-
On Mon, Apr 25, 2016 at 05:24:43AM -0600, Jan Beulich wrote:
> >>> On 22.04.16 at 18:35, wrote:
> > On 22/04/16 08:20, Jan Beulich wrote:
> >> When a guest unmasks MSI-X interrupts before enabling MSI-X on the
> >> device, so far nothing updates the {host,guest}_masked internal state;
> >> this to
On Thu, Apr 21, 2016 at 09:45:17AM -0600, Jan Beulich wrote:
> In commit aa7c1fdf9d ("x86/MSI: properly track guest masking requests")
> I neglected to consider devices allowing for both MSI and MSI-X to be
> used (not at the same time of course): The MSI-X part of the intercept
> logic needs to fa
On Thu, Apr 21, 2016 at 09:45:46AM -0600, Jan Beulich wrote:
> In commit 9256f66c16 ("x86/PCI: intercept all PV Dom0 MMCFG writes")
> for an unclear to me reason I left pci_conf_write_intercept()'s return
> value unchecked. Correct this.
>
> Signed-off-by: Jan Beulich
>
Release-acked-by: Wei Li
On Mon, Apr 25, 2016 at 01:07:54AM -0600, Jan Beulich wrote:
> Commit 4d27280572 ("x86/xsaves: fix overwriting between non-lazy/lazy
> xsaves") switched to always saving full state when using compacted
> format (which is the only one XSAVES allows). It didn't, however, also
> adjust the restore sid
>>> On 18.04.16 at 16:00, wrote:
> While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> However the existing panic() is going to be eliminated, so we must
> propagate the IOMMU Device-TLB flush error up to the
> iommu_iotlb_flush{,_all}.
>
> If IOMMU mapping and unmapping fail
On 04/22/16 16:47, Anthony PERARD wrote:
> Hi,
>
> Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root
> bridge does not finish to initialize and breaks under Xen.
(Adding Ray Ni)
> There are several issue probably due to the use of
> PcdPciDisableBusEnumeration=TRUE.
>
>>> On 18.04.16 at 16:00, wrote:
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -45,19 +45,31 @@ void do_suspend_lowlevel(void);
>
> static int device_power_down(void)
> {
> +int err;
> +
> console_suspend();
>
> time_suspend();
>
> i8259A_suspe
>>> On 18.04.16 at 16:00, wrote:
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -91,7 +91,7 @@ int is_igd_vt_enabled_quirk(void);
> void platform_quirks_init(void);
> void vtd_ops_preamble_quirk(struct iommu* iommu);
> void vtd_ops_postamble_quirk
>>> On 25.04.16 at 13:18, wrote:
> From: Jan Beulich
>
> For vtsc=1 PV guests, rdtsc is trapped and calculated from get_s_time()
> using gtime_to_gtsc. Similarly the tsc_timestamp, part of struct
> vcpu_time_info, is calculated from stime_local_stamp using
> gtime_to_gtsc.
>
> However gtime_to_
>>> On 25.04.16 at 12:35, wrote:
> Previously p2m type p2m_mmio_write_dm was introduced for write-
> protected memory pages whose write operations are supposed to be
> forwarded to and emulated by an ioreq server. Yet limitations of
> rangeset restrict the number of guest pages to be write-protect
>>> On 18.03.16 at 17:46, wrote:
> The command line instructions for FLASK include a note on how to compile
> Xen with FLASK but the note was out of date after the change to Kconfig.
>
> Signed-off-by: Doug Goldstein
> ---
> CC: Ian Jackson
> CC: Jan Beulich
> CC: Keir Fraser
> CC: Tim Deegan
On Mon, 25 Apr 2016, Jan Beulich wrote:
> >>> On 25.04.16 at 13:18, wrote:
> > From: Jan Beulich
> >
> > For vtsc=1 PV guests, rdtsc is trapped and calculated from get_s_time()
> > using gtime_to_gtsc. Similarly the tsc_timestamp, part of struct
> > vcpu_time_info, is calculated from stime_local
> -Original Message-
> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 25 April 2016 11:36
> To: xen-devel@lists.xen.org
> Cc: zhiyuan...@intel.com; Wei Liu; Paul Durrant; Paul Durrant; Keir (Xen.org);
> Jan Beulich; Andrew Cooper; George Dunlap; Jun Nakajima; Kevin Tian; Tim
> (
On 25/04/16 08:52, Thomas Gleixner wrote:
> On Mon, 25 Apr 2016, Jan Beulich wrote:
> On 22.04.16 at 20:03, wrote:
+#define hugepages_supported() cpu_has_pse
>>>
>>> Please don't use the cpu_has_* macros anymore, they are going away soon.
>>>
>>> In this case it should be static_cp
The `make` manual documents that a rule of the form
target1 target2: prereq
recipe
is equivilent to
target1: prereq
recipe
target2: prereq
recipe
This is correct if only target1 or target2 is wanted, but is not the case if
both target1 and target2 are wanted to be
On 04/24/2016 04:23 PM, Borislav Petkov wrote:
On Mon, Feb 01, 2016 at 10:38:48AM -0500, Boris Ostrovsky wrote:
Start HVMlite guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
page, initialize boot_params, enable early page tables.
Since this stub is executed before kernel entry point
On Thu, Apr 21, 2016 at 03:38:26AM -0600, Jan Beulich wrote:
> Recent changes to Linux result in there just being a single unmask
> operation prior to expecting the first interrupts to arrive. However,
> we've had a chicken-and-egg problem here: Qemu invokes
> xc_domain_update_msi_irq(), ultimately
On Mon, Apr 25, 2016 at 06:05:50AM -0600, Jan Beulich wrote:
> >>> On 25.04.16 at 13:18, wrote:
> > From: Jan Beulich
> >
> > For vtsc=1 PV guests, rdtsc is trapped and calculated from get_s_time()
> > using gtime_to_gtsc. Similarly the tsc_timestamp, part of struct
> > vcpu_time_info, is calcul
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] Fix cpumap setting
before passing to XEN"):
> On Wed, Apr 20, 2016 at 03:33:13PM +0100, Wei Liu wrote:
> > In principle I think having python binding and xl/libxl behave more or less
> > the same is the right direction. I'm a bit nervous about
On Mon, Apr 25, 2016 at 06:12:34AM -0600, Jan Beulich wrote:
> >>> On 25.04.16 at 12:35, wrote:
> > Previously p2m type p2m_mmio_write_dm was introduced for write-
> > protected memory pages whose write operations are supposed to be
> > forwarded to and emulated by an ioreq server. Yet limitations
Andrew Cooper writes ("[PATCH for-4.7] docs/build: Work around apparent bug
with multi-target rules"):
> The `make` manual documents that a rule of the form
>
> target1 target2: prereq
> recipe
>
> is equivilent to
>
> target1: prereq
> recipe
> target2: prereq
> recipe
On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang wrote:
> Previously p2m type p2m_mmio_write_dm was introduced for write-
> protected memory pages whose write operations are supposed to be
> forwarded to and emulated by an ioreq server. Yet limitations of
> rangeset restrict the number of guest pages to
On Mon, Apr 25, 2016 at 09:21:27AM -0400, Boris Ostrovsky wrote:
> I was following Documentation/x86/boot.txt (plus comments in code preceding
> those two routines) which I considered to be the API.
>
> We are supposed to come to startup_32 with paging off and %esi pointing to
> boot_params. For
On Mon, Apr 25, 2016 at 02:35:56PM +0100, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.7] docs/build: Work around apparent bug
> with multi-target rules"):
> > The `make` manual documents that a rule of the form
> >
> > target1 target2: prereq
> > recipe
> >
> > is equivilent t
On 25/04/16 14:50, Wei Liu wrote:
> On Mon, Apr 25, 2016 at 02:35:56PM +0100, Ian Jackson wrote:
>> Andrew Cooper writes ("[PATCH for-4.7] docs/build: Work around apparent bug
>> with multi-target rules"):
>>> The `make` manual documents that a rule of the form
>>>
>>> target1 target2: prereq
>>
(CC Steve and Andre)
Hi Stefano,
On 25/04/16 11:45, Stefano Stabellini wrote:
On Mon, 18 Apr 2016, Julien Grall wrote:
UP guest usually uses TLB instruction to flush only on the local CPU. The
TLB flush won't be broadcasted across all the CPUs within the same
innershareable domain.
When the v
On 04/25/2016 09:47 AM, Borislav Petkov wrote:
On Mon, Apr 25, 2016 at 09:21:27AM -0400, Boris Ostrovsky wrote:
I was following Documentation/x86/boot.txt (plus comments in code preceding
those two routines) which I considered to be the API.
We are supposed to come to startup_32 with paging of
Hi Jan,
On 25/04/16 12:52, Jan Beulich wrote:
On 18.04.16 at 16:00, wrote:
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2540,7 +2540,7 @@ static int force_stage = 2;
*/
static u32 platform_features = ARM_SMMU_FEAT_COHERENT_WALK;
-static void arm_s
> -Original Message-
> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
> George Dunlap
> Sent: 25 April 2016 14:39
> To: Yu Zhang
> Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
> Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan Beulich;
On Mon, Apr 25, 2016 at 09:54:37AM -0400, Boris Ostrovsky wrote:
> Yes, those.
I don't think the ones in arch/x86/kernel/head_{32,64}.S are ABI.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
___
Xen-devel mailing list
Xen
On Mon, Apr 25, 2016 at 02:38:57AM -0600, Jan Beulich wrote:
> >>> On 22.04.16 at 17:21, wrote:
> > Here is what I came up using your idea. Do you want me to add
> > 'Suggested-by'
> > Jan on it?
>
> I'll leave that up to you; it was really just a vague idea that I gave...
>
> > --- a/xen/arch
>>> On 25.04.16 at 15:25, wrote:
> On Thu, Apr 21, 2016 at 03:38:26AM -0600, Jan Beulich wrote:
>> Recent changes to Linux result in there just being a single unmask
>> operation prior to expecting the first interrupts to arrive. However,
>> we've had a chicken-and-egg problem here: Qemu invokes
>
>>> On 25.04.16 at 15:39, wrote:
> On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang wrote:
>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op.h
>> @@ -83,7 +83,13 @@ typedef enum {
>> HVMMEM_ram_rw, /* Normal read/write guest RAM */
>> HVMMEM_ram_ro,
flight 92666 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92666/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
build-amd6
On 25/04/16 15:01, Paul Durrant wrote:
>> -Original Message-
>> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
>> George Dunlap
>> Sent: 25 April 2016 14:39
>> To: Yu Zhang
>> Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
>> Andrew Cooper; Tim (Xen.
>>> On 25.04.16 at 16:01, wrote:
> The p2m type changes are also wrong. That type needs to be left alone,
> presumably, so that anything using HVMMEM_mmio_write_dm and compiled to the
> old interface version continues to function. I think HVMMEM_ioreq_server
> needs to map to a new p2m type whi
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 April 2016 15:16
> To: Paul Durrant
> Cc: Andrew Cooper; George Dunlap; Wei Liu; Jun Nakajima; Kevin Tian;
> Zhiyuan Lv; Yu Zhang; xen-devel@lists.xen.org; Keir (Xen.org); Tim (Xen.org)
> Subject: RE: [Xen-devel]
On Fri, Apr 01, 2016 at 11:03:28AM +0100, Wei Liu wrote:
> On Fri, Apr 01, 2016 at 01:41:40AM +, Xu, Quan wrote:
> > On March 31, 2016 9:50pm, Wei Liu wrote:
> > > On Thu, Mar 31, 2016 at 10:21:22AM +, Xu, Quan wrote:
> > > > On March 11, 2016 12:53am, Wei Liu wrote:
> > > > > -build: $(S
On Mon, Apr 25, 2016 at 3:19 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 25 April 2016 15:16
>> To: Paul Durrant
>> Cc: Andrew Cooper; George Dunlap; Wei Liu; Jun Nakajima; Kevin Tian;
>> Zhiyuan Lv; Yu Zhang; xen-devel@lists.xen.o
> -Original Message-
> From: George Dunlap
> Sent: 25 April 2016 15:28
> To: Paul Durrant
> Cc: Jan Beulich; Kevin Tian; Wei Liu; Andrew Cooper; Tim (Xen.org); xen-
> de...@lists.xen.org; Yu Zhang; Zhiyuan Lv; Jun Nakajima; Keir (Xen.org)
> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq
The #ifndef / #define value used was not consistent so it did not
function as a proper header guard.
Signed-off-by: Doug Goldstein
---
tools/libfsimage/ufs/ufs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libfsimage/ufs/ufs.h b/tools/libfsimage/ufs/ufs.h
index 4e7c
On 04/25/2016 10:11 AM, Borislav Petkov wrote:
On Mon, Apr 25, 2016 at 09:54:37AM -0400, Boris Ostrovsky wrote:
Yes, those.
I don't think the ones in arch/x86/kernel/head_{32,64}.S are ABI.
Hmm... I thought that everything specified in boot.txt was ABI.
I don't think we can jump to compress
On Mon, Apr 25, 2016 at 09:39:03AM -0500, Doug Goldstein wrote:
> The #ifndef / #define value used was not consistent so it did not
> function as a proper header guard.
>
> Signed-off-by: Doug Goldstein
Acked-by: Wei Liu
Release-acked-by: Wei Liu
And queued. Thanks for fixing this.
> ---
>
For native (non-cross compiles) we now only require bcc, ld86, as86 for
building rombios, we can build the toolstack sans rombios and using the
system SeaBIOS due to known build issues. At the same time capture the
output of the configure scripts to help with tracking down future build
issues. This
On April 25, 2016 9:58pm, wrote:
> On 25/04/16 12:52, Jan Beulich wrote:
> On 18.04.16 at 16:00, wrote:
> >> --- a/xen/drivers/passthrough/arm/smmu.c
> >> +++ b/xen/drivers/passthrough/arm/smmu.c
> >> @@ -2540,7 +2540,7 @@ static int force_stage = 2;
> >>*/
> >> static u32 platform_fea
1 - 100 of 190 matches
Mail list logo
