On Fri, Apr 25, 2025 at 12:29:35PM +0200, Niklas Schnelle wrote:
> On Fri, 2025-04-25 at 11:00 +0200, Thomas Huth wrote:
> > On 17/04/2025 19.37, Farhan Ali wrote:
> > > +asm volatile(
> > > +/* pcilgi */
> > > +".insn rre,0xb9d6,%[val],%[ioaddr_len]\n"
> > > +"ipm
On Mon, Jul 27, 2020 at 12:12:02PM +0200, David Hildenbrand wrote:
> +#define DIAG500_DEVICE_MEMORY_REGION 4
> >>>
> >>> Regardless what we end up with, this needs to be specified
> >>> somewhere(tm).
> >>
> >> Yeah, there, we should also document the existing subcodes. What would
> >> be
On Wed, Jul 15, 2020 at 07:51:27PM +0200, David Hildenbrand wrote:
> > Regarding documentation (some linked in the cover letter), so far I have
> > (generic/x86-64)
> >
> > 1. https://virtio-mem.gitlab.io/
> > 2. virtio spec proposal [1]
> > 3. QEMU 910b25766b33 ("virtio-mem: Paravirtualized memor
On Wed, Jul 15, 2020 at 01:42:02PM +0200, David Hildenbrand wrote:
> > So, are you saying that even at IPL time there might already be memory
> > devices attached to the system? And the kernel should _not_ treat them
> > as normal memory?
>
> Sorry if that was unclear. Yes, we can have such device
On Wed, Jul 15, 2020 at 01:21:06PM +0200, David Hildenbrand wrote:
> > At least in v4.1 the kernel will calculate the max address by using
> > increment size * increment number and then test if *each* increment is
> > available with tprot.
>
> Yes, we do the same in kvm-unit-tests. But it's not su
On Wed, Jul 15, 2020 at 11:19:03AM +0200, David Hildenbrand wrote:
> On 14.07.20 12:17, Claudio Imbrenda wrote:
> > shouldn't it return all the hotplugged areas once hotplugging is
> > enabled?
>
> No, that would be dangerous and wrong. Memory ranges part of memory
> devices never must be indicate
On Wed, Jul 15, 2020 at 11:42:37AM +0200, David Hildenbrand wrote:
> So, in summary, we want to indicate to the guest a memory region that
> will be used to place memory devices ("device memory region"). The
> region might have holes and the memory within this region might have
> different semantic
On Fri, Jul 10, 2020 at 05:24:07PM +0200, David Hildenbrand wrote:
> On 10.07.20 17:18, Heiko Carstens wrote:
> > On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
> >>> Note: Reading about diag260 subcode 0xc, we could modify Linux to query
> >>
On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
> > Note: Reading about diag260 subcode 0xc, we could modify Linux to query
> > the maximum possible pfn via diag260 0xc. Then, we maybe could avoid
> > indicating maxram size via SCLP, and keep diag260-unaware OSs keep
> > working
On Fri, Jul 10, 2020 at 05:24:07PM +0200, David Hildenbrand wrote:
> On 10.07.20 17:18, Heiko Carstens wrote:
> > On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
> >>> Note: Reading about diag260 subcode 0xc, we could modify Linux to query
> >>
On Thu, Sep 04, 2014 at 12:52:26PM +0200, frank.blasc...@de.ibm.com wrote:
> +void kvm_s390_gisa_register_alert(struct kvm *kvm, u32 gisc)
> +{
> + int bito = BITS_PER_BYTE * 7 + gisc;
> +
> + set_bit(bito ^ (BITS_PER_LONG - 1), &kvm->arch.iam);
> +}
Just a very minor nit: you could also u
On Mon, Mar 17, 2014 at 07:11:37PM +0100, Cornelia Huck wrote:
> Add a new interface to register/deregister sources of adapter interrupts
> identified by an unique id via the flic. Adapters may also be maskable
> and carry a list of pinned pages.
>
> These adapters will be used by irq routing late
On Wed, Jul 31, 2013 at 11:08:15AM +0200, Cornelia Huck wrote:
> On Mon, 29 Jul 2013 15:59:53 +0200
> Jens Freimann wrote:
>
> > This patch adds a floating irq controller as a kvm_device.
> > It will be necesary for migration of floating interrupts as well
> > as for hardening the reset code by a
On Fri, Jul 26, 2013 at 06:47:59PM +0200, Jens Freimann wrote:
> This patch adds a floating irq controller as a kvm_device.
> It will be necesary for migration of floating interrupts as well
> as for hardening the reset code by allowing user space to explicitly
> remove all pending floating interru
On Tue, Sep 04, 2012 at 05:13:25PM +0200, Cornelia Huck wrote:
Just some quick comments:
[...]
> int kvm_s390_inject_program_int(struct kvm_vcpu *vcpu, u16 code)
> {
> struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
> @@ -648,6 +747,12 @@ int kvm_s390_inject_vm(struct kvm *k
On Thu, Aug 09, 2012 at 12:41:57PM +0200, Cornelia Huck wrote:
> On Thu, 09 Aug 2012 13:03:57 +0300
> Avi Kivity wrote:
>
> > On 08/07/2012 05:52 PM, Cornelia Huck wrote:
> > > Running under a kvm host does not necessarily imply the presence of
> > > a page mapped above the main memory with the v
16 matches
Mail list logo
