Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
p;vcpu->arch.vgic.lock, flags);
+
+return ret;
The implementation looks good. However, one question. ret would be equal
to the latest LPI updated. So even if all LPIs have failed but the
latest, you will still return 0. Is it what you want?
Cheers,
--
Julien Grall
_
And I obviously commented on the wrong version :/.I will replicate the
command on v10.
Sorry for the inconvenience.
On 06/02/2017 06:24 PM, Julien Grall wrote:
Hi Andre,
On 05/11/2017 06:53 PM, Andre Przywara wrote:
+do
+{
+nr_lpis =
radix_tree_gang_lookup(&it
p;vcpu->arch.vgic.lock, flags);
+
+return ret;
The implementation looks good. However, one question. ret would be equal
to the latest LPI updated. So even if all LPIs have failed but the
latest, you will still return 0. Is it what you want?
Cheers,
--
Julien Grall
_
moment for the only
purpose of later being able to free them again.
We configure the virtual ITSes to match the hardware ones, that is we
keep the number of device ID bits and event ID bits the same as the host
ITS.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
Cheers,
--
Julien Grall
to match the hardware.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 05/31/2017 11:42 AM, Julien Grall wrote:
Hi Stefano,
On 30/05/17 22:39, Stefano Stabellini wrote:
On Tue, 30 May 2017, Julien Grall wrote:
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock
reate mode 100644 xen/include/asm-arm/vpl011.h
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
this information,
the debug output can easily be inserted into the wrapper function or
this export can be done just for this debugging session.
So I'd rather not do this - as the patch demonstrated ;-)
Fair enough. So:
Acked-by: Julien Grall
Cheers,
--
Julien
regression too much exceeds the time between new regressions being
introduced, we will never succeed.
Julien, what is the state of the arndale fixes for 4.9 ?
Just sent it (you are CCed). Sorry for the late.
Cheers,
--
Julien Grall
___
Xen-devel m
/release/xen/4.9.0-rc8/xen-4.9.0-rc8.tar.gz.sig
Please send bug reports and test reports to
xen-de...@lists.xenproject.org. When sending bug reports,
please CC relevant maintainers and me (julien.gr...@arm.com).
Cheers,
--
Julien Grall
___
Xen-devel
Hi,
It has been reviewed-by Boris but I don't see the patch queued. Would it
be possible to queue it for 4.12?
Cheers,
On 01/06/17 21:41, Boris Ostrovsky wrote:
On 06/01/2017 11:38 AM, Julien Grall wrote:
Hi Boris,
On 01/06/17 16:16, Boris Ostrovsky wrote:
On 06/01/2017 10:01 AM, J
Hi Stefano,
On 23/05/17 19:26, Stefano Stabellini wrote:
On Tue, 23 May 2017, Julien Grall wrote:
Both helpers access_ok and array_access_ok are not used on ARM. Remove
them.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
I don't see this patch in staging. Can you p
In order to select "wait for the lock" behavior, you have
+# to add the '-w' parameter. Unfortinately, both the locking and the
NIT: s/Unfortinately/Unfortunately/
Release-acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 26/05/17 12:14, Punit Agrawal wrote:
Hi,
Hi,
It looks like this patch series has been fully acked. Can someone apply it?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
potential bug if not disabled
correctly.
I agree, but imo this should be a prompt-less Kconfig option,
selected under suitable conditions.
I don't mind of the way to do it as long as it is disabled on ARM.
Cheers,
--
Julien Grall
___
Xen
Release-acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 06/06/17 18:06, Andre Przywara wrote:
On 30/05/17 11:47, Julien Grall wrote:
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock so far.
However for forwarded interrupts (Dom0 only so far) this
crash, especially windows which uses this mechanism to
handle NMIs.
Release-acked-by: Julien Grall
Cheers,
---
An alternative to adding yet another parameter to the function would
be to have "cpl" have a special case value (e.g. negative) to indicate
VM86 mode. That would allow repla
idea was to confine this fix to what we care for right now.
I guess eventually it doesn't matter as we will probably get rid of the
rank and its lock anyway.
That's a good point. So we may want to wait until the vGIC rework to see
what we can do here. Stefano, any opinion?
Che
this concern 4.9
release... Please take the habit to CC the release manager for anything
targeting a release.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
s.html &
other artifacts
Will create, when we cut the tarballs
Regards
Lars
On 02/06/2017 17:15, "Julien Grall" wrote:
Hi all,
There are some pending security issues that have been found during the
hardening period, which haven't been pre-disclosed yet.
I am going to delay t
-$(CONFIG_TRACE) += trace.o
obj-y += traps.o
obj-y += usercopy.o
obj-y += x86_emulate.o
I would use similar things for common/trace.c too. This would let the
user remove all tracing code at build time.
Cheers,
--
Julien Grall
___
Xen-devel
i
Cc: Julien Grall
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Jennifer Herbert
---
xen/Kconfig.debug | 11 -
xen/common/spinlock.c | 16 +--
xen/common/trace.c | 10 +++-
xen/include/asm-arm/arm32/system.h | 12 +
xen/include/asm-arm/
On 06/06/17 11:19, Andre Przywara wrote:
Hi,
On 30/05/17 12:38, Julien Grall wrote:
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped&qu
However, today, nobody is using 'page' after. Unless there is a reason
to drop it, I would prefer to keep it so the if and else part match.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ners but I think it would be better to keep the
page = mfn_to_page(mfn). This is matching the behavior of the else part
where page will always point to first base page.
Indeed we don't use it today, but nothing prevent a future patch to do
it and it would be difficult to spot th
d
by Xen.
In any case, the naming gives the impression it also exists when
HCR_EL2.E2H = 0.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/06/17 16:07, Julien Grall wrote:
On 07/06/17 15:56, Sergej Proskurin wrote:
Hi Julien,
[...]
Also, a lot of the new defines you add are for TCR_EL1 and not TCR_EL2.
Please make the distinction in the name to avoid misusing them.
+
+#define TCR_TB_31 (31)
#ifdef
On 07/06/17 18:46, Stefano Stabellini wrote:
On Wed, 7 Jun 2017, Punit Agrawal wrote:
Stefano Stabellini writes:
On Tue, 6 Jun 2017, Julien Grall wrote:
On 26/05/17 12:14, Punit Agrawal wrote:
Hi,
Hi,
It looks like this patch series has been fully acked. Can someone apply it?
Done
tion. However,
I am not sure how this is related to write_itte_locked.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
the macro for_each_set_bit (see xen/bitops.h) here that will
handle the problem for you:
for_each_set_bit( used_lr, lr_mask, nr_lrs )
{
}
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
MD_SIZE) %
+ ITS_CMD_BUFFER_SIZE(its->cbaser));
+
+if ( ret )
+gdprintk(XENLOG_WARNING,
+ "vGITS: ITS command error %d while handling command
%lu\n",
+ ret, its_cmd_get_command(command));
... here?
This co
On 08/06/17 13:11, Manish Jaggi wrote:
On 5/30/2017 4:07 PM, Julien Grall wrote:
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index c927306..f496fc1 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1301,6 +1301,7 @@ static int gicv3_iomem_deny_access(const
d, const struct
dt_device_node *gic, void *fdt); +u32 gicv3_its_make_hwdom_madt(u8
*base_ptr, u32 offset); +u32
gicv3_its_madt_generic_translator_size(void); +/* Deny iomem access for
its */ +int gicv3_its_deny_access(const struct domain *d); /* * Map a
device on the host by allocating an ITT on the hos
pi_iort_id_mapping {
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 9f954d3..1cc0167 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -36,6 +36,7 @@ typedef enum {
TBL_FADT,
TBL_MADT,
TBL_STAO,
+
tor_size(void);
+/* Deny iomem access for its */
+int gicv3_its_deny_access(const struct domain *d);
Same here.
/*
* Map a device on the host by allocating an ITT on the host (ITS).
* "nr_event" specifies how many events (interrupts) this device will
need.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ATA,
+ FWNODE_IRQCHIP
+};
+
+struct fwnode_handle {
+ enum fwnode_type type;
+ struct fwnode_handle *secondary;
+};
+
+#endif
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
unsigned long align);
+extern void *_xrealloc(void *p, unsigned long new_size, unsigned long align);
static inline void *_xmalloc_array(
unsigned long size, unsigned long align, unsigned long num)
--
Julien Grall
___
Xen-devel mailing list
X
e_handle {
+ enum fwnode_type type;
+ struct fwnode_handle *secondary;
+};
+
+#endif
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+ const struct iommu_ops *ops);
+void iommu_fwspec_free(struct device *dev);
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
+
+#endif
#endif /* _IOMMU_H_ */
Cheers,
--
Julien Grall
t really need the p2m. What would you prefer?
Technically this should be a vCPU as the guest page-table may be
different on each vCPU. So I would prefer to use a vCPU here.
Also, it would allow us to make sure the function has been called with
vCPU == current (i.e an ASSERT).
Cheers,
--
Julien
On 09/06/2017 07:48, Manish Jaggi wrote:
On 6/8/2017 7:28 PM, Julien Grall wrote:
Hi,
Hello Julien,
Hello,
+list_for_each_entry(its_data, &host_its_list, entry)
+{
Pointless {
+size += sizeof(struct acpi_madt_generic_translator);
+}
Just for readability of
On 09/06/2017 08:13, Manish Jaggi wrote:
On 6/8/2017 6:39 PM, Julien Grall wrote:
Hi Manish,
Hi Julien,
Hello,
On 08/06/17 13:38, Manish Jaggi wrote:
Spurious line.
This patch disables the smmu node in IORT table for hardware domain.
Also patches the output_base of pci_rc id_array
ment (Input_base, num_ids, out_base) can translate
into two or more id_array entries of smmu node.
Which is basically solution 1) below... Anyway, I will wait the next
version hoping that you will handle properly the IORT generation.
Cheers,
--
Julien Grall
On 07/06/17 16:22, Dario Faggioli wrote:
On Wed, 2017-06-07 at 12:16 +0100, Julien Grall wrote:
Hi Dario,
Hi,
On 01/06/17 18:34, Dario Faggioli wrote:
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 2a06406..33b903e 100644
--- a/xen/common/spinlock.c
+++ b/xen/common
On 09/06/17 11:51, Julien Grall wrote:
On 07/06/17 16:22, Dario Faggioli wrote:
On Wed, 2017-06-07 at 12:16 +0100, Julien Grall wrote:
Hi Dario,
Hi,
On 01/06/17 18:34, Dario Faggioli wrote:
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 2a06406..33b903e 100644
--- a
On 09/06/17 11:55, George Dunlap wrote:
On 09/06/17 11:51, Julien Grall wrote:
On 07/06/17 16:22, Dario Faggioli wrote:
On Wed, 2017-06-07 at 12:16 +0100, Julien Grall wrote:
Hi Dario,
Hi,
On 01/06/17 18:34, Dario Faggioli wrote:
diff --git a/xen/common/spinlock.c b/xen/common
a part
of this functionality would be in a separate function (e.g.
get_granularity()), though. I will see what I can do at this point.
You are right sorry. However, I still think open-code 0,1,2 is not
intuitive. You should introduce proper define for that.
Cheers,
ed-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
You should include asm/vreg.h and not asm-arm/vreg.h. With that fixed:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
LPERS
#endif /* __ASM_ARM_VREG__ */
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
G_IDX out_cons = intf->out_cons;
+XENCONS_RING_IDX out_prod = intf->out_prod;
+XENCONS_RING_IDX in_ring_qsize, out_ring_qsize;
smb_mb()
Ditto.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
(e.g trace) using
physmap hypercall with XENMAPSPACE_foreign_gmfn_foreign.
*/
#define DOMID_XENxen_mk_uint(0x7FF2)
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 09/06/17 14:20, Julien Grall wrote:
Hi Jan,
On 08/06/17 16:19, Jan Beulich wrote:
Correct respective comments.
Signed-off-by: Jan Beulich
---
MMUEXT_{CLEAR,COPY}_PAGE in fact also allow to be invoked on DOMID_IO
owned pages at present. I've intentionally not added this to the tex
nit(struct domain *d,
+ struct vpl011_init_info *info);
+void domain_vpl011_deinit(struct domain *d);
+#else
+static inline int domain_vpl011_init(struct domain *d,
+ struct vpl011_init_info *info)
+{
+return -ENOSYS;
+}
+
+static inline void domain_vpl011_deinit(struct domain *d) { }
+#endif
+
+#endif
+
Please drop this newline.
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
test.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ind the definition of domain_vpl011_deinit
See patch #3.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
rc = -EINVAL;
+break;
+}
+
+return rc;
+}
default:
{
int rc;
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
confusing as it is easily to mix with the
atomic_read, atomic_write helpers.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
3; // Log2(page size / 8 bytes)
So I still don't see how this would make the code less readable. This
would also avoid to introduce yet another array on the stack (though it
should really have been static) for limited purpose.
Cheers,
--
Julien Grall
thout unlocking!
CC: Ross Lagerwall
CC: Boris Ostrovsky
CC: Jan Beulich
CC: Andrew Cooper
CC: Julien Grall
Julien, could you Release-Ack it for 4.9 please?
Sure:
Release-acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing li
e the full support before giving an
ack on this patch.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
e have a benefits to keep this code
close to Linux. It is small enough and we don't need 80% of it.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hi Sameer,
On 08/06/17 22:42, Goel, Sameer wrote:
On 6/8/2017 1:59 PM, Julien Grall wrote:
On 08/06/2017 20:30, Sameer Goel wrote:
This will be used as a device property to match the DMA capable devices
with the associated SMMU. The header file is a port from linux.
Linux
LT_THRESHOLD 10
} fault;
u64 vf_rlen[6];
+struct device dev;
struct device does not exist on x86. If you still want to add it, then
you should do it in a separate patch and CC relevant maintainers.
};
#define for_each_pdev(domain, pdev) \
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
h) kick up stream table faults.
Robin.
[1]:http://www.spinics.net/lists/linux-acpi/msg74844.html
I am not sure how x86 is handling that. The closest I can find would be
domain_context_mapping. I have CCed x86 folks to get more feedback here.
Cheers,
--
Julien Grall
For the device_tree part:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
IDs to be passed in to inquire whether the
device is assigned to that specific domain.
I forgot to answer on this bit. I agree that the current behavior is
strange. I would be in favor of your suggestion.
Cheers,
--
Julien Grall
___
Xen-devel
ing that code
for a dying domain is only a symptom as far as we understand it
now, not anywhere near the cause.
Are you suggesting to revert on Xen 4.9?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
& INTERRUPT_RANK_MASK];
-vgic_unlock_rank(v, rank, flags);
-return priority;
+return ACCESS_ONCE(rank->priority[virq & INTERRUPT_RANK_MASK]);
}
bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
Cheers,
--
Julien Grall
d-off-by: Andre Przywara
With the change above:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
10 bits here, since for now it only sees
SPIs, so it does not need more. This should be revisited once we get
proper DomU ITS support.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel
flight_irq(struct vcpu *v, unsigned int virtual_irq);
-extern void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq);
+extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p);
/* Accept an interrupt from the GIC and dispa
IC_IRQ_GUEST_ENABLED, &p->status);
gic_remove_from_lr_pending(v_target, p);
+desc = p->desc;
spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
+clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
+list_del_init(&p->inflight);
+gic_remove_from_lr_pending(v, p);
+}
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ra
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
with a BUILD_BUG_ON.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
not change anything, it just removes the declaration and initialization.
Signed-off-by: Andre Przywara
With the typo fixed:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org
s/all of time/all of the time/ I think.
With that:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
a
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
confusingly using ID_bits in GITS_TYPER to denote the number of event IDs
(in contrast to GICD_TYPER, where it means number of LPIs).
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel
arm64 - and copy the
respective entries before using them, to avoid the guest tampering with
them meanwhile.
To allow compiling without warnings, we declare two functions as
non-static for the moment, which two later patches will fix.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
.
Hmmm, you do that in patch #22 now. So please move this sentence in that
patch.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
as well.
+ */
+if ( unlikely(!p ||
+ test_and_clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status)) )
NIT: !p and test_and_clear_bit should be aligned. By that I mean:
unlikely(!p ||
test_and_clear_bit()
With that:
Acked-by: Julien Grall
Cheers,
-
Hi Andre,
On 07/06/17 18:49, Andre Przywara wrote:
On 02/06/17 18:12, Julien Grall wrote:
On 05/26/2017 06:35 PM, Andre Przywara wrote:
+/*
+ * radix_tree_insert() returns an error either due to an internal
+ * condition (like memory allocation failure) or because the LPI
already
might still
be disabled at this point.
Since write_itte_locked() now sees its first usage, we change the
NIT: s/write_itte_locked/write_itte/
declaration to static.
Signed-off-by: Andre Przywara
With the update in the commit message:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
ned-off-by: Andre Przywara
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
for those from that particular
VCPU.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
release note if it
is not backported before the release.
I will keep track of this.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 12/06/2017 23:34, Stefano Stabellini wrote:
On Mon, 12 Jun 2017, Julien Grall wrote:
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock so far.
However for forwarded interrupts (Dom0 only so
e ring buffer. For writing data, it keeps checking
periodically if there is space in the
ring buffer. If there is space then it writes more data.
You should not assume that xenconsoled is the only backend console. One
could decide to implement its own.
code is unlikely to help
with any further analysis of the issue, as reaching that code
for a dying domain is only a symptom as far as we understand it
now, not anywhere near the cause.
Are you suggesting to revert on Xen 4.9?
Yes, if we revert now, then I'd say on both master and 4.
at least on ARM GCC (?), assignment will be atomic
(though will not prevent the compiler to only write/read once). We make
this assumption in quite a few places (such as PV protocol for the
index) and I am not sure to understand why it cannot be done in other
places...
Chee
opy over the ACPI tables. Rather
regenerating them.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 13/06/17 12:44, Manish Jaggi wrote:
On 6/13/2017 4:58 PM, Julien Grall wrote:
On 13/06/17 12:02, Manish Jaggi wrote:
Will the below code be ok?
If you noticed, I didn't say this code is wrong. Instead I asked why
you use the same ID. Meaning, is there anything in the DSDT requiring
tic inline void domain_vpl011_deinit(struct domain *d) { }
+#endif
+
+#endif
+
Please drop this newline.
You mean the newline between the #endifs or after the last #endif?
Yes.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
_ONCE/WRITE_ONCE with
bigger size. I am not suggesting to do the same on Xen but avoiding the
bigger size.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
701 - 800 of 6780 matches
Mail list logo
