flight 57881 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57881/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 16 guest-stop fail REGR. vs. 53768
Tests which are f
* Rusty Russell wrote:
> As the comment in arch/x86/include/asm/paravirt_types.h says:
>
>* Get/set interrupt state. save_fl and restore_fl are only
>* expected to use X86_EFLAGS_IF; all other bits
>* returned from save_fl are undefined, and may be ignored by
>*
> -Original Message-
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Thursday, June 04, 2015 9:11 PM
> To: Li, Liang Z
> Cc: xen-devel@lists.xen.org; k...@xen.org; jbeul...@suse.com;
> andrew.coop...@citrix.com; Tian, Kevin; Zhang, Yang Z
> Subject: Re: [RESEND] nested EPT: fix the handl
On 05/06/2015 15:22, Jan Beulich wrote
> >>> "Wang, Wei W" 06/04/15 4:21 AM >>>
> >On 26/05/2015 22:16, Jan Beulich wrote
> >> >>> On 13.05.16 at 09:51, wrote:
> >> > --- a/xen/drivers/acpi/pmstat.c
> >> > +++ b/xen/drivers/acpi/pmstat.c
> >> > @@ -261,29 +272,47 @@ static int get_cpufreq_para(st
Hello Experts.What is "Ling" and why Xen choose "Erlang" ? Can you tell me
about the future of it on Xen? what is the goal?
Thank you.___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, 2015-06-04 at 12:01 +, osstest service user wrote:
> flight 57852 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/57852/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-q
As suggested by Andrew Cooper, this patch attempts to remove
some redundancy and allow for an easier time when adding vm_events
for new control registers in the future, by having a single
VM_EVENT_REASON_WRITE_CTRLREG vm_event type, meant to serve CR0,
CR3, CR4 and (newly introduced) XCR0. The actu
>>> On 04.06.15 at 17:47, wrote:
> At 16:19 +0100 on 04 Jun (1433434780), David Vrabel wrote:
>> On 04/06/15 15:05, Tim Deegan wrote:
>> > At 15:35 +0200 on 03 Jun (1433345719), Vitaly Kuznetsov wrote:
>> >> We need to close all event channel so the domain performing soft reset
>> >> will be able
On Fri, 2015-06-05 at 09:52 +0100, Jan Beulich wrote:
> >>> On 04.06.15 at 17:47, wrote:
> > At 16:19 +0100 on 04 Jun (1433434780), David Vrabel wrote:
> >> On 04/06/15 15:05, Tim Deegan wrote:
> >> > At 15:35 +0200 on 03 Jun (1433345719), Vitaly Kuznetsov wrote:
> >> >> We need to close all event
>>> On 05.06.15 at 10:45, wrote:
> On Thu, 2015-06-04 at 12:01 +, osstest service user wrote:
>> flight 57852 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/57852/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests whic
>>> On 05.06.15 at 10:58, wrote:
> On Fri, 2015-06-05 at 09:52 +0100, Jan Beulich wrote:
>> >>> On 04.06.15 at 17:47, wrote:
>> > At 16:19 +0100 on 04 Jun (1433434780), David Vrabel wrote:
>> >> On 04/06/15 15:05, Tim Deegan wrote:
>> >> > At 15:35 +0200 on 03 Jun (1433345719), Vitaly Kuznetsov w
On Fri, 2015-06-05 at 10:00 +0100, Jan Beulich wrote:
> >>> On 05.06.15 at 10:45, wrote:
> > On Thu, 2015-06-04 at 12:01 +, osstest service user wrote:
> >> flight 57852 xen-unstable real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/57852/
> >>
> >> Regressions :-(
> >>
> >>
On Thu, 2015-06-04 at 22:18 +, osstest service user wrote:
> flight 57866 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/57866/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-armhf-xl-multiv
On Fri, 2015-06-05 at 11:37 +0530, Vijay Kilari wrote:
> On Thu, Jun 4, 2015 at 7:24 PM, Ian Campbell wrote:
> > Draft D follows. Also at:
> > http://xenbits.xen.org/people/ianc/vits/draftD.{pdf,html}
>
> http://xenbits.xen.org/people/ianc/vits/draftD.pdf downloads draftC not draftD
Fixed, not s
>>> On 05.06.15 at 11:07, wrote:
> From:
> http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64
> -xl-qemuu-win7-amd64.xen-4.4-testing.html
> http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64
> -xl-qemuu-win7-amd64.xen-4.5-testing.html
> it look
On 05/06/2015 07:07, Vijay Kilari wrote:
On Thu, Jun 4, 2015 at 7:24 PM, Ian Campbell wrote:
This information shall include at least:
- The Device ID of the device.
- The maximum number of Events which the device is capable of
generating.
When a device is discovered/registered (i.e. when
>>> On 03.06.15 at 18:50, wrote:
> On 06/03/2015 05:36 PM, Don Slutz wrote:
>> On 06/03/15 11:58, Andrew Cooper wrote:
>>> On 03/06/15 16:26, George Dunlap wrote:
On 05/22/2015 04:50 PM, Don Slutz wrote:
> Summary is that VMware treats "in (%dx),%eax" (or "out %eax,(%dx)")
> to port 0
On 05/06/15 03:58, Rusty Russell wrote:
>
> Subject: x86: rename save_fl/restore_fl paravirt ops to highlight eflags.
> From: Rusty Russell
>
> As the comment in arch/x86/include/asm/paravirt_types.h says:
>
>* Get/set interrupt state. save_fl and restore_fl are only
>* expecte
>>> On 04.06.15 at 13:28, wrote:
> On 06/03/15 13:09, George Dunlap wrote:
>> On 05/22/2015 04:50 PM, Don Slutz wrote:
>>> This adds synchronization of the 6 vcpu registers (only 32bits of
>>> them) that vmport.c needs between Xen and QEMU.
>>>
>>> This is to avoid a 2nd and 3rd exchange between Q
>>> On 22.05.15 at 17:50, wrote:
> @@ -5805,6 +5808,12 @@ static int hvmop_set_param(
> break;
> if ( a.value > 1 )
> rc = -EINVAL;
> +/* Prevent nestedhvm with vmport */
> +if ( d->arch.hvm_domain.is_vmware_port_enabled )
> +{
> +
On Fri, 2015-06-05 at 10:28 +0100, Julien Grall wrote:
>
> On 05/06/2015 07:07, Vijay Kilari wrote:
> > On Thu, Jun 4, 2015 at 7:24 PM, Ian Campbell
> > wrote:
> >> This information shall include at least:
> >>
> >> - The Device ID of the device.
> >> - The maximum number of Events which the dev
On Fri, 2015-06-05 at 11:37 +0530, Vijay Kilari wrote:
> > ## Virtual LPI interrupt injection
> >
> > A physical interrupt which is routed to a guest vCPU has the
> > `_IRQ_GUEST` flag set in the `irq_desc` status mask. Such interrupts
> > have an associated instance of `struct irq_guest` which con
Introduced by c/s 376bbba "sched_rt: print useful affinity info when dumping".
If the allocation of cpumask failed, prv was leaked.
Signed-off-by: Andrew Cooper
Coverity-ID: 1304398
CC: Keir Fraser
CC: Jan Beulich
CC: Dario Faggioli
CC: George Dunlap
CC: Meng Xu
---
xen/common/sched_rt.c |
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 June 2015 10:36
> To: Don Slutz; Don Slutz
> Cc: Aravind Gopalakrishnan; Suravee Suthikulpanit; Andrew Cooper; Ian
> Campbell; Paul Durrant; George Dunlap; Ian Jackson; Stefano Stabellini; Eddie
> Dong; Jun Nakaj
On Fri, 2015-06-05 at 10:49 +0100, Andrew Cooper wrote:
> Introduced by c/s 376bbba "sched_rt: print useful affinity info when dumping".
> If the allocation of cpumask failed, prv was leaked.
>
Wow... I really did a _great_ job with that patch, didn't I? :-//
> Signed-off-by: Andrew Cooper
> Cov
On Thu, 4 Jun 2015, Don Slutz wrote:
> - Topal: Output generated on Fri Jun 5 11:09:19 BST 2015
> - Topal: GPG output starts -
> gpg: Signature made Thu 04 Jun 2015 23:20:41 BST using RSA key ID F1ABD29C
> gpg: Can't check signature: public key not found
> - Topal: GPG output ends
Hi Ian,
On 04/06/2015 17:49, Ian Campbell wrote:
It uses a PPI which we cannot route to a guest, and will surely need
more support than just that anyway.
I noticed this on Mustang with UEFI where the built in DTB contains a
node of this type.
Signed-off-by: Ian Campbell
---
xen/arch/arm/dom
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/06/2015 12:11, Stefano Stabellini wrote:
>>>
>>> Hopefully I will get to a change to Xen. However getting the
>>> Xen change back-ported to enough version(s) will not be
>>> quick...
> Yeah, this is basically an ABI breakage.
>
> We have b
On Fri, 5 Jun 2015, Paolo Bonzini wrote:
> - Topal: Using cache file
> `/home/sstabellini/.topal/cache/c86c5929de7d6c8599f3cb59b3e02e5b'-
> - Topal: Output generated on Fri Jun 5 11:25:25 BST 2015
> - Topal: GPG output starts -
> gpg: Signature made Fri 05 Jun 2015 11:25:03 BS
Printing pointers to struct domain isn't really useful for initial
problem analysis. In get_page() also drop the page only after issuing
the log message, so that at the time of printing the state can be
considered reasonably consistent.
Signed-off-by: Jan Beulich
---
It also slightly concerns me
On Thu, 2015-06-04 at 18:55 +0100, Julien Grall wrote:
> > # Scope
> >
> > The ITS is rather complicated, especially when combined with
> > virtualisation. To simplify things we initially omit the following
> > functionality:
> >
> > - Interrupt -> vCPU -> pCPU affinity. The management of physica
On Fri, 2015-06-05 at 11:17 +0100, Julien Grall wrote:
> Hi Ian,
>
> On 04/06/2015 17:49, Ian Campbell wrote:
> > It uses a PPI which we cannot route to a guest, and will surely need
> > more support than just that anyway.
> >
> > I noticed this on Mustang with UEFI where the built in DTB contains
On Fri, 2015-06-05 at 10:18 +0100, Jan Beulich wrote:
> >>> On 05.06.15 at 11:07, wrote:
> > From:
> > http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64
> >
> > -xl-qemuu-win7-amd64.xen-4.4-testing.html
> > http://logs.test-lab.xenproject.org/osstest/results/history.te
On 05/06/15 11:27, Jan Beulich wrote:
> Printing pointers to struct domain isn't really useful for initial
> problem analysis. In get_page() also drop the page only after issuing
> the log message, so that at the time of printing the state can be
> considered reasonably consistent.
>
> Signed-off-b
On Fri, 2015-06-05 at 10:31 +0100, Jan Beulich wrote:
> > I'm talking about cost-benefits analysis. What's the benefit of
> > accepting this patch, and is it worth the cost?
>
> The basic idea of allowing guests originally having got installed on
> VMware to continue their lives on Xen is certain
On Fri, 15 May 2015, Jan Beulich wrote:
> The code introduced to address XSA-126 allows simplification of other
> code in xen_pt_initfn(): All we need to do is update "cmd" suitably,
> as it'll be written back to the host register near the end of the
> function anyway.
>
> Signed-off-by: Jan Beuli
Il 05/06/2015 00:20, Don Slutz ha scritto:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/15 18:10, Eric Blake wrote:
[adding Markus, as author of the regression]
On 06/04/2015 03:59 PM, Don Slutz wrote:
On 06/04/15 11:04, Fabio Fantoni wrote:
Today after trying xen-unstable build (t
The problem requiring the first patch here is actually what lead to
XSA-120. This patch in turn introduces an issue similar to XSA-129,
which gets dealt with by patch 10 (and of course requiring qemu to
be fixed, for which a separate series will be sent). (Note that the
ordering of patches is solel
On Thu, 2015-06-04 at 15:54 +0100, Ian Campbell wrote:
> (redirecting to xen-devel as I originally intended)
>
> On Wed, 2015-06-03 at 13:02 +0800, lwch...@cs.hku.hk wrote:
> > Hi,
> >
> > Wonder if there is any follow-ups from the relevant developers:
> > (1) are you able to reproduce the "spinn
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
Rather than disabling and enabling MSI-X once per vector, do it just
once per device.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1243,6 +1243,9 @@ int pci_restore_msi_state(struct pci_dev
struct msi_desc *entry, *tmp;
st
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
---
v3: temp
On 05/06/15 11:25, Ian Campbell wrote:
> On Fri, 2015-06-05 at 11:17 +0100, Julien Grall wrote:
>> Hi Ian,
>>
>> On 04/06/2015 17:49, Ian Campbell wrote:
>>> It uses a PPI which we cannot route to a guest, and will surely need
>>> more support than just that anyway.
>>>
>>> I noticed this on Mustan
- __pci_enable_msix() now checks that an MSI-X capability was actually
found
- pass "pos" to msix_capability_init() as both callers already know it
(and hence there's no need to re-obtain it)
- call __pci_disable_msi{,x}() directly instead of via
pci_disable_msi() from __pci_enable_msi{x,}()
Fold msixtbl_addr_to_virt() + virt_to_msi_desc() into simplified
msixtbl_addr_to_desc(), as the callers don't need the virtual address
anymore.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -181,36 +181,23 @@ static struct msixtbl_entry *msixtbl_fin
In particular we want to avoid losing track of our own intention to
have an entry masked. Physical unmasking now happens only when both
host and guest requested so.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -241,7 +241,7 @@ static void hpet_msi_unmask(stru
The specification explicitly provides for this, so we should have
supported this from the beginning.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -209,7 +209,7 @@ static int msixtbl_read(
unsigned int nr_entry, index;
int r = X86EMUL_UNHANDL
On Mon, 2015-05-25 at 19:07 -0500, Chong Li wrote:
> Add xc_sched_rtds_vcpu_get/set functions to interact with Xen to get/set a
> domain's
> per-VCPU parameters.
>
> Signed-off-by: Chong Li
> Signed-off-by: Meng Xu
> Signed-off-by: Sisu Xi
It looks like there is still some discussion around t
Now that we support it for our guests, let's do so ourselves too.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -236,8 +236,7 @@ static bool_t read_msi_msg(struct msi_de
if ( unlikely(!msix_memory_decoded(entry->dev,
Also make dmar_{read,write}q() actually do what their names suggest (we
don't need to be concerned of 32-bit restrictions anymore).
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1054,8 +1054,7 @@ static void dma_msi_set_affinit
Qemu shouldn't be fiddling with this bit directly, as the hypervisor
may (and now does) use it for its own purposes. Provide it with a
replacement interface, allowing the hypervisor to track host and guest
masking intentions independently (clearing the bit only when both want
it clear).
Signed-off
> On 3 Jun 2015, at 10:35, Ian Campbell wrote:
>
> On Mon, 2015-06-01 at 10:36 +0100, Lars Kurth wrote:
>> In the event that we do not have a patch available two working weeks
>> before the disclosure date, we aim to send an advisory that reflects
>> the current state of knowledge to the Xen sec
On Fri, 15 May 2015, Jan Beulich wrote:
> Expecting the ROM BAR to be written with an all ones value when sizing
> the region is wrong - the low bit has another meaning (enable/disable)
> and bits 1..10 are reserved. The PCI spec also mandates writing all
> ones to just the address portion of the r
On Mon, 2015-05-25 at 19:09 -0500, Chong Li wrote:
> Add libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set functions to
> support
> per-VCPU settings for RTDS scheduler.
>
> Add a new data structure (libxl_vcpu_sched_params) to help per-VCPU settings.
>
> Signed-off-by: Chong Li
> Sig
On Mon, 2015-05-25 at 19:11 -0500, Chong Li wrote:
> Change main_sched_rtds and related output functions to support per-VCPU
> settings
> for xl sched-rtds tool.
>
> Signed-off-by: Chong Li
> Signed-off-by: Meng Xu
> Signed-off-by: Sisu Xi
> ---
> tools/libxl/xl_cmdimpl.c | 261
> +++
On Fri, 2015-06-05 at 12:20 +0100, Julien Grall wrote:
> On 05/06/15 11:25, Ian Campbell wrote:
> > On Fri, 2015-06-05 at 11:17 +0100, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 04/06/2015 17:49, Ian Campbell wrote:
> >>> It uses a PPI which we cannot route to a guest, and will surely need
> >>>
>>> On 05.06.15 at 13:32, wrote:
>> --- a/hw/xen/xen_pt.c
>> +++ b/hw/xen/xen_pt.c
>> @@ -248,7 +248,9 @@ static void xen_pt_pci_write_config(PCID
>>
>> /* check unused BAR register */
>> index = xen_pt_bar_offset_to_index(addr);
>> -if ((index >= 0) && (val > 0 && val < XEN_PT_BAR
On Fri, 2015-06-05 at 12:32 +0100, Lars Kurth wrote:
> > On 3 Jun 2015, at 10:35, Ian Campbell wrote:
> >
> > On Mon, 2015-06-01 at 10:36 +0100, Lars Kurth wrote:
> >> In the event that we do not have a patch available two working weeks
> >> before the disclosure date, we aim to send an advisory
Bob,
Thank you.
Adding Michael Glasgow
Note that I created a new list wg-openst...@lists.xenproject.org (CC'ed) ,
where we can discuss openstack related issues (see
http://lists.xenproject.org/cgi-bin/mailman/listinfo/wg-openstack). I will link
to it from various wiki/web pages also
Regards
1: MSI-X: latch MSI-X table writes
2: MSI-X: drive maskall and enable bits through hypercalls
3: MSI-X: really enforce alignment
4: pass-through: correctly deal with RW1C bits
5: pass-through: log errno values rather than function return ones
6: pass-through: constify some static data
Signed-off-b
The remaining log message in pci_msix_write() is wrong, as there guest
behavior may only appear to be wrong: For one, the old logic didn't
take the mask-all bit into account. And then this shouldn't depend on
host device state (i.e. the host may have masked the entry without the
guest having done s
Particularly the maskall bit has to be under exclusive hypervisor
control (and since they live in the same config space field, the
enable bit has to follow suit). Use the replacement hypercall
interfaces.
Signed-off-by: Jan Beulich
--- a/qemu/upstream/hw/xen/xen_pt.h
+++ b/qemu/upstream/hw/xen/x
The way the generic infrastructure works the intention of not allowing
unaligned accesses can't be achieved by simply setting .unaligned to
false. The benefit is that we can now replace the conditionals in
{get,set}_entry_value() by assert()-s.
Signed-off-by: Jan Beulich
--- a/qemu/upstream/hw/x
Introduce yet another mask for them, so that the generic routine can
handle them, at once rendering xen_pt_pmcsr_reg_write() superfluous.
Signed-off-by: Jan Beulich
--- a/qemu/upstream/hw/xen/xen_pt.h
+++ b/qemu/upstream/hw/xen/xen_pt.h
@@ -105,6 +105,8 @@ struct XenPTRegInfo {
uint32_t res
Functions setting errno commonly return just -1, which is of no
particular use in the log file.
Signed-off-by: Jan Beulich
--- a/qemu/upstream/hw/xen/xen_pt.c
+++ b/qemu/upstream/hw/xen/xen_pt.c
@@ -609,8 +609,8 @@ static void xen_pt_region_update(XenPCIP
g
This is done indirectly by adjusting two typedefs and helps emphasizing
that the respective tables aren't supposed to be modified at runtime
(as they may be shared between devices).
Signed-off-by: Jan Beulich
--- a/qemu/upstream/hw/xen/xen_pt.h
+++ b/qemu/upstream/hw/xen/xen_pt.h
@@ -31,7 +31,7
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> The function vgic_vN_init only calls register_vgic_ops. As it will never
> contain anything else, domain initialization code should be in the
> callback domain_init, remove them and directly use the VGIC ops in the
> commmon vGIC code.
>
> S
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> The domain_init callback can return error. Check it and progate the
> error if necessary.
>
> Signed-off-by: Julien Grall
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen
On Fri, Jun 5, 2015 at 7:13 PM, Ian Campbell
wrote:
> On Thu, 2015-06-04 at 15:54 +0100, Ian Campbell wrote:
> > (redirecting to xen-devel as I originally intended)
> >
> > On Wed, 2015-06-03 at 13:02 +0800, lwch...@cs.hku.hk wrote:
> > > Hi,
> > >
> > > Wonder if there is any follow-ups from the
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> On GICv3, the default size of the distributor region is 64kB. This
> region can be extended
But never shrunk, correct? Would a sanity check during parsing be
worthwhile?
> to provide an implementation defined set of
> pages containing addi
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> It's not neccessary to get again from the hardware DT the redistributor
"necessary"
I'd say "It is not necessary to get the redistributor information from
the hardware again".
> informations. We already have it stored in the gic_info and t
On 05/06/15 11:24, Ian Campbell wrote:
> On Thu, 2015-06-04 at 18:55 +0100, Julien Grall wrote:
>>> # Scope
>>>
>>> The ITS is rather complicated, especially when combined with
>>> virtualisation. To simplify things we initially omit the following
>>> functionality:
>>>
>>> - Interrupt -> vCPU -> p
>>> On 02.06.15 at 23:14, wrote:
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -581,6 +581,72 @@ out:
> return ret;
> }
>
> +static int register_one_rmrr(struct acpi_rmrr_unit *rmrru)
> +{
> +bool_t ignore = 0;
> +unsigned int i = 0;
> +
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> There is a global check for page alignment later within the same function.
>
> Signed-off-by: Julien Grall
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lis
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
Subject: "messages printed"
> - Print all the redistributor regions rather than only the first
> one...
> - Add # in the format to print 0x for hexadecimal. It's easier to
> differentiation from decimal
FWIW # doesn't work if
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> It's not easy to understand PAGE_SIZE * 0x10 and PAGE_SIZE * 16 at the
> first glance.
The important question really is what is the semantic meaning in the
given context, is it "N pages" or "a 64K region". In this particular
case it is indee
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> Make clear that the GIC interface is 4K and not rely on PAGE_SIZE == 4K.
I'm not really sure about this, it seems like splitting hairs a bit too
finely.
You forgot your S-o-b.
> ---
> xen/arch/arm/gic-v2.c | 27 +++
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> There is a global check for page alignment within this function.
>
> Signed-off-by: Julien Grall
> Cc: Zoltan Kiss
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
h
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> The driver only needs to know the base address of the hypervisor
> register during the GIC initialization (see gicv2_init).
>
> Signed-off-by: Julien Grall
Acked-by: Ian Campbell
___
Xen-deve
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> 0 is a valid physical address and dt_device_get_address would return
> an error if a problem during the retrieving happen.
>
> Signed-off-by: Julien Grall
Acked-by: Ian Campbell
___
Xen-devel
On Fri, 2015-06-05 at 13:24 +0100, Ian Campbell wrote:
> On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> > There is a global check for page alignment within this function.
> >
> > Signed-off-by: Julien Grall
> > Cc: Zoltan Kiss
>
> Acked-by: Ian Campbell
Lets make that a blanket Ack
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> ... in order to decouple the vGIC driver from the GIC driver.
Making the common physical GIC info struct contain the union of all gic
versions for the benefit of each of the vgic drivers is not how I would
prefer to see this.
I think we sho
On 04/06/15 17:25, Joe Perches wrote:
> On Thu, 2015-06-04 at 13:52 +0100, Julien Grall wrote:
>> On 04/06/15 13:46, David Vrabel wrote:
>>> On 04/06/15 13:45, Julien Grall wrote:
On 03/06/15 18:06, Joe Perches wrote:
> On Wed, 2015-06-03 at 17:55 +0100, Julien Grall wrote:
>> rx->stat
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> Currently, it's hard to decide whether a part of the domain
> initialization should live in gicv_setup (part of the GIC
> driver) and domain_init (part of the vGIC driver).
>
> The code to initialize the domain for a specific vGIC version i
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> Some version of the GIC are able so support multiple versions of the
> vGIC.
>
> For instance, some version of the GICv3 can as well support GICv2.
>
> Signed-off-by: Julien Grall ---
> xen/arch/arm/gic-v2.c | 1 +
> xen/arch/arm/gic-
On Fri, Jun 5, 2015 at 3:19 PM, Ian Campbell wrote:
> On Fri, 2015-06-05 at 11:37 +0530, Vijay Kilari wrote:
>> > ## Virtual LPI interrupt injection
>> >
>> > A physical interrupt which is routed to a guest vCPU has the
>> > `_IRQ_GUEST` flag set in the `irq_desc` status mask. Such interrupts
>> >
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> A platform may have a GIC compatible with previous version of the
> device.
>
> This is allow to virtualize an unmodified OS on new hardware if the GIC
> is compatible with older version.
>
> When a guest is created, the vGIC will emulate s
>>> On 02.06.15 at 23:14, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1185,6 +1185,18 @@ Specify the host reboot method.
> 'efi' instructs Xen to reboot using the EFI reboot call (in EFI mode by
> default it will use that method first).
>
On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
> * Modify the GICv3 driver to recognize a such device. I wasn't able
> to find a register which tell if GICv2 is supported on GICv3. The only
> way to find it seems to check if the DT node provides GICC and GICV.
I think that's the way...
>>> On 05.06.15 at 12:53, wrote:
> On 05/06/15 11:27, Jan Beulich wrote:
>> Printing pointers to struct domain isn't really useful for initial
>> problem analysis. In get_page() also drop the page only after issuing
>> the log message, so that at the time of printing the state can be
>> considered
On 05/06/15 13:14, Ian Campbell wrote:
> On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
>> On GICv3, the default size of the distributor region is 64kB. This
>> region can be extended
>
> But never shrunk, correct? Would a sanity check during parsing be
> worthwhile?
Yes. See 5.3 in PRD03
On 05/06/15 12:20, Jan Beulich wrote:
> 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 occurr
On 05/06/15 12:22, Jan Beulich wrote:
> In particular we want to avoid losing track of our own intention to
> have an entry masked. Physical unmasking now happens only when both
> host and guest requested so.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
I really need to dust off my
On 05/06/15 12:23, Jan Beulich wrote:
> Fold msixtbl_addr_to_virt() + virt_to_msi_desc() into simplified
> msixtbl_addr_to_desc(), as the callers don't need the virtual address
> anymore.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
X
On Thu, Jun 04, 2015 at 04:28:00PM +0100, Wei Liu wrote:
[...]
> 2. Libxl record that in toolstack save path.
> 3. Remote end calls xc_domain_setmaxmem in toolstack restore path.
Unfortunately toolstack restore is called after
libxl__xc_domain_restore so it cannot be used to solve our problem.
We
Hi Ian,
On 05/06/15 13:15, Ian Campbell wrote:
> On Fri, 2015-05-08 at 14:29 +0100, Julien Grall wrote:
>> It's not neccessary to get again from the hardware DT the redistributor
>
> "necessary"
>
> I'd say "It is not necessary to get the redistributor information from
> the hardware again".
>
On 06/05/15 05:52, Jan Beulich wrote:
On 22.05.15 at 17:50, wrote:
@@ -5805,6 +5808,12 @@ static int hvmop_set_param(
break;
if ( a.value > 1 )
rc = -EINVAL;
+/* Prevent nestedhvm with vmport */
+if ( d->arch.hvm_domain.is_vmware_port_enable
On Fri, 2015-06-05 at 13:15 +0100, Julien Grall wrote:
> >> I'm struggling to see how this would work. After enabling/disabling an
> >> IRQ you need to send an INV which require the devID and the eventID.
> >
> > This is a detail for the pits driver, which is deliberately out of scope
> > here. Th
>>> On 02.06.15 at 18:26, wrote:
> @@ -546,13 +567,19 @@ static void mapcount(
>
> *wrc = *rdc = 0;
>
> +/*
> + * Must have the remote domain's grant table lock while counting
> + * its active entries.
> + */
> +ASSERT(spin_is_locked(&rd->grant_table->lock));
> +
>
>>> On 02.06.15 at 18:26, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -288,10 +288,10 @@ static inline void put_maptrack_handle(
> struct grant_table *t, int handle)
> {
> -spin_lock(&t->lock);
> +spin_lock(&t->maptrack_lock);
> maptrack_entry(t
1 - 100 of 224 matches
Mail list logo
